【rpd怎么算excel】产品服务员干货-基础技术篇：如何优雅地控制需求？

大家好，现在我将整理上一份工作中在产品层面上做的一些方法论和实证经验，与大家分享，供产品同事交流和学习。(大卫亚设)。

本文与产品同学分享了自己在需求提取、需求翻译、需求管理、需求设计、需求驱动、需求传递等方面的实践经验。希望通过这篇文章文章，帮助中学产品工作者优雅地控制需求。沉着应对杂乱的需求，对上游需求者兄弟给予有力的专家支持，下游R & amp希望能对d兄弟进行专业有序的协调。

对工作敏感地平息下来

再牛的产品经理也要了解业务，业务能力再强也容易关门停车。只有我们融入业务，理解业务，才能一直保持对业务的敏感状态。

当我们沉浸在工作中的时候，我们可以感受到深刻、系统、水平、垂直地存在于工作中的问题、可能出现的问题以及相关问题背后的上下文“语境”。

对业务敏感可以通过以下方案来表达：

场景1:当业务兄弟或业务领导者讨论业务“表象问题”时，我们可以立即以相同频率照镜子，用业务语言与当事人无缝沟通，同时发掘对“表象问题”的深层问题或业务或老板背后的潜在诉求以及相应的解决策略。场景2:当我们接受某项任务或需要解决某个特定问题时，我们会从整个平台的角度思考问题，制定解决方案，并有大盘，以免丢坑。场景三：除了工作休闲外，作为产品天生的好奇心可以吸引外部、行业内、行业外表面无关的东西进入工作，促进事业的良性创新和发展。

我爱你的产品持续的工作思维。

热爱成就是伟大的。如果不爱我们的产品，就不可能单纯依靠审查，依靠成果创造伟大的产品。(伯纳德肖，成功)如果产品经理不喜欢自己的产品，不使用自己的产品，在工作之外继续思考自己的产品，就很难获得出色的输出和产品创新。

当我们持续关注和思考我们的产品时，用户反馈给我们的问题基本上是事先知道的、已经安排好的或考虑好的。(大卫亚设，Northern Exposure(美国电视)，产品名言)尽管我们知道短期内无法解决，但我们可以补充非开发战略，例如我们的日程计划。例如，我们的日程安排，例如我们的工作界限，可以补充非发展战略。

Excel文档第4部分：Roadmap feature matrix 3个版本的Featurelist要求池

Roadmap的设计策略及实战case

Roadmap是以实现公司战略目标为原则，决定我国产品建设的中长期指导计划，不同等级和阶段的粒度尺度不同。

优雅的Roadmap需要以下元素：

指导经营目标。明确的时间窗口；明确的业务方案和业务目标；逻辑进化的自我一致性；根据公司的现状，能够承受的研发；d资源投资决策层的共识和认可。

功能矩阵的设计策略及实战case

功能矩阵是站在产品所有层面的功能角度或特定的商业场景角度，思考和设计我们产品的进化计划。从某种意义上说，功能矩阵是另一个观点Roadmap，但与Roadmap有明显的区别。

差异1:功能矩阵更喜欢“矩阵”和“时间”。差异2:功能矩阵比Roadmap更习惯用“优先级”、“状态”来表示，但Roadmap的优先级基本相同，只是时间窗口的设置问题。也就是说，功能矩阵是产品经理通过“自下而上”的内生动力，以暗线推动产品迭代的进化。Roadmap通过产品经理“自上而下”的外部框架指导，明确推动了产品迭代的进化。Roadmap反映了公司的战略意图，功能矩阵显示了产品经理对产品的深入思考和配兵部署。

25&index=4" width="640" height="197"/>

需求池：采集、梳理、更新策略及实战case

产品经理打交道最多的就是需求，面对来自各方杂乱无章的需求，我们需要进行统一管理。基于分层组织架构，实践中我认为比较好的采用AB结构。

A类需求池原则上是产品总监或一级产品负责人维护，A类需求池需要向产品内部进行实时同步、随时查阅、协同编辑，共同维护，作为团队的“公有资源”使用。实务中，产品总监或一级产品负责人需要每周、每月、每季度与产品组同事内部集体Review——指导产品团队持续的完善需求、聚类整理需求、有序解决需求。如有必要还需与业务领导一起讨论技术开发是否有必要或者启动优先级及时间窗口设定。

B类需求池原则上是所有产品经理对自己负责模块的维护。大家会问，这两个是否重，是否存在需求不一致呢？

答案是“一定会”，但是，并非简单意义上的“重复”，我们姑且可以把B类需求池作为自己的账本，自己的账本应该和大账本保持同步，但是自己的账本的侧重点是更敏捷、更系统、更细腻——方便自己心中有本账。

无论是A类需求还是B类需求，都遵循“实时记录”、“及时整理”、“定期复盘”、“干系人共识”、“状态更新”。

无论是A类需求还是B类需求，在信息处理时，都应该有如下几个必备字段：“提出人”、“问题描述”、“问题归属”、“问题性质”、“优先级”、“版本规划”、“状态”、“责任人”。不同团队，不同个人习惯可以略有不同，示例如下：

三个版本的Featulist

基于上述Roadmap的“明线指导”和产品功能矩阵规划的“暗线指导”，结合上述需求池的原始线索，我们需要梳理出下个版本要解决的问题，并基于可投入的研发资源及时间窗口设置下个版本的Featurelist。

相对产品功能矩阵表，Featurelist的粒度要更细。具体哪些需求可进入Featurelist，可以同大家分享我的一些实务经验：

• 如果是运营类需求，Featurelist包含两个维度：运营面上的功能需求点+产品内部相关联动点；
• 如果是产品类需求，Featurelist包含两个维度：主功能点占比80%+用户体验（含bug修复）优化点：占比20%。

为了将产品经理从需求应付中解放出来，发挥我们的产品owner原始价值，我的操盘经验一般是采用三段式，也即研发一版、设计一版、规划一版。

研发一版：当前研发团队正在进行的，产品的时间投入基本分布在如下几个场景：文档动态更新、研发动态支持、项目进度动态跟进、测试验收、上线培训等工作，这些场景的特点是：琐碎、紧急。

设计一版：是我们提前对已共识要干的下个小Roadmap进行拆分设计，也是研发前期产品拥有最宝贵的静态时间窗口期。

这个场景的特点是：产品内部方案论证、产品内部评审、需求方二次确认、必要的前置视觉启动等。设计一版也是最考验产品经理能力的，出色的产品经理可以很好的做好时间窗口把握，帮公司和团队节省巨大的人力资源（不是产品经理自己，而是整个下游团队的静态等待时间）。

规划一版：更多是提前思考下下个版本应该做哪些、相对大Roadmap我们进度有哪些偏差、是否有最新的需求或市场变化需要考虑进来，带有较大的不确定性。

除此之外，出色的产品经理还要做到如下两件事：通过提前思考来逆向指导“设计一版”的逻辑扩展性和方案策略的合理性，二一个是与业务体系进行论证、明确哪个部门的优先级高，哪个需求优先级高，并向外部提前一个月同步一个月后的预定攻击目标和预期交付成果，进而避免业务追着产品问，我的XX需求啥时候做？我的XX需求啥进度了？你们下一步打算做什么？

定期Review：回应需求方关切+明确行动共识+再次澄清需求

需求池有了、版本规划有了、产品设计也干了、研发也吭哧吭哧启动了，这么多需求，我们的资源有限，时间有限，不可能全部做完，也不可能一步到位。而我们的老板、我们的需求方（内部各业务方）是不清楚我们在干什么的？

这就需要产品经理需要做如下事情：

1. 启动前与需求方再次明确共识：哪个优先级高、哪个优先级低、大的策略框架、预期可达到的效果是。
2. demo文档设计完后要与干系人确认，进一步澄清需求是否符合预期，避免研发进行中变更或者上线后推到重来。
3. 每周小通报、每月大通报，向干系人通报Roadmap的整体进度、当前在途项目的进度以及干扰事项、前置协作等信息。

产品设计：目标诉求、干系人、业务场景、需求边界、业务链路、产品架构

目标诉求、干系人、业务场景

我撰写PRD有个习惯，也即每个功能模块、每个页面（敏捷需求或时间不允许时省去），花时间撰写（思考梳理）“业务场景、目标用户、设计诉求、设计策略、背景说明”等信息，基于上述背景，在整理需求会让自己的思路清晰、考虑系统、方法得体，还有个好处是避免遗漏。

当然了、C端产品相对比较简单，这些步骤的价值没有B断产品明显，示例如下：

业务链路的设计策略及实战case

产品经理千万不能接到需求上来就画原型，钻入细节，而是先调研业务、静下心来思考人，然后用手（或工具）画出业务链路图。画完业务链路图后再自行推敲是否合理，正向的、逆向的、约束条件、分支条件等是否都考虑到了，业务链路是否有遗漏、业务链路能否再简化，现有功能如何自然演进（如需）。

上述基础工作做完之后，再结合前述的功能矩阵图（如excel、如脑图）二次推敲、调整。

二次推敲完之后，再与业务方、干系人讨论、看下是否有遗漏，如无遗漏方可开展原型撰写。这里有个坑，业务方并非只是领导，还要邀请实际使用者参与讨论，避免我们闭门造车或遗漏业务中的特殊规则等。

产品架构设计策略及实战case

产品架构是产品经理站在公司的业务、资源和时间三个维度，统筹考虑当前产品的业务架构、技术架构、研发平台（客户端还是小程序还是都干）、先做哪些功能？再做哪些功能？各个功能模块之间的耦合解构关系、不同的研发小组分别并行或串行做哪些功能，最后有序会师等。

一方面考验产品经理的过往大项目经验沉淀能力；一方面考验产品经理的业务理解深度；一方面考验产品经理敢下功夫投入的系统思考的逻辑严谨性和前瞻预见性；一方面考验产品经理的权衡决策能力；最后一个是考验产品经理的落地执行能力。

征询讨论：领导征询、业务方征询、技术组长征询

心中装有产品架构、在已达成共识的业务链路和Featurelist指导下，完成PRD（我习惯直接用原型，而非写word）初稿。

初稿更多的是页面结构、信息布局、事件流转的呈现，并不涉及研发层面的详尽的逻辑注解。初稿自查无异议后，要与产品Leader（如无略）内审，内审通过后再与需求方一起走查看下是否符合预期，是否有遗漏的场景未覆盖，产品策略是否合理等。

与业务方达成共识后，就部分高复杂业务或有一定技术难点的再与各组长进行逐一征询，提前获取各技术组长的专业指导建议和方案认可，为后面的正式需求宣讲扫清障碍。

立项圈人：画饼、排期、立项、圈人

需求宣讲完后，我们需要各研发组长在指定时间内（原则上不超过2工作日）基于Featurelist和PRD返回排期，如果资源有冲突，可以分组错茬开发。

产品经理要利用好需求宣讲这个舞台的前、中、后三个场。

前场是画饼，讲这件事的背景、紧迫性和价值，用故事、段子、使命等将大家从其它阵地带入到我们的阵地。

中场就是我们最拿手的需求宣讲，千万不要搞砸了，注意顺序“功能矩阵”>“业务链路”>“具体模块”>”全局潜规则”，最后来个虚心请教是否有遗漏，请在座的研发、测试专家们“扔砖”~

后场就是再次重申，决战开始，此刻起兄弟们都归我管了，立项后谁的需求都不能接了，谁敢私自接需求，咱们周会上刀枪相见~

风险化解：真诚干练、更新同步、每周Review+进度通报

人无完人，再大神级的RPD也会有瑕疵，此时我们要做的就是释疑、补充、完善。

从业秘诀如下：

• 千万要真诚、千万要真诚、千万要真诚
• 千万要干练、千万要干练、千万要干练

千万要及时更新文档、千万要及时更新文档、千万要及时更新文档。

备注：更新不代表立即上传SVN，但每日必须同步一次。

及时组织或协助组织项目进度Review，每周一次，会上就干三件事：进度驱动、协调协同、风险披露。

验收交付：标准对照、需求池更新、数据初始化、运营客服培训

标准对照

时间充足：从大到小（扒洋葱）、事无巨细（推土机），分层推进；

时间紧张：关键业务点体验，其它交给业务方和测试兄弟把关。

需求池更新

基于研发测试进行中暴漏的问题，动态更新我们的需求池、及潜在版本的Feturelist。

数据初始化

永远记住，数据初始化是一个标准动作，永不可忘记。基于此倒排，我们的数据初始化策略和前置准备工作。

运营客服培训

领导一句话，产品一拍兄，研发一把泪，事终于成了。

但我们要对运营同学、客服同学进行系统的培训。

培训秘诀：概念导入；业务链路串讲；具体操作演示；操作手册。

以上是自己在产品中的一些实践总结，限于文采拙劣和时间有限，未能精细呈现，海涵。文中所述观点不当的，希望广大产品同仁不吝拍砖，共同提高。

不同的产品团队、不同的岗位角色，会导致我们的分工不同，以上很多场景可能不涉足或不主控，但万变不离其宗，方法相同，只要我们有产品盘感、业务敏感、逻辑严谨、灵通好学、干练带风、狠下功夫，放到哪我们都一样熠熠生辉。

产品之路很艰辛，也更能锻炼人！在此祝广大产品兄弟姐妹们不辱“产品”之title，做出好产品！

作者：九天牧人，个人微信unifarm

本文由 @九天牧人 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议