forecho

把生命浪费在美好的事物上

互联网产品开发流程

2017年09月04日

引言

我们在开发项目的第二个版本接近尾声的时候,出现了两个主要问题:

  1. 项目的延期。
  2. 产品需求没及时更上,导致开发有几天的工作只是修改 BUG、优化代码,无其他事情可做。

这两个问题出现之后,我们跟老板开会讨论,然后疏通了一些开发流程,这些流程之前一直被我们所忽视。下面我就总结和分享一下这次的「经验教训」吧。

产品开发流程

先说说我认为一个最小的互联网团队有哪些职位吧:

  • 一个 CEO
  • 一个 CTO
  • 一个产品
  • 至少一个UI
  • 至少一个开发
  • 至少一个测试

互联网产品角色

不同的职位扮演着不同的职责:

  1. 产品经理负责跟老板索要需求,然后整理需求,输出需求文档和原型图,UI 可以配备给产品,配合产品把原型变成高保真的效果图。
  2. 技术主要是负责实现需求,把产品经理给的需求实现功能,根据产品需求的详细程度和功能多少,这个过程可能是漫长的,也可能是很快的。开发期间,对需求有疑问的地方,可能需要产品经理的配合。
  3. 测试的职责是保证产品最终给到用户的质量。技术人员开发完成所有需求,自测完成之后交给测试人员,然后测试人员根据产品的需求来验证结果。这个期间可能需要开发人员配合修改 BUG,对需求有疑问或者分歧的地方需要产品经理配合。
  4. CTO 的职责是调配资源,保证项目进度,解决项目中的各自疑难问题。如果人员不够的情况下可能还需要亲自上。

目前我们也是尽量按照以上职责来进行的,但是有一个问题被我们忽视了,那就是整个流程的运作。放大视野:

互联网产品开发流程

  1. 产品经理在规划好一个版本(我们暂且叫V1.0)的时候,输出了产品文档和原型之后,紧接着他的主要职责就是收集新的版本(可能是V1.1)需求,他的「副业」可能就是配合开发和测试等有需要的工作。
  2. 等产品经理准备好需求和原型之后,召集技术开发人员和测试人员,开需求评审会议。会后可能会有小的调整。把调整好的需求文档和原型发给测试和开发之后V1.0版本开始进行开发阶段。
  3. 技术接受到任务之后,开始认领工作,然后细分任务,给出合理的排期,才真正开始进入写代码阶段。
  4. 在开发接近尾声的时候,产品经理整理的需求也应该接近尾声了。
  5. 开发把功能全部开发完并且自测完成之后,V1.0 进入测试阶段。与此同时,V1.1 版本的产品原型和需求文档应该是准备的差不多了,然后开始着手准备开V1.1的需求评审会议了。
  6. V1.0 版本测试通过之后,就准备上线了。V1.0 上线的时候,V1.1 开发应该接近尾声了。

说了以上这么多废话,总结下来就是 - 正常情况下的的开发流程,应该会有3个版本同时在运行。

经历了这次事件,我才对此有了认知。

项目管理

《软件随想录 卷一》 这本书有一篇文章是《轻松掌握软件开发进度》,这篇文章写于 2000年3月29日。文章总结了这几点:

  1. 使用微软 Excel
  2. 保持简单
  3. 每个功能点应该分成几个子任务
  4. 只有负责写代码的程序员本人才能准确预估时间
  5. 适当细分任务,保持适合的颗粒度(每个任务的耗时应该在2小时到16个小时之间,如果超过这个范围说明你的任务还可以再拆分)
  6. 记录原始和当前的时间估计
  7. 每天更新「实际用时」一栏的值
  8. 把休假和节日等也考虑在计划之中
  9. 把调试代码的时间也考虑在计划中
  10. 把集成也考虑到计划表中
  11. 把缓冲时间也考虑进计划中
  12. 永远不要让开发经理压缩程序员预估的时间
  13. 计划表就像积木(做计划表,排优先级,时间不够就砍掉不重要的功能)

根据以上几点再结合我们现在的项目管理,我来谈几句。

  • 我最讨厌的是 Excel,觉得比较臃肿。再一个就是这几年国内的项目管理已经有好多可以选择了,我用过的就有 teambition、tower、worktile、tapd 等等。我认为其中 tapd 最为复杂,功能比较强大,一旦用过之后,觉得其他的项目管理的功能过于简单,无法满足使用。所以我们现在用的就是 tapd,出自腾讯的敏捷开发项目管理。
  • 不使用 Excel 来管理还有另外一个原因,无法多人协作使用。不过现在好像也可以通过石墨,Google docs,一起写 来实现了吧。没实践过。
  • 以上几点被我忽略的是「6. 记录原始和当前的时间估计」,不过这次已经做了调整。
  • 书中介绍的是按小时评估任务时间,而我们还是按日期来评估时间,最小时间单位是半天。
  • 之前总是忽略测试给出的时间,按照自己的认为的测试时间向上汇报的上线时间,结果导致了延期。所以「只有负责写代码的程序员本人才能准确预估时间」,是非常重要的。

PS:顺便再吐槽一下 tapd,使用期满6个月才有资格申请开通「全周期敏捷研发」,本来想使用个甘特图都不行。

总结

以上就是因为一次项目延期事件,我们复盘的结果。我们主要从「产品开发流程」和「项目管理」两个方面找到了以下几个问题:

  • 产品需求没更上开发,导致项目开发脱节,而市场又急需上线新功能,产品需求的延期会导致剩下的环节全部延期。同样的技术开发的延期也会导致剩下的环节全部延期。
  • 项目进度的把控,怎么做到项目的不延期?即使延期也要在可控范围之内(最多1-2天的延期)。项目的排期是一个非常重要的环节,要做到每天更新「实际用时」一栏的值,做到及时反馈,进而不断提高自己排期的准确性。