7000字实例解析：产品经理如何正确参与并引导开发评估

人人都是产品经理 • 2年前扫码分享

我是创始人李岩：很抱歉！给自己产品做个广告，点击进来看看。

编辑导语：作为产品经理遇到的问题可谓是各式各样的，日常需要处理的问题也很繁多，本篇文章作者针对产品经理日常遇到的问题进行案例分析，讲述了产品经理应如何正确参与并引导开发评估的内容，一起来学习一下吧。

作为产品经理，你是否遇到过以下问题：

开发出来的功能和设计的规则不一致；
看起来很简单的功能开发评估需要好几天；
负责的项目经常延期；
不知道开发进展。

如果出现以上问题，80%是因为开发评估工作没有做好。

这篇文章将会结合笔者的实际案例，详细讲解如何解决上述问题。

注：本文讨论的内容基于特定的情况下，即团队中没有专职的项目经理/敏捷教练，需要产品经理兼任，即“保姆式产品经理”，同时产品经理的设计方案已通过评审。

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

在中小企业，特别是以敏捷开发为主的团队中，产品经理往往需要承担一部分项目管理的职责。

其中最重要的要属需求评审后的开发评估工作了（若需求较简单，可与评审会共同进行）。

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

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

可是现实情况却不尽人意，常常会遇到：

开发对功能规则理解有偏差；
需求遗漏或需求蔓延；
评估的工时和实际所用的工时差距过大。

并且这类问题往往在开发后期才会暴露出来，轻则导致改动方案，费时费力；重则导致项目延期，影响整体目标。

千万不要认为开发评估会是开发的主场，作为产品经理，需要对产品的结果负责，对于任何环节可能造成的风险都需要提前规避。

因此，在评估会上，产品经理不仅要做一个“ 倾听者 ”（了解技术实现方案）和“ 支持者 ”（对于开发不明确的地方提供必要的说明），更要做一个“ 引导者 ”。

虽不参与实际的开发决策，但需要在关键节点通过正确地引导保证评估过程的准确性。

这种积极的做法有以下好处：

降低项目开发风险；
建立与开发的信任；
从技术视角看待产品，了解开发知识；
锻炼领导力。

下文将会从会议前（准备）、会议中（引导）、会议后（监控）详细拆解每个步骤。

二、会议前

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

尽管经过需求评审会，团队成员已经对设计方案达成了共识，但仍不能保证每个人都记住和理解。

因此在开发评估会前，还需要通过一种结构化的方式全局呈现需求，这种方式就是WBS（工作分解结构），也可以理解为详细的功能列表。

对于产品经理，功能列表肯定不会陌生，在需求之后原型之前，我们就会通过功能列表梳理产品结构。

但此处的功能列表则需要拆解的越详细越好，因为它是给开发看的，便于他们对要做之事有一个整体的了解。

同时又可以避免需求遗漏、蔓延和理解不一致的情况出现。如同去菜市场买菜，相比于提前列出购买清单，如果是到了菜市场才决定买什么，那大概率会多买或少买。

这里我用曾经做过的在线答题功能举例：

7000字实例解析：产品经理如何正确参与并引导开发评估

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

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

比如对于“切换题目”功能，如果不写出“切换时需要自动保存答案”这一规则，前端人员仅看功能列表时就会忘记调用保存接口。

这里可能你会有不解：PRD也有详细的功能规则，为什么不用，而是要重新做一个WBS？

这是由于两者的形式决定的，WBS相比PRD最大的优势就是“直接”和“结构化”。

从下图可以看到，PRD文档包含了很多内容，产品经理自己写都需要花很久，开发同样需要花很长时间阅读（现实中更多的情况是开发不看文档，遇到问题了再问）。

其次文档形式不便于直观地看出各功能的层级结构，难以形成前后联系。

而WBS是将PRD中最重要的“功能需求”拿出来，并细化到最小功能点，做到了需求不遗漏，方便开发做后续的活动拆分（下文会说明）。

同时产品的架构、各功能之间的联系和关键规则都在一张表里展示出来，大大提高了阅读效率。

7000字实例解析：产品经理如何正确参与并引导开发评估

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

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

我们回想一下开需求评审会的场景，经常有开发对我们的设计方案提出质疑。

如果恰好是你没考虑清楚，那么你会选择跟他深入讨论，还是会说“这个问题问得好，我记下来了，会后我再好好想想然后答复你，我们先看下一项？”

我相信大家都会选择后面的方式，因为在会上讨论，不仅浪费他人的时间，而且讨论出的结果往往都是没有经过深思熟虑的。

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

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

例如我在设计阅卷规则时，不仅可按考生、试卷、题目分配，还可按试卷和考生、题目和考生综合分配。

同时试卷类型还包括选题组卷、抽题组卷和随机组卷，题目中还包含复合题，这都增加了开发在设计阅卷模型时的难度，可能还会改动已有的题库——试卷模型。

显然，这么复杂的方案不适合在会上讨论，于是我先后跟前后端负责人约了几次会议，形成了一个初步的方案。

这样做不仅保证了实现方案的完备性（作为负责人，经验和眼界都会高一些），同时减少了沟通成本（沟通渠道=N（N-1）/2，N指参与沟通者的人数）。

接下来再开评估会议，有了开发负责人的背书，就会顺利很多。

3. 促使信息对齐

经过前面的两步，你已经为评估会做好了资源上的准备，接下来你可能会把WBS、PRD、设计图、开发负责人提供的初步方案打包发给团队成员。

然后信心满满的准备开会。可是事与愿违，在会上你会发现，由于每个人所站的角度不同、高度不同，仍然有部分成员因为理解不一致而进行无效讨论。

因此在这个步骤里，主要目标是解决成员间信息不对称的问题。

这里我提供一个经过实践验证的、确保大家信息对齐的方案，可以用到各种会议中去，也可以根据实际情况进行调整：

将所有资料和解释说明通过钉钉打包发给相关团队成员，并督促未查看的成员查看；
在会议前1天，要求各成员针对会议资料必须给出反馈意见（无意见也要写明），并收集留档；
提前解答大家共同反馈的疑问；
在会议开始前，准备纸质版资料，最少要能保证3人共用一份；
若会议前临时有人员变动，或前期准备时间不充足，可在会前加入静默阅读的方式。

需要注意的是，心理学上有一个常见的现象——基本归因错误，即当我们对一个结果做因果分析时，往往会将原因归咎于倾向性因素（人格或态度等内在特质），而忽略外部环境的影响。

但其实环境才是影响人们行为的最重要的因素。

例如，如果你面对“仍然有部分开发成员因为不清楚需求而进行无效讨论”的情况，是不是第一反应是这个开发不认真、不主动。

但不妨换个角度想想，其实是目前的一种工作流程造成了他还不清楚需求。

人是制度的产物，改变人不如改变制度和流程，所以以上我提供的方法都是基于改变流程这一维度。

想更深入的了解这一心理现象，可查看我的另一篇文章《指责他人是愚蠢之举》。

三、会议中

经过了会议前三步的准备，团队成员对需求范围、设计方案以及初步开发方案都有了较深入的理解，接下来就进入到了正式开会环节。

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

后续开发过程是否顺利，是否能够按时按量完成，都会受会议中产出的结果影响，因此重要性不言而喻。

在开发评估会议中，主要包括三个环节：

①确定开发方案；
②分解开发活动；
③评估活动时间。

当需求较简单或开发方案没有争议时，可以跳过①环节，所以下文基于开发方案已确定的情况，主要对②③两个环节进行展开。

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

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

倘若你的团队没有这种“分解”意识，直接根据功能或页面进行评估，比如“下发试卷”功能：“需求是时间到后把试卷发给每一个考生，看起来比较简单，就估1人/天吧”。

但实际在开发的时候才会发现，之前没有考虑下发随机组卷这种类型的试卷，也没有考虑上万人同时发卷的并发问题，导致按照之前评估的时间完不成，进而导致延期。

要想解决这一问题，要从思想上转换：

功能是设计方案可分解的最小单位，而开发方案的最小单位是一个个的接口。

因此在评估前要做一件事：建立设计方案和开发方案之间的联系，这就需要在前面的步骤中我们已经做好的WBS。

还是拿“在线答题”功能举例：

虽然WBS已经把功能分解并按层级罗列了出来，但从开发的角度看还比较笼统，不能直接用于评估。

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

对设计方案做整体介绍；
带领开发对WBS中的每个功能/功能组梳理逻辑；
引导开发利用MECE原则列出所用后端接口；
讨论接口细节；
确定前后端开发活动（任务）。

如果前期的准备工作做的充分，这个过程会进行得很顺利，因为大家有共同的认知，容易达成一致意见。

允许对细节方案短暂讨论，比如对于倒计时提醒，可以采用后端提供服务器时间，前端定时校准并计算倒计时，也可以直接由后端计算。

但是涉及到模型建立、表结构设计、技术选型这类方案的讨论，还是需要在会前决定好。

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

分解好开发活动后，接下来就要对每个开发活动估算时间。

大家可以回顾一下在自己的项目中开发人员是怎么做评估的，我见过很多团队，基本上都是采用开发负责人拍脑袋的方式进行估算。

这样做会出现两个问题：

仅靠个别人员评估，可能造成评估不全面。例如试卷已生成，此时再改题库中的题目是不会影响试卷的，因此往试卷中添加题目时，需要存入题目的副本，对于这种细节单靠个别人员评估很容易遗忘。
评估人员和实际开发人员不一致，可能造成实际工时的偏差。开发负责人是基于自己的经验去评估的，没有考虑实际开发人员的情况。

因此要想准确评估开发活动的时间，全体参与是必须的。但全体参与又会带来另外两个问题：

因为每个人的经验不同、理解不同，如何就活动时间达成一致？
如何避免“从众效应”，导致估时不准？

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

1）什么是估算扑克

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

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

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

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

2）数列的含义

扑克上的数字可以代表“工时”，也可以代表“故事点”（敏捷开发）。

代表工时很好理解，即估计每个开发活动需要花费的小时数（允许组合，如1+1/2=1.5h），是目前使用范围最广的方式。

但这样做会有一个问题：每个人做一项任务所花费的时间都是根据自身情况决定的，比如挖一个10m³的坑，你需要用1小时，而一个小学生需要用8小时。

所以要如何评估挖10m³的坑所用的时间才合理呢？如果估1小时，显然对小学生来说不可能完成，如果估8小时，对你来说就是浪费时间。

我们无法让能力不同的人，就同一份工作的耗时达成一致，但可以做到对工作量大小的估算保持一致。

什么意思呢，不管谁来做这个工作，它的工作量、复杂度、风险都在那里，不增不减，因此可以转而评估工作总量。

评估前需要定义一个单位工作量——故事点，比如我们事先定义挖1m³的坑为1个故事点，那么对于10m³的坑就是10个故事点，

实际中，可根据团队情况选取数列表示的含义，也可并行估算。

3）估算工时步骤

分牌：为每名参与估算的成员分一组牌（13张）；
讲解：产品经理为大家讲解需求并答疑（若在上一步骤中已经详细讲解，本步骤可以省去）；
估算：仅与该活动有关的开发成员估算工时，如针对“交卷”接口，由全部后端评估工时。
待每个成员选好牌后同时展示出来，估算过程不可互相商讨；
若大家的估算结果相近（相差的数值牌不超过2张），取平均值；
若差异较大，需要让估算最大和最小的成员分别阐述自己的理由，大家沟通后重新进行估算。
记录估算结果

注：一个完整的开发过程还涉及前后端联调，可以拆成单独的活动再由前后端成员共同评估。

同时由于工时评估关注细节——各活动已是分解的最小结果，工时不会太久，建议使用0-10的数列进行评估。

4）估算故事点步骤

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

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

（1）关于评估对象

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

一个涉及到前后端的交卷功能才算完整（这不代表前面的分解活动没有用，恰恰是因为分解，才使得估算更准确）。

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

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

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

例如把交卷功能作为1个故事点，在估算“保存”功能时，若开发认为“保存”功能的开发任务量、复杂度、风险和不确定性预计是“交卷”功能的3倍。

那么“保存”功能就应该为3个故事点。另外在以后的每次估算中，最好使用同样的单位故事点，这样有助于评估和提升整个团队的生产能力。

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

1. 确定单位故事点；
2. 分牌；
3. 讲解；
4. 多次估算：仅与该功能有关的开发成员进行估算，如
  针对“交卷”功能，由前后端成员共同评估，并对故事的点数达成一致；
5. 记录估算结果。

将所有功能评估完后，就可以得出总的故事点数，新团队在第一个开发周期可以先不用考虑完成率，尽量做。

在周期结束后统计做完了多少个故事点即可，再通过两三个周期的调整和适应，我们就可以较准确地评估出团队整体的生产力和个人的生产力，为后续改进提供依据。

5）并行估算

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

1. 确定单位故事点；
2. 分牌；
3. 讲解；
4. 针对功能（故事）估算故事点数；
5. 针对具体开发活动估算工时；
6. 记录估算结果；。

3. 开发活动分配和筛选

到了这一步，我们已经拿到了每个开发活动/功能较准确的评估。

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

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

如果采用的是故事点估算，会参考前几次已完成的总故事点数。

不管是采用哪种估算方式，都可能会遇到所排需求超出团队周期内的最大工作量，此时就需要产品经理根据需求的优先级和关联性判断哪些需求可以移入下一个周期。

4. 会议通用

1）把控会议进度

控制会议整体时间：一次会议最好不要超过90分钟，若需求过多，可拆分为多次会议；
控制会议各环节时间：拆解开发活动时可能会遇到无法达成一致的情况，要及时引导大家转入下一个议题，会后相关人员再对未决议问题展开讨论，避免浪费所有人时间；
控制讨论内容：开会时很容易讨论着讨论着就跑偏了，需要及时制止这种情况并把话题带回来。

2）做好会议记录

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

四、会议后

1. 跟踪遗留问题

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

2. 跟进开发过程

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

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

甘特图适用于：

基于工时的估算方式；
瀑布式开发模式；
无固定开发周期；
需求较多且不容易变更。

看板适用于：

基于故事点的估算方式；
敏捷型开发模式；
有固定开发周期；
需求多变。

在项目进行过程中，产品经理需要每天检查并更新活动进度，这样可以及时发现偏离情况：

尽管经过细致的分解和科学的评估，仍然不能保证活动评估时间与实际完全一致，这里面包含内部原因（遇到技术难题、评估时忽略了细节等）和外部原因（疫情隔离等），如果会导致进度延期，产品经理需要根据实际情况做出应对并及时上报。
若需要临时增加需求，则按照前面的步骤再走一遍，评估出新需求的时间。如果新需求不复杂，那么可以跟开发负责人沟通，加在剩余时间内；如果新需求比较复杂且优先级较高，则需要考虑替换掉原来的某些任务（当然现实情况是都得要，那么就只能加班了）。