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

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

开发出来的功能和设计的规则不一致

看起来很简单的功能开发评估需要好几天

负责的项目经常延期

不知道开发进展

如果出现以上问题，80%是因为开发评估工作没有做好。这篇文章将会结合笔者的实际案例，详细讲解如何解决上述问题。

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

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

在中小企业，特别是以敏捷开发为主的团队中，产品经理往往需要承担一部分项目管理的职责，其中最重要的要属需求评审后的开发评估工作了（若需求较简单，可与评审会共同进行）。

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

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

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

开发对功能规则理解有偏差

需求遗漏或需求蔓延

评估的工时和实际所用的工时差距过大

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

千万不要认为开发评估会是开发的主场，作为产品经理，需要对产品的结果负责，对于任何环节可能造成的风险都需要提前规避。因此，在评估会上，产品经理不仅要做一个“倾听者”（了解技术实现方案）和“支持者”（对于开发不明确的地方提供必要的说明），更要做一个“引导者”：虽不参与实际的开发决策，但需要在关键节点通过正确地引导保证评估过程的准确性。

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

降低项目开发风险

建立与开发的信任

从技术视角看待产品，了解开发知识

锻炼领导力

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

二、会议前

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

尽管经过需求评审会，团队成员已经对设计方案达成了共识，但仍不能保证每个人都记住和理解。因此在开发评估会前，还需要通过一种结构化的方式全局呈现需求，这种方式就是WBS（工作分解结构），也可以理解为详细的功能列表。

对于产品经理，功能列表肯定不会陌生，在需求之后原型之前，我们就会通过功能列表梳理产品结构。但此处的功能列表则需要拆解的越详细越好，因为它是给开发看的，便于他们对要做之事有一个整体的了解，同时又可以避免需求遗漏、蔓延和理解不一致的情况出现。如同去菜市场买菜，相比于提前列出购买清单，如果是到了菜市场才决定买什么，那大概率会多买或少买。

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

可以看到，给产品经理自己看的功能列表会相对简单一些，只需写出大致的功能架构，为后续的原型设计提供指引。而给开发看的WBS则需要遵循MECE原则，将各功能分解地很详细，并且需要把重要的规则补充完整，这样有助于开发进行评估。比如对于“切换题目”功能，如果不写出“切换时需要自动保存答案”这一规则，前端人员仅看功能列表时就会忘记调用保存接口。

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

这是由于两者的形式决定的，WBS相比PRD最大的优势就是“直接”和“结构化”。从下图可以看到，PRD文档包含了很多内容，产品经理自己写都需要花很久，开发同样需要花很长时间阅读（现实中更多的情况是开发不看文档，遇到问题了再问）；其次文档形式不便于直观地看出各功能的层级结构，难以形成前后联系。而WBS是将PRD中最重要的“功能需求”拿出来，并细化到最小功能点，做到了需求不遗漏，方便开发做后续的活动拆分（下文会说明），同时产品的架构、各功能之间的联系和关键规则都在一张表里展示出来，大大提高了阅读效率。

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

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

我们回想一下开需求评审会的场景，经常有开发对我们的设计方案提出质疑。如果恰好是你没考虑清楚，那么你会选择跟他深入讨论，还是会说“这个问题问得好，我记下来了，会后我再好好想想然后答复你，我们先看下一项”？

我相信大家都会选择后面的方式，因为在会上讨论，不仅浪费他人的时间，而且讨论出的结果往往都是没有经过深思熟虑的。开发评估会也是同样的道理，当面对较复杂的设计方案时，作为“引导者”，要避免开发在会上就某个需求的实现方案进行讨论。

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

例如我在设计阅卷规则时，不仅可按考生、试卷、题目分配，还可按试卷和考生、题目和考生综合分配，同时试卷类型还包括选题组卷、抽题组卷和随机组卷，题目中还包含复合题，这都增加了开发在设计阅卷模型时的难度，可能还会改动已有的题库-试卷模型。显然，这么复杂的方案不适合在会上讨论，于是我先后跟前后端负责人约了几次会议，形成了一个初步的方案。这样做不仅保证了实现方案的完备性（作为负责人，经验和眼界都会高一些），同时减少了沟通成本（沟通渠道=N（N-1）/2，N指参与沟通者的人数）。接下来再开评估会议，有了开发负责人的背书，就会顺利很多。

3、促使信息对齐

经过前面的两步，你已经为评估会做好了资源上的准备，接下来你可能会把WBS、PRD、设计图、开发负责人提供的初步方案打包发给团队成员，然后信心满满的准备开会。可是事与愿违，在会上你会发现，由于每个人所站的角度不同、高度不同，仍然有部分成员因为理解不一致而进行无效讨论。

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

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

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

2、在会议前1天，要求各成员针对会议资料必须给出反馈意见（无意见也要写明），并收集留档

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

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

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

需要注意的是，心理学上有一个常见的现象——基本归因错误，即当我们对一个结果做因果分析时，往往会将原因归咎于倾向性因素（人格或态度等内在特质），而忽略外部环境的影响，但其实环境才是影响人们行为的最重要的因素。例如，如果你面对“仍然有部分开发成员因为不清楚需求而进行无效讨论”的情况，是不是第一反应是这个开发不认真、不主动。但不妨换个角度想想，其实是目前的一种工作流程造成了他还不清楚需求。

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

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

会议中和会议后的内容待下次更新。

公众号：产品乱弹。产品管理，瞎胡乱谈。