做计划的前提是项目经理或者研发组长一定要对自己要做的东西十分了解才行,要做那些东西,这些东西有那些难点,那些地方可能出问题,谁来做比较合适,如果让他做的话需要重点监督那些地方。这些东西都要做到有谱才行。这也是为什么在产品设计和落地里说要让项目经理来整理原型详细说的原因。
通过产品设计就可以形成模块--功能菜单---功能点的三级详细说明,配合框架提供的用户、角色、权限、组织机构功能。这样一个应用系统基本就已经能够成型了,计划只要给这些东西按照他们的依赖关系来分配负责人和时间就可以了。整个开发需要做两个计划,
主计划
主计划,主要关注模块的时间节点以及配合部门的入场出场时间。按项目的开发周期可以分为开发准备、开发、测试封版期三个阶段。
开发前期的技术准备主要是做一些技术方案的确定、技术点的预研以及原型详细说明的整理和讨论。另外这个阶段应该要准备一份比较重要的文档《开发基础准则》主要说明一些通用的UI、开发、数据库设计准则,如查询条件必须出现在列表上、字符串类的查询必须模糊查询、每个模块的简称等等,这个文档应该在不晚于正式开发前提供。这个阶段的特点就是时间上有很多不确定的地方,技术方案的的制定需求的讨论需要开会讨论,且会议参与人员会牵扯到不同部门的不同岗位,能把会议组织起来就不是一件很容易的事情。而技术点的预研也有很大的不确定性。所以这个阶段的计划为了增加时间的紧迫性开始时间和截至时间应该尽可能的提前,实际执行时间可以延迟。它的最终形式应该如下图:
开发期的计划主要以模块为单位进行划分就行了,原则上一个模块一个人负责,但为了团队成员快速熟悉开发环境,基础模块可以平均分以下。这个计划里第一件事要是需求fix,就是把项目经理整理的原型详细说明组织会议,进行逐条讨论,由开发人员做会议记录,将讨论的东西记录到原型详细说明上,形成一个fix的需求文档,这个文档就可以用于指导开发和测试了。还有一个是DB结构的fix,这个如果开发成员足够值得信任的话可以到开发阶段在进行,但需要注意一些跟别的模块有业务牵扯的数据表应该尽早设计出来,以免影响其他模块的进度。它的最终形式大致如下:
测试计划就是按期提测就行了,这里计划最好做两轮。
开发详细计划
开发详细计划的制定相对来说就比较简单,繁琐了。把需要做的页面按开发顺序和负责人排好,然后对着日历安排开始和结束时间就行了,安排的时候一定要注意节假日,以及可能的请假,对于请假一般按一个人三个月请两天就够了。在制定详细计划的时候有几条经验可以建议一下。
1、按说计划的时候需要开发人员预估一下,但这一步完全可以去掉,项目经理自己估算就可以了,不会有太大的误差,在有现成开发框架、主要技术难点已经预研的情况下,工作量不会太难估算,也不会有太大误差。另外大家低头不见抬头见的,谁还不知道谁那点事,什么人能干什么活,大家心里都懂。就算是新人,业务开发也就是那么点事情,给个页面熟悉下流程基本基本上也能保证开发进度了。
2、定详细计划的时候,因为在主计划里模块的截至时间已经确定了,所以也就是按这个时间去反推了。有个大致的公式可以参考一下,60%(需求确认开发)+20%(自测)+20%流动。比如一个页面,估算的是4天,首先就要拿出来20%也就是0.8天四舍五入就是1天作为项目经理流动时间。剩下的3天才是体现到计划里的,在填报进度的时候第一天差不多就得完成40%,第二天差不多是80%,第三天是100%,这样大致能保证第三天的自测时间。
3、流动时间按20%算的话,一个月按22天工作日计算,差不多是4天的时间,这四天基本就是用来应对请假、变更、计划的延迟了。但这个时间是不能以单列的形式体现在计划里的,不然肯定会被领导划掉的。应该找一些看着复杂但实际很简单的页面来分散安排,比如一个页面实际计划是2天,可以给三天。但一定要提前说明,帐要算明白,不算明白肯定会被开发占便宜的。这样的计划不要连续在一起排,最好是隔上两三个比较紧张的页面,安排一个这样的页面。
4、计划的时候要考虑一下比较长的假期,五一,十一,春节,尤其是春节对于一个项目的连续性来说太致命了,春节开班后好几天都很难进入状态。这样排计划的时候最好在假期前安排的紧张一些,甚至可以安排到从计划看不加班都不行的程度。假期后可以适当轻松个一两天。
详细的计划反馈到文档上大致就是这个样子了。
开发过程的监督
做好详细计划后进度的监督相对就比较简单了,每天下班的时候让每个开发人员填报一下进度和完成度就行了。自测的监督就比较困难了,目前都没有找到很好的办法。目前的做法是。
1、开发前确认,在开发人员进行页面开发前,项目经理要和开发对照原型详细说明过一遍,主要是从技术难点、逻辑上需要特殊注意的点以及和别的模块有交互的地方需要怎么做。这些东西都确认好以后再去开发,一个页面也用不了几分钟。
2、在开发人员完成一个页面后去看他的测试数据,如果只有一两条肯定是有问题的,数据比较乱比如大量的aaa,bbbb和重复数据也会有问题。然后再去关注一下状态字段是不是每个状态的数据都有,和别的模块交互的地方,交互的数据是不是自己添加的还是用的别人的数据。
3、把页面上的功能简单点一下,重点关注数据规则验证,和别的模块交互这些开发前确认的东西。
上面三点只能保证发现问题,但是发现问题的时候都是计划的时间用完的时候,发现的问题以后还得分配时间改。最主要的是要培养开发人员培养自测的习惯,至于怎么培养,我也没找到很好的办法,现在能做的就是经常说,反复的说,需求确认的时候说,review代码的时候说,测试发现Bug的时候说总有听的,如果无论怎么说都不停的,项目经理总会有用和不用的权力。
网友评论