项目管理 腾讯 PM 教你六步开好迭代会

redmine · 发布于 2017年10月31日 · 6 次阅读
96
本帖已被设为精华帖!

说迭代计划会前,我觉得团队应该创建多层计划,不但要有一年的粗略的产品计划,也要有一份详细的下个迭代的可执行计划。

大家看上图,是不是看着像一颗洋葱,这个图叫洋葱计划图。战略目标在最外层,由外向内不断切分这个外围的目标,最终切分成最小周期的可行性的迭代计划。这个就是我上面说的多层计划?那为什么要多层计划呢?在我们的业务面对不可预期的用户需求时,制定长的周密的计划,会出现频繁的变更;而我们在制定近期的迭代计划的时候有时候会偏离我们最开始的目标,所以基于上面两点,制定上面这种洋葱计划,基于目标进行层层分解,保证不偏离目标,由外向内逐渐细化,计划也能更灵活。从传统项目的单个计划转向多层级计划。从一次计划转向到多次计划。

迭代计划会议6步法

迭代会议最终的输出物是迭代计划,那迭代会议上,我们要做哪些事情呢?我总结主要有这下面6个要点(有些要点可以在迭代会前来进行,这里就简化些,不做区分了):

团队参与

我们传统项目管理,制定迭代计划,都是项目经理或者项目经理跟核心成员共识计划,然后分配给对应的同学。现在我们要团队所有人一起参与迭代计划的制定。因为实际做事情的同学才知道这个工作我需要花费多长时间,能不能完成。而且由他在会议上自己做出承诺,更有仪式感。

确定优先级

  • 我想用4W1H的方式说明下优先级: What——什么是优先级? 是一种内部规则的约定,高优先级的代表要先做,低优先级的后做。

  • Who——谁来确认优先级? 产品特性的优先级,一般由产品负责人决定。

  • When——什么时间确认优先级? 迭代会议前,产品负责人需要对需求池的需求进行梳理时,明确哪些是高优先级的需求,哪些是低优先级的需求。并把低优先级的需求放到下个迭代待排期的列表里。

  • Why——为什么要确认优先级? 需求池里那么多需求,但是迭代周期和人力是固定的,在下个迭代先做哪个,不做哪些,我们需要有一个标准规则来决定,优先级就是这个丈量的规则。

  • How——确认优先级的方法? 产品特性的优先级,可以通过kano模型来决定,就是如下这个图。这个属于产品范畴,这里不多介绍。

除了考虑产品优先级外,仍需考虑下面几点(包括不限于下面几点):

  • 依赖性:就是这个需求是否有前置需求,必选前置需求做完,才能启动后面的需求,那前置需求优先级会较高。
  • 完整性:就是这个需求做完,能让一个功能体验比较完整,如果不做,或造成功能体验的缺失 。
  • 紧急性:紧急程度的来源有很多,如运营活动的时间安排、老板的需求、用户的强烈要求等等。
  • 投入产出成本:如果一个需求需要花很少的时间就可以完成,虽然不是核心路径下的需求,有时候优先级也会比较高;
  • …… ## 需求分解 需求分解的颗粒度更小,越容易做估算,排期计划才更准确。需求分解可以从这两个层面来做:一个层面是按照需求生命周期来分解,可以分解成交互、设计、前端、后台、测试等;另一个层面按照交付分解,如一个功能可以分解成更小的功能(如下图)。这两种分解可以单独使用,也可以混搭。

团队估算

估算有很多方法,通常有对比估算、专家估算、故事点估算。我这里不想说方法,只想从实操层面来说,如果估算成员越了解需求细节,那估算的准确性就越高。所以一般评估前,最好有一个需求讲解会。当然这个主要也要看团队的成熟度和默契度,如果团队成员足够牛,从产品经理一句话就能评估工作量当然最好;如果团队做不到,那就需要在评估前,有详细的需求文档,甚至带有交互图或者视觉图的产品文档,需求越详细,评估才约准确。

完成标准

通常我们迭代都是有固定周期的,那一个周期里,不是所有需求都能开发完上线的(如前端后台类的业务),所以我们定义特性的完成标准,如设计完成、开发完成、测试完成、灰度上线、全量上线等。通过定义完成标准明确我们各个阶段的验收要求。

任务分配

需求分配的原则:就是尽量把需求分配给最熟悉该需求模块的人。当然比较鼓励主动认领,让开发做自己感兴趣的需求,这样积极性和热情比较高。不过不太好操作,需要团队培养这样的氛围,另外对团队能力要求较高。

共收到 0 条回复
32 redmine 将本帖设为了精华贴 10月31日 11:45
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册