谈谈项目进度规划
产品发布
熬了两个月后,新版App终于发布,iOS版和安卓版,这比之前的进度延迟了整整一个月,原计划一个月完成。尽管后期产品不在我的掌握之中,但作为产品经理,无论如何都要挂念着这事情,费尽心思设计的产品,表达的理念,从友盟3000多条用户反馈的逐条查看,从市面上40多个竞品的研究把玩,从之前对产品的积累理解,到抽取出用户需求和产品需求,确定了产品的核心功能并绘制出产品线框图;从刚进团队的陌生感,工程师对产品设计的不理解和质疑,到最后用事实和道理,沟通和诚意取得他们的信任。这两个月的时间,确实学到了很多,做产品的,沟通的,项目管理的,公司文化的,自己理解的,种种N多。最近刚好看完项目管理的经典之作《人月神话》,趁着记忆尚存,就结合这两个月的产品开发谈谈项目管理。
项目延期
《人月神话》中提到这样的场景:想象一下,史前巨兽在焦油坑中垂死挣扎,越是挣扎越无法逃脱,最终沉入坑底。
App在3月初启动,到了25号进度出现了延迟迹象,由于另外的原因,在4月初到4月20号这段时间,我置身其中,真切感觉到项目的进展真如史前怪兽般在苦苦挣扎,UI设计人员、开发人员在一些早前已经确定下来的视觉和功能上不停返工折腾,时间每一天在耗去,看似每件简单的事情都不需要过多时间,但是当许多杂碎的小改动纠缠和汇集起来的时候,事情开始变得不可控制,时间的延迟也就情理之中了。
回头来看,项目一开始的进度计划就已预埋延期的种子
众多软件项目中,缺乏合理的时间进度是造成是造成项目滞后的最主要原因,它比其他所有的因素加起来的影响还大
书中提到了以下几点原因:
- 对估算技术缺乏有效的研究
- 错误假定人和月可以互换
- 软件经理不会持续有耐心的估算
- 对进度缺少跟踪和监督
- 当意识到进度偏移时,下意识地反应是增加人力
对照一下,1、4和5的错误我们犯的最明显
对于第1点
首先,项目估算时间不是基于团队沟通结果的。3月初估算项目时间,主管先提出自己的看法,认为一个月的时间足够,iOS工程师A和Android工程师B在接受到这个信息的前提下,不敢或者没有准备充分的理由来提出不同意见,产品经理在有限的理解(对两位工程师,iOS版是A一手一脚做出来的,A有三年经验;Android版之前是外包的,现在B接手,B是刚毕业的学生)下,提出iOS和Android的时间应该有所区别,至少要考虑到Android的实际情况,但是主管认为所谓的新版没有新增功能,只是界面修改,工作量并没有多少;
其次,关于期限一个月,产品要做到哪个程度,没有明确。 按照《人月神话》的提法,一个月后是程序?编程系统?编程产品?还是编程系统产品,制定计划时没有提及。简单点说,一个月是产品开发出来,还是已经通过QA测试,还是已经发布了?没有明说,这直接导致主管和产品经理在后期看法的冲突;
再次,对项目时间的估算不是基于细分功能点和交互的,只是一个笼统的猜测。会议上没有将项目的各个功能点罗列出来,也没有考虑到功能之外的各种交互需要时间,也没有考虑到UI设计icon需要的时间,也没有考虑到QA测试需要的时间,也没有考虑到工程师修复bug需要的时间,总之,没有细化的估算,只有笼统臆测
对于第4点
项目没有制定里程碑,是导致我们App延迟的重要因素之一。 当iOS进度顺利时,没有有效的监督和追踪,导致iOS工程师有所懈怠,认为事情做得差不多,实际上从用户体验的角度看,还有许多细节需要改进,这无关功能,但确实需要耗费时间;而Android这边,由于没有追踪和监督,导致主管和产品经理不清楚具体进展到哪个程度。
产品功能优先级别没有界定。 既然项目管理需要监督和追踪,自然要有可监督和追踪的产出物,但我们没有,某个时间点需要完成那些功能,哪些功能需要优先处理,UI需要在哪个时间点出哪个页面的视觉方案,这些在制定项目进度的时候都没有纳入考虑
对于第5点
当项目进展过去20多天,主管直接介入UI细节,修改推翻了一些之前确定的功能、视觉和交互,并增加了一名Android工程师,期望能加快项目进度,事实却是适得其反。
向进度落后的项目中追加人手只会使项目更加落后
无论多少个母亲,孕育一个生命都需要十个月
原因由以下几点
- 新增人手本身的经验不一定能加快项目进展
- 新增人手需要额外的沟通和培训
- 新增人手对项目中不能分解的任务无法提供帮助
反观我们的问题,主管并不懂UI和设计,很多时候是个人意见主导,不停要求UI和iOS修改,返工问题严重;后期加入的Android工程师经验相对丰富,项目中刚好有可以分解的任务给他接手,但是前期也需要时间熟悉代码,也需要和团队其他成员沟通,尤其是跟原来的Android程序员,这也一定程度上拖延了Android的进度,总的来说,新加入的Android程序员还好起到了推动作用,但是是在项目延期一个月的情况下。
对于软件进度的安排,《人月神话》的作者给出了自己多年的经验法则:
1/3计划
1/6编码
1/4构件测试和早期系统测试
1/4系统测试,所有的构件已完成
看出来,我们之前的进度安排如何糟糕,计划就一个会议的时间,一个小时不到,编码占据了90%以上,测试不到一周,不得不承认,这样的进度安排无疑是失败的。
项目的时间依赖于顺序上的限制,人员的数量依赖于单个子任务的数量,从这两个数值可以推算出进度时间表
总结
合理的项目进度计划的产生,应该是由项目经理、产品经理和技术人员共同沟通的结果,绝不是一言堂拍脑袋决定的;产品经理定义好完整的PRD文档,技术经理根据PRD文档的需求转为技术上各个功能点的描述,由架构师和工程师共同评估每个功能点需要的人日,最后由项目经理根据评估时间的关键路径制定项目进度,这才是最基本的流程方式。至于项目经理和产品经理是否同一个人,这个人的水平如何,制定的计划是否合理,对需求变更如何控制,那就另当别论了。但如果连个基本的流程都没有,随随便便就能制定出项目进度计划,那项目的后果就如焦油坑里挣扎的巨兽,最终沉入坑底了