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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

二、会议前

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3、促使信息对齐

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

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

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

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

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

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

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

随意打赏

提交建议
微信扫一扫,分享给好友吧。