解剖产品经理工作流，三个步骤管理好需求池

上一篇我们讨论了需求分析，主要从需求的对象、需求的意图、需求的成本三个维度去探讨，接下来我们讲一讲需求池。

需求池对于圈内产品人来说是想当然的存在，因为几乎每天都会面对， 但你可曾认真想过为什么会有需求池？

在时间上，需求的收集可能比较分散，但也可能蜂拥而来，将需求传达给设计、研发还需要进一步评估、转化，这需要花费不少的时间。这时候需求池提供了一个缓冲空间，平衡了需求的供给，同时需求池也是调控项目周期的重要工具，有规划版本作用。

需求池看似简单，想做好却也不容易，我们再来了解下管理需求池有哪几个重要环节？

如果把需求池形象化，那么蓄水池再合适不过。

蓄水池是一个蓄水设施，想要蓄水自然需要有水的流入，蓄水的目的是为了平衡水的流出。如果想蓄水池发挥更高级作用，那么在蓄水的同时通过滤悬浮颗粒、去除有机污染物、处理可溶无机物等工序净化水质，使其流进来的是污水，流出去的是净化水。

如同蓄水池一般，管理需求池可分为三个重要环节：需求输入、需求转化、需求输出。

下面我们针对这三个环节逐一讨论。

一、输入：需求录入

经历了前面用户需求分析，我们已经得到需求的大致样貌。需求池作为一个缓冲区，需要把需求基本信息清晰地记录起来，既要把原始需求描述清楚，也要把分析后的场景、服务对象记录好，等下一次再看时，能够还原需求本质而不产生歧义。

储蓄字段

需求池记录方式不限制，可以简单地用表格文档，也可以用项目协作工具，只要能把需求描述清即可。一个合格的需求池里应该有以下几个字段：

• 需求来源：记录需求从那个渠道获取，方便后期跟踪核对。
• 需求描述：记录第一手需求描述，方便后期跟踪核对。
• 需求场景：场景化是需求推演的重要依赖。
• 服务对象：需要仔细甄别，提出者与需求受益者并不一致。
• 本质意图：有别于需求描述，记录经过分析后的需求目标。
• 提出时间：有些需求存放过于长久的时需要重新取舍或再分析。
• 优先级：是输出版本规划的重要依据。

上面提到只是基本字段，需要根据产品性质、公司流程酌情增加。

诸如需求场景、服务对象、本质意图等在第一阶段的需求分析已经有了答案，现在只是组织言语依次填入。

比较特殊的是归类，大部分的需求池都会有。但实际上有不少的归类仅仅是为了存在而存在，对于需求的描述并没有多大帮助，有的甚至造成误导。这个需要本身工作流已经形成清晰的需求分类才考虑，这是需要注意的细节。

优先级排序

关于优先级，也有不少人总结出一套完整的流程，大致是通过KANO模型对用户满意度的分析，根据基本需求、期望需求、兴奋需求、无差异需求、方向需求五个特征给需求打分，再综合紧急程度、开发成本、研发周期等最终评定出优先级。

看起来很棒，这种精细分析针对于某个大需求或整个产品去做调研，分析效果不错，但大量运用于每个需求几乎是不可能的。

首先，需求的满意度从何谈起？

必须通过用户调研或数据分析才能建立模型，这样做需要花费大量的人力与时间，显然不适合应用在每个需求上。但如果不这么做，那么这个模型就只能依赖产品经理的主观经验去判定，然后打分。

那何必绕一个大圈子来掩饰自己的主观意识呢？乱了思绪也乱了工作流程，因此我并不推荐。

工具方法是好，但不应该乱用，老老实实结合当前产品周期，给需求定一个需要完成的时间，通过这个时间排个序。

后期根据研发排期也可灵活调整优先级，坦白承认这确实依赖工作经验，但随着实践次数的增多，判断会越来越准确。

二、转化：需求转述

当我们接了许多活忙得昏天暗地时，我们肯定很想找人分担下，把一堆的需求锅丢给设计师、程序猿，给他们制造点“麻烦”，想想就是兴奋。但一股脑直接丢过去估计是要打架的，互联网八卦咱们忍住不谈，记得别这么干就是了。

转化产品需求描述

尽管在这之前我们已经确定了需求背后的意义与其基本的可操作性，从开发的角度而言，这个叫做用户需求，是关于用户意图的实际描述。然而具体怎么做，设计师、程序猿们不一定能很好的理解。

打个比方，用户的问题是“某一个页面的按钮很被难点到”。

从产品的角度看，放大按钮、调整位置，似乎都有助于改善用户体验，改哪一个？一起改？这个问题的解决方法是模糊的。

实际上还有一种可能，并是不按钮太小跟位置问题，而是点击按钮时都会有短暂时间的无响应。这在用户看来就是没点着，如此一来，无论在视觉交互上怎么修改，都解决不了问题。

所以，产品经理作为用户与团队对接第一人，需要拆解问题、分析功能，将用户需求定到位，最终转义形成适合于产品开发的功能描述与产品目标，再一并传达给研发团队。

与团队先切磋

产品经理既然承载了用户与团队的沟通桥梁，多沟通是关键，避免梳理出一大堆研发团队看不懂的文档。

想在沟通层面做好，首先要善于分享，这需要苦口婆心多次重复，越是重要的事越需要被重复提及才能被理解、被记住，有能力的管理者通过沟通将产品的核心理念清晰的往外传达。

其次，要不耻下问，在沟通中保持开放，产品经理干得活不少，会面临到许多方面的问题。有些问题需要留给垂直能力突出的专业人士来处理，我们需要做的只是抛砖引玉。

也只有研发团队了解产品的核心理念，再通过他们进一步转化相关的需求描述。这样，需求描述是建立在大家共同的认知上，能为后期避免很多因歧义产生的争论。

三、输出：版本规划

关于输出，主要是决定当前需要实现哪些需求，既是为下一步的需求评审确定好内容，也是对产品的版本规划。

顶住外界压力

当我们在确定当前要实现哪些需求时，几乎每一个部门都认为他们的需求才是最重要的，包括老板，有木有？

切莫被各个部门牵着鼻子走，记住我们才是专业的；老子说了算，要有霸气，要有骨气。

当然，适当调整需求的优先级也是可以的。

需求关联

版本规划不应该着眼一个需求，应该站在全局的角度去思考，在需求功能上下钻挖掘，在需求模块上横向联系。在理清楚需求之间存在的关联后，将有联系的需求规划在同一个版本输出。

从长期来看，关联严谨的需求集合有助于项目的快速推进。

简易文档

如果前面的工作都做好了 ，那么文档的输出就是水到渠成的事。这里需要形成的是简易文档或原型，后期再逐步深入。

这里是启动阶段，主要以磋商为主，文档也是以交流为主。

当我们做到这里，需求池管理的基本工作已经结束了，下面总结一下流程。

1. 首先，整理需求录入排好优先级；
2. 其次，与团队积极沟通形成产品需求描述；
3. 最后，联动需求规划好版本输出沟通文档。

以上就是本期内容，每个人都有属于自己的工作方式，找到合适自己的才是最重要。小龙只是抛砖引玉，希望对你能有所启发。

下一期需求评审，咋们不见不散。

#相关阅读#

《想做好需求分析？这3个问题你需要解答》

 

作者：小龙的执着；公众号：小龙的执着（ID：york_wu1219_office）

本文由 @小龙 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。