推荐理由：适合人群：资深产品经理。

阅读耗时：字数2628，约7.5分钟。产品经理在敏捷开发中，占据着重要位置，其中参与引导和开发评估非常重要。本文提供部分方法论，很值得借鉴。欢迎想引入此套方法论的你，和我沟通，我们共同策划更好的方案。

一、产品经理在开发评估会议中的定位

在评估会议上，开发团队会对本期需求制定实现方案，并会根据方案的难易程度评估具体每个开发活动的开发时间。

因为评估会议代表整个开发工作的起点，只要评估得准确，那么后续按照计划执行即可，能够减少很多风险。

二、会议前

1. 对本期需求拆解详细的WBS

需要通过一种结构化的方式全局呈现需求，这种方式就是WBS，也可以理解为详细的功能列表。

给产品经理自己看的功能列表会相对简单一些，只需写出大致的功能架构，为后续的原型设计提供指引。

而给开发看的WBS则需要遵循MECE原则，将各功能分解地很详细，并且需要把重要的规则补充完整，这样有助于开发进行评估。

这是由于两者的形式决定的，WBS相比PRD直接和结构化。PRD文档包含了很多内容，产品经理自己写都需要花很久，开发同样需要花很长时间阅读。其次文档形式不便于直观地看出各功能的层级结构，难以形成前后联系。

2. 提前安排开发负责人制定初步开发方案

会议是决策，而不是讨论。

开发评估会也是同样的道理，当面对较复杂的设计方案时，作为引导者，要避免开发在会上就某个需求的实现方案进行讨论。

一个切实可行的做法是在会前，同相关负责人直接沟通，请他们提供一个或多个初步方案，再拿到会上由全体开发进行决策。

3. 促使信息对齐

主要目标是解决成员间信息不对称的问题。这里我提供一个经过实践验证的、确保大家信息对齐的方案，可以用到各种会议中去，也可以根据实际情况进行调整：

将所有资料和解释说明通过小D打包发给相关团队成员，并督促未查看的成员查看；

在会议前1天，要求各成员针对会议资料必须给出反馈意见，并收集留档；

提前解答大家共同反馈的疑问；

在会议开始前，准备纸质版资料，最少要能保证3人共用一份；

若会议前临时有人员变动，或前期准备时间不充足，可在会前加入静默阅读的方式。

三、会议中

在开发评估会议中，主要包括三个环节：①确定开发方案；②分解开发活动；③评估活动时间。

1. 引导开发正确分解开发活动

分解是产品经理必备的一种思维，上到业务目标，下到产品功能都需要分解成可执行的最小单位，开发评估工作亦是如此。

要想解决这一问题，要从思想上转换：功能是设计方案可分解的最小单位，而开发方案的最小单位是一个个的接口。

此时要引导开发继续分解到接口层面：

对设计方案做整体介绍；

带领开发对WBS中的每个功能/功能组梳理逻辑；

引导开发利用MECE原则列出所用后端接口；

讨论接口细节；

确定前后端开发活动（任务）。

2. 引导开发准确评估活动时间

这样做会出现两个问题：

评估人员和实际开发人员不一致，可能造成实际工时的偏差。开发负责人是基于自己的经验去评估的，没有考虑实际开发人员的情况。

这里我提供一个高效率进行群体决策的工具——估算扑克，产品经理可以用其引导开发准确评估时间。

1）什么是估算扑克

估算扑克是一种迅速而精准地进行评估和规划的工具。

和普通扑克牌一样，也是由54张牌组成，两张大小王分别用中英文描述了使用规则，剩下52张牌分为4组，可供4人使用，每人13张，由11张数列牌、1张“？”牌和1张“咖啡”牌组成。

“？”代表无法准确评估，“咖啡”牌代表要休息了。

数列牌可以是自然数排列（0-10），也可以是修正后的斐波纳契数列，其中0代表非常简单，不需要精力就能完成。

2）数列的含义

扑克上的数字可以代表“工时”，也可以代表“故事点”。

代表工时很好理解，即估计每个开发活动需要花费的小时数，是目前使用范围最广的方式。

评估前需要定义一个单位工作量——故事点，实际中，可根据团队情况选取数列表示的含义，也可并行估算。

3）估算工时步骤

分牌：为每名参与估算的成员分一组牌；

讲解：产品经理为大家讲解需求并答疑；

估算：仅与该活动有关的开发成员估算工时，如针对“交卷”接口，由全部后端评估工时。
待每个成员选好牌后同时展示出来，估算过程不可互相商讨；

若大家的估算结果相近，取平均值；

4）估算故事点步骤

由于故事点指的是工作总量，单独对任意一个前后端任务评估都不完整，且不好统一定义单位故事点。

因此基于故事点估算的步骤会与工时估算稍有不同，主要提现在评估对象不同和确定单位故事点。

（1）关于评估对象

故事点代表了一个最小的、完整的功能所需的所有工作量，一个交卷接口不算完整。

一个涉及到前后端的交卷功能才算完整。

所以故事点的评估对象是一个完整的功能，同时在评估时还要考虑影响该工作量的所有因素，包括开发、联调、风险点等。

（2）关于确定单位故事点

如果是刚刚建立的新团队，在进行估算前，还需要寻找一个标的，建议团队选取一个简单的功能闭环代表1个单位故事点，并要达成共识。

按故事点估算步骤可分为：

确定单位故事点；

分牌；

讲解；

多次估算：仅与该功能有关的开发成员进行估算；

记录估算结果。

5）并行估算

根据前面的介绍，不难看出故事点估算侧重于对整体的评估，关注结果，而工时估算侧重于对细节的评估，关注过程，两种估算方式互为补充。

3. 开发活动分配和筛选

接下来就是由开发负责人将这些任务合理地分配给各成员，成员也可以主动认领，产品经理无需干涉这一过程。

如果按工时估算，一般会给每个成员分配的活动时间占总工时的80%，剩下的时间留作应急。

4. 会议通用

1）把控会议进度

控制会议整体时间：一次会议最好不要超过90分钟，若需求过多，可拆分为多次会议；

控制会议各环节时间：拆解开发活动时可能会遇到无法达成一致的情况，要及时引导大家转入下一个议题；

控制讨论内容：开会时很容易讨论着讨论着就跑偏了，需要及时制止这种情况并把话题带回来。

2）做好会议记录

安排人员记录会议过程中的确认事项、待办事项，并整理产出文档。

四、会议后

1. 跟踪遗留问题

如果记录了一些待办事项，会后要组织相关人员进行落实，做到事事有结果。

2. 跟进开发过程

如果团队中没有项目经理，那么项目跟进的工作就需要由产品经理负责。

通过前面的评估会，我们可以得到已经确认的开发活动、开发时间和开发人员，接下来就需要把这些内容做成可视化的图表，便于跟踪和查看，目前常用的有甘特图和项目看板。

读后感

往往评估时间的确定非常重要，通常都是由客户的需求决定的，遇到最多的情况是不懂的人来评估时间，懂的人往往给自己的余量特别多。本文中提到的平均法值得借鉴。如果你试的好，记得告诉我。

Powered by Froala Editor