【需求评审】谈谈产品需求如何被“接生”

洗完澡盘腿在床上,思索着今天应该需要写啥。

自己出校门实习也有了一段时间,待过大公司,待过小公司,也待过不大不小的公司。在每一次产品的版本迭代环节,总结来看,PM工作流程大致可分为以下几个阶段:

  • 需求收集:主要是需求池的维护,产出优化的初步思路。需求来源可能是用户反馈、boss要求、数据分析产出等等渠道;
  • 需求分析:明确背景,量化需求收益和成本,根据团队开发能力和其他限制因素筛选需求方案,以及排定需求优先级;
  • 需求设计:此阶段需要产出落地页设计方案,明确页面跳转逻辑以及服务端策略;
  • 需求评审:在包括组内feature评审,详细策略评审以及技术评审,目的在于明确风险点以及开发排期;
  • 开发跟踪:跟进开发排期进度,协调设计和其他资源;
  • 跟进提测:包括组件提测和全量提测,跟进修复可能的bug;
  • 上线观察:主要就是上线后的效果观察,若有A/B测试则需要对比分析需求的ROI;
  • 产出迭代项目,重复步骤一;

篇幅所限,没办法在一篇文章内描述完所有的流程,这次针对产品工作流程的“接生”环节——需求评审,谈谈聊一聊。

一、需求评审的“地位”

为什么没按照工作流程从头开始讲,为什么自己会将“需求评审”称作“接生”。PM这块儿一直有一个段子叫做“产品就像是一个孩子,PM、RD负责生孩子,运营负责养孩子”。如果把需求评审之前称为“受孕”,那么需求评审也就是“接生”的阶段。因为需求怎么做,能不能做,能做到多大程度,多少人来做这个需求,都需要在评审环节完成结论产出。避免需求被拍死,就需要PM在评审环节做好充分准备。

另外,PM舌战RD撕逼的场景,往往会在这个环节体现的淋漓尽致。

二、需求评审的几个阶段

  • feature 评审:基本由PM组内参与,主要是核对需求要点,避免发生需求冲突;
  • 组内策略评审:基本由PM组内参与或者少数设计同学,评审需求的策略逻辑是否合理以及初步设计方案,明确待优化项;
  • 组内策略优化评审:基本由PM组内参与或者少数设计同学,明确上一版评审基础上需求疑点,本阶段评审结论为定稿方案;
  • 技术评审:参与需求开发的全员参与,完成需求讲解和排期确定;
  • 排期方案制定:包括明确各个各个承接方具体的工作安排和负责内容;

三、需求评审“评”什么

如果把需求评审本身当做是一个产品,那么参与需求评审的成员也就是这个“产品”的用户。这些“用户”大致分为:PM、客户端RD、服务端RD、运营、数据组、QA、UI、UE以及各自部门的老板。我根据团队内不同成员的诉求角度,先来拆一拆这些“用户”都各自需要什么:

  • PM:完成需求内容的讲解,完成质疑解惑,需要明确需求承接方以及排期情况;
  • RD:了解需求的技术成本,明确每个需求的确切策略以及需求背景和收益;
  • 设计:了解需求的设计成本,用户体验因素的考量;
  • 运营:需要了解该需求是否需要适配推广或者运营方案;
  • 数据:需要明确需求收益的评估维度和评估方案;
  • QA:了解需求存在的风险点,排查用户以及技术层面的风险;
  • boss:了解成本、为业务或者公司带来的收益以及评估策略;

OK,取上述“用户”诉求的并集,其实就能够得出在需求评审的环节中PM需要讲解的内容,也可大致作为撰写PRD的内容框架。

  • 需求背景:功能诉求产出的原因,最合理、最有效的需求背景就是用数据支撑。数据需要贯穿评审的每个环节,包括明确需求收益、数据评估等等;
  • feature list:也就是所有本次待评审需求的整理集合,需要明确需求的优先级,各个需求的story子例,评审成员能够通过list一览整个版本的需求信息,也方便整理开发排期。
  • 需求详细:RD需要明确每一个需求的详细策略,同时QA也需要通过策略来检验需求是否存在冲突和异常风险,为了便于策略沟通和理解,评审内容能上图就上图(用户流程图、布局框架图、逻辑跳转原型图等等),对于设计同学来讲,若有设计需求,则还需要产出基本的demo样例,方便成员在实际开发前了解需求的呈现形式。
  • 评估体系:包括客户端打点统计,明确打点评估维度,便于在开发上线后做需求收益的评估工作。

四、啰嗦几句

1、PM是需求评审的决策者

往往很多时候,由于需求准备不足或者思考深度不够,在面临需求PK或者答疑环节,很容易被其他成员“带着跑”,以至于出现最终拍板的需求并非之前组内通过的需求方案。面临此类情况,为了推进评审进度,最好的处理方式就是暂停该需求的评审,进入下个评审环节,待会后明确清楚再定夺是否开发该需求。

2、数据是支撑需求的有力工具

就如同每个人都遵守法律一样,做决策时数据往往就是最有力的的武器。当出现团队意见分歧或者不认可,PM需要拿出数据来为自己的观点提供辅助,基于事实和数据做出的决策会比靠感觉和经验更有力度。

3、学会团队激励

以前看过很多帖子都说,技术评审环节可以减少背景、收益等要素内容,因为RD只关心需求怎么实现。但是事实并非如此,任何一个合格的RD,包括设计、QA在内,都绝对不只是一个落地实现需求的“机器人”,他们都会关心自己的工作目的是什么,收益是什么。因此在上线评估阶段,PM可以根据成员分工排期以邮件形式周知收益状况,让实际参与落地上线的同学了解到他们的工作最终为产品带来了什么。成就感的建立,往往也能为PM的可信任感增分不少。

(其实上面的话很多是我老板教我们的~~~)

复盘文章内容:

1、需求评审是产品工作流程的关键环节,直接决定了需求能否从idea到落地实现;

2、需求评审阶段主要分为PM内部评审、团队技术评审和排期制定;

3、评审内容大致包括需求背景、目的收益、详细策略、落地页设计和收益评估维度;

4、PM需要利用数据增强话语权和可信度,另外也需要通过收益数据来激励团队成员;

欢迎关注“滔滔有话讲”