引言
我们在开发项目的第二个版本接近尾声的时候，出现了两个主要问题：
- 项目的延期。
- 产品需求没及时更上，导致开发有几天的工作只是修改 BUG、优化代码，无其他事情可做。
这两个问题出现之后，我们跟老板开会讨论，然后疏通了一些开发流程，这些流程之前一直被我们所忽视。下面我就总结和分享一下这次的「经验教训」吧。
产品开发流程
先说说我认为一个最小的互联网团队有哪些职位吧：
- 一个 CEO
- 一个 CTO
- 一个产品
- 至少一个 UI
- 至少一个开发
- 至少一个测试
不同的职位扮演着不同的职责：
- 产品经理负责跟老板索要需求，然后整理需求，输出需求文档和原型图，UI 可以配备给产品，配合产品把原型变成高保真的效果图。
- 技术主要是负责实现需求，把产品经理给的需求实现功能，根据产品需求的详细程度和功能多少，这个过程可能是漫长的，也可能是很快的。开发期间，对需求有疑问的地方，可能需要产品经理的配合。
- 测试的职责是保证产品最终给到用户的质量。技术人员开发完成所有需求，自测完成之后交给测试人员，然后测试人员根据产品的需求来验证结果。这个期间可能需要开发人员配合修改 BUG，对需求有疑问或者分歧的地方需要产品经理配合。
- CTO 的职责是调配资源，保证项目进度，解决项目中的各自疑难问题。如果人员不够的情况下可能还需要亲自上。
目前我们也是尽量按照以上职责来进行的，但是有一个问题被我们忽视了，那就是整个流程的运作。放大视野：
- 产品经理在规划好一个版本（我们暂且叫 V1.0）的时候，输出了产品文档和原型之后，紧接着他的主要职责就是收集新的版本（可能是 V1.1）需求，他的「副业」可能就是配合开发和测试等有需要的工作。
- 等产品经理准备好需求和原型之后，召集技术开发人员和测试人员，开需求评审会议。会后可能会有小的调整。把调整好的需求文档和原型发给测试和开发之后 V1.0 版本开始进行开发阶段。
- 技术接受到任务之后，开始认领工作，然后细分任务，给出合理的排期，才真正开始进入写代码阶段。
- 在开发接近尾声的时候，产品经理整理的需求也应该接近尾声了。
- 开发把功能全部开发完并且自测完成之后，V1.0 进入测试阶段。与此同时，V1.1 版本的产品原型和需求文档应该是准备的差不多了，然后开始着手准备开 V1.1 的需求评审会议了。
- V1.0 版本测试通过之后，就准备上线了。V1.0 上线的时候，V1.1 开发应该接近尾声了。
说了以上这么多废话，总结下来就是 - 正常情况下的的开发流程，应该会有 3 个版本同时在运行。
经历了这次事件，我才对此有了认知。
项目管理
《软件随想录 卷一》 这本书有一篇文章是《轻松掌握软件开发进度》，这篇文章写于 2000 年 3 月 29 日。文章总结了这几点：
- 使用微软 Excel
- 保持简单
- 每个功能点应该分成几个子任务
- 只有负责写代码的程序员本人才能准确预估时间
- 适当细分任务，保持适合的颗粒度（每个任务的耗时应该在 2 小时到 16 个小时之间，如果超过这个范围说明你的任务还可以再拆分）
- 记录原始和当前的时间估计
- 每天更新「实际用时」一栏的值
- 把休假和节日等也考虑在计划之中
- 把调试代码的时间也考虑在计划中
- 把集成也考虑到计划表中
- 把缓冲时间也考虑进计划中
- 永远不要让开发经理压缩程序员预估的时间
- 计划表就像积木（做计划表，排优先级，时间不够就砍掉不重要的功能）
根据以上几点再结合我们现在的项目管理，我来谈几句。
- 我最讨厌的是 Excel，觉得比较臃肿。再一个就是这几年国内的项目管理已经有好多可以选择了，我用过的就有 teambition、tower、worktile、tapd 等等。我认为其中 tapd 最为复杂，功能比较强大，一旦用过之后，觉得其他的项目管理的功能过于简单，无法满足使用。所以我们现在用的就是 tapd，出自腾讯的敏捷开发项目管理。
- 不使用 Excel 来管理还有另外一个原因，无法多人协作使用。不过现在好像也可以通过石墨，Google docs，一起写 来实现了吧。没实践过。
- 以上几点被我忽略的是「6. 记录原始和当前的时间估计」，不过这次已经做了调整。
- 书中介绍的是按小时评估任务时间，而我们还是按日期来评估时间，最小时间单位是半天。
- 之前总是忽略测试给出的时间，按照自己的认为的测试时间向上汇报的上线时间，结果导致了延期。 所以「只有负责写代码的程序员本人才能准确预估时间」，是非常重要的。
PS：顺便再吐槽一下 tapd，使用期满 6 个月才有资格申请开通「全周期敏捷研发」，本来想使用个甘特图都不行。
总结
以上就是因为一次项目延期事件，我们复盘的结果。我们主要从「产品开发流程」和「项目管理」两个方面找到了以下几个问题：
- 产品需求没更上开发，导致项目开发脱节，而市场又急需上线新功能，产品需求的延期会导致剩下的环节全部延期。同样的技术开发的延期也会导致剩下的环节全部延期。
- 项目进度的把控，怎么做到项目的不延期？即使延期也要在可控范围之内（最多 1-2 天的延期）。项目的排期是一个非常重要的环节，要做到每天更新「实际用时」一栏的值，做到及时反馈，进而不断提高自己排期的准确性。
- 原文作者： forecho
- 原文链接： https://blog.forecho.com/internet-product-development-process.html
- 版权声明：本作品采用 署名-非商业性使用 4.0 国际 (CC BY-NC 4.0)进行许可，非商业转载请注明出处（作者，原文链接），商业转载请联系作者获得授权。
