项目管理的一些思考

现状

俗话说家家有本难念的经,每个公司的情况都不太一样,当你的团队遇到项目管理问题时,通常会怎么做?看了很多关于瀑布流、敏捷开发、迭代式开发模式的文章、讨论,没有一个能套到自己身上。

目前团队采用的管理模式类似于 scrum,以一个季度为一个迭代,每两周为 1 个 sprint。迭代第一个 sprint 通常会进行需求讨论+产品设计+技术优化,第二个 sprint 开始进行功能开发+上个sprint的质量保证+下个sprint的需求讨论产品设计。

现状

这个流程执行下来遇到的问题有几个:

  1. 功能优先级高,要等产品设计敲定
  2. 功能复杂度高时容易跨 sprint
  3. 功能开发完没有总结完善过程直接进入了下一个功能开发
  4. 季度为单位的时间周期太长,无法做到真正的时间控制

每个 sprint 的任意功能延期就会产生蝴蝶效应,迭代末期留给 full testing 的时间会非常少,不得已就整个迭代延期。

优化

优化方案是以时间控制为目标,将需求讨论与产品设计挪出 sprint 管理流程。 sprint 作为内部管理的一个小迭代,只控制功能开发+质量保证的时间。假设 sprint 以两周为单位,那么 PM 主要抓这两周内的开发任务队列的进度,风险与功能质量就非常可控了。

优化后总体上会分为两个队列:

  1. 功能设计 ready 队列
  2. sprint 开发+质量保证队列。

功能设计好后会进入 ready 队列,按优先级进入下一个开发 sprint。产品和商务需要在下一个开发sprint之前开会定好优先级,以两周为单位后开会速度、效率也能提高,响应客户的速度、客户的满意度理论上都会提高。

功能设计队列由产品经理推进,与商务需求讨论制定功能优先级。完成设计的进入 ready 状态。

ready-queue

需求评审由商务与 PM、产品经理、Tech Leader参加(会上直接砍掉不合理的、不会做的)。
原型评审由产品经理、Tech Leader 参加(评估设计方案)。
设计评审由 PM、产品经理、Tech Leader参加(评估开发时间,超期砍功能、重新评估设计方案、加人力)。

sprint 开发队列的模式是从 ready 队列按时间排期进入当前 sprint

sprint-dev

形成循环后就达到了 scrum 理想的样子。

大版本迭代还可以继续以季度为分割,可以交付给客户的就是 N - 1 个 sprint 所交付的内容,第 N 个 sprint 的交付物不会包含在大版本中,第 N 个 sprint 的时间内 QA 需要做封板测试。

那么流程改变后研发侧需要做什么

研发 leader

tech-leader

研发

developer

测试

qa

下一步

等流程跑通跑顺,就做到了 scrum 敏捷开发,抛开大版本以季度为单位的发版,每个 sprint 的交付物都应该做到可以直接交付客户,那即是理想状态。