产品发布
熬了两个月后，新版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文档的需求转为技术上各个功能点的描述，由架构师和工程师共同评估每个功能点需要的人日，最后由项目经理根据评估时间的关键路径制定项目进度，这才是最基本的流程方式。至于项目经理和产品经理是否同一个人，这个人的水平如何，制定的计划是否合理，对需求变更如何控制，那就另当别论了。但如果连个基本的流程都没有，随随便便就能制定出项目进度计划，那项目的后果就如焦油坑里挣扎的巨兽，最终沉入坑底了
