第一次尝试做PM

时间:2021-07-26 16:22:09

在3月底的时候,第一次接触后向流量经营平台,一个新项目,当时有点紧张和欣喜,欣喜的是我可以负责一个项目,这是一个新的锻炼机会,紧张的是我不知道怎么去做好一个项目,这对我来说是一个全新的挑战。

1.需求接触

   当时域经理,就发了一个原型图给我看,我看了一下,什么后向流量、移动网络加速,一点概念也没有,当时就懵了,紧接着域经理和部门经理去开会,就这个项目讲了一大堆,当时是对着业务流程图讲的,会议结束的时候讲到了CRM与能力开放(CSB),计费,当时的后向流量系统之间的关系,由于我对CRM域的业务不熟悉,所以也只听懂了是做流量代理这个平台。写这些文字的时候,差不多两个月了,这时候已经完全理清了系统之间的交互。,

  第二次我记得是参加了一个需求分析会,其实需求专门有人做的,我们开发承接方,我的任务就是将需求搞懂,将需求转化为代码,表结构,进行任务分配。记得当时也听了云里雾里的,尤其是涉及到其他平台,就更加听不懂了,好在测试给我发了文档,否则我就更加听不懂了,这时候开始有很多疑问了,比如流量的计费,其实有疑问是好事情,证明自己对别人的需求设计开始有了自己的想法,当时下午就整理了好多疑问,一点一点的讨教老大。老大很耐心,又给我说了一遍整个流程,我的理解又加深了一步。紧接着是清明的前一天,是我对需求的消化阶段,由于我要负责整个项目的表结构设计,兼顾需求和开发,所以我要比任何人都要了解需求,避免二次开发,我又问了一次老大,后来就清明回去按照自己的理解去想表结构了,这是我第一次挑战整个项目的表结构设计。


2.开发准备

  说到开发准备,我一个人肯定是完不成的,毕竟工作经验也只有一年多,技术架构又不是特别了解,老大说采用分布式架构,这是我第一次了解dubbo和zookeper,后台的业务层都发布到zookper注册中心去了,dubbo是对zookper的一个管理,就像Apache对tomcat管理一样,就像卡车上装着很多桶水一样的道理,redis缓存框架也不是特别了解,因为涉及实时入库,不断更改次数的操作,担心锁表,所以用到了redis,当时有个技术人员负责搭建框架,一个人负责测试环境的准备,我依旧负责表机构设计,和每个人分工,并写了一份开发文档,具体到每个人做的功能,涉及的表,因为开发者不需要了解需求,我只能需求转化为概要设计说明书。


3.项目开发

   说到项目开发,我自己也参与了项目的开发,不过我是纯后台的,不涉及到页面的展示,但是如果真正做一名项目经理,亲身经历告诉自己,不要参与开发,项目经理的任务就是将表结构设计好,概要设计写好,在项目开发的过程中,帮助他们弄懂需求,当涉及到与其他系统接口交互比较多的时候,协调能力是解决项目的关键,说实话,白天沟通,晚上写代码这种情况就是我的写照了,不是因为太累,而是因为人的精力是有限的,到了晚上写出来的代码出错的几率很大,但由于项目成本的原因的,一个人身兼多职也是很正常的。项目开发一个月就结束了,这时候才真正体会磨刀不误砍柴功,需求很重要,设计很重要。


4.测试上线

  测试上线阶段其实特别关键,对于测试人员这个阶段比较痛苦,尤其是bug很多的时候,但对于开发人员相对前期有个缓冲期,测试的时候不仅仅要考虑功能,考虑浏览器

,考虑用户的体验,但很多开发人员是根本不会考虑的,如果开发人员能考虑到这一点就完美了

5.风险

很多时候任务由于种种原因没有按照规定的期限完成,服务器没有下来,与其他系统交互的时候,其他系统未按时上线,影响了本系统

6.系统交互

一般情况下接口调用能力开放平台,调用计费,然后计费将渠道号和客户标识同步给CRM