仓库源文站点原文


title: "互联网产品开发流程" date: 2017-09-04T15:12:00+08:00 tags: ["总结", "项目管理"] draft: false

toc: true

引言

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

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

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

产品开发流程

<!--more-->

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

互联网产品角色

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

  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. 计划表就像积木(做计划表,排优先级,时间不够就砍掉不重要的功能)

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

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

总结

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