Entrar Agora 上一篇文章，我和你聊了用户需求分析，主要从需求对象、需求意图、需求成本这三个维度去拆解。顺着这个思路，今天想接着聊聊一个产品人再熟悉不过的东西——需求池。
大家几乎每天都在和需求池打交道，但不知道你有没有认真想过一个问题：需求池这东西，到底为什么会出现？
其实原因很简单。需求来得特别不均衡，有时候零零散散，有时候又一股脑儿涌过来。你不可能每接到一个需求就立刻评估、排期、推进，何况很多需求还需要进一步消化和转化，才能变成设计、开发能听懂的语言。这中间的时间差，就需要一个缓冲地带。需求池的存在，就是给这种“供应不均衡”兜底的，它让你先收进来，再慢慢处理，很自然地就成了调节项目节奏、规划版本的一个抓手。
看着简单，但真要把需求池管好，其实挺考验功力的。如果非要打个比方，我觉得最贴切的就是蓄水池。
蓄水池先得有水进来，才能存住水，而存水的目的是为了平稳地放水。如果想让它发挥更高级的作用，还可以通过过滤、净化这一系列处理，让流进去的是夹杂泥沙的浑水，流出来的却是干净水。对应到需求池管理上，正好就是三个重要环节：需求输入、需求转化、需求输出。
先来说输入：把需求收进来，还要记清楚。
做完前面一轮用户需求分析，你其实已经拿到了一个需求的“大致样貌”。但当它进入需求池这个缓冲区，光知道“有这么一个需求”远远不够，你得把一些关键信息固定下来，方便以后随时回溯，而且不能产生歧义。
一个基本合格的需求池，至少应该记录这些内容：需求来源，从哪个渠道来的，方便后续跟踪核对；需求描述，保留第一手原始描述，原汁原味；需求场景，这是后续推演需求怎么做的重要依据；服务对象，这里要小心，提需求的人不一定是最终受益者，需要仔细甄别；本质意图，和原始描述不同，它是分析后得出的需求背后真正想要达成的目标；提出时间，有些需求放久了，可能会失效，或者需要重新审视；还有优先级，这是后续做版本规划时的重要参考。这几项是基础中的基础，你也可以根据自己产品的特性和公司流程再补充一些。其实前面需求分析阶段已经把场景、服务对象、本质意图捋出来了，现在只是把它们整理成文字，填进去而已。
有一点想特别提一下：分类。很多需求池里都有分类这个字段，但坦白说，有相当一部分分类只是为了存在而存在，对描述需求本身没什么帮助，有时甚至会产生误导。所以，你得在自己的工作流里形成一套真正有意义的需求分类方式，这个细节值得留意。
那优先级怎么排？很多人一提到优先级排序，就会搬出一套看起来很完整的流程：先用KANO模型分析用户满意度，把需求分成基本需求、期望需求、兴奋需求、无差异需求、反向需求，然后分别打分，再综合紧急程度、开发成本、研发周期这些因素一起来排。听起来很科学，对吧？
但这种精细分析，更适合针对大需求，或者对整个产品做研究的时候用，效果确实不错。可要是想把它用在每一个需求上，几乎不现实。首先，满意度数据从哪儿来？真要严格用模型，得通过用户研究或者数据分析来建立，这需要大量人力和时间，显然不适合去套每一个琐碎需求。可如果不这么做，模型就变成了产品经理凭主观经验去打分，绕这么大一个圈子，只是为了给自己的主观判断套上一层“科学”外衣，意义不大。
所以我个人不太推荐动不动就上KANO。不如诚实一点，结合当前产品所处的阶段，给需求设定一个需要完成的时间窗口，然后按这个时间去排优先级。后期再根据研发的实际排期灵活调整。得承认，这件事确实依赖经验，但随着练习次数变多，你的判断会越来越准，这没什么不好意思的。
再来说转化：别把“锅”直接甩给研发。
手里攒了一堆需求，肯定想赶紧找人分担，把“锅”分给设计师、程序猿，光想想都兴奋。但如果你直接把原始需求丢过去，大概率是要打架的。互联网江湖上的八卦就不多聊了，总之，千万别这么干。
你需要把用户需求转成产品需求描述。虽然前面已经分析出了需求背后的意义和基本可操作性，但从开发的角度看，那依然叫“用户需求”——是对用户意图的如实描述，设计师和程序猿未必能直接理解该怎么动手。比如，用户反馈“某个页面按钮很难点”。从产品视角看，你可能会想，把按钮放大一点，或者调整一下位置，是不是就能改善体验了？但到底改哪个？一起改？解决方案其实很模糊。而且还有一种可能，真正的问题根本不是按钮大小和位置，而是点击按钮后，界面会有短暂的无响应，用户感觉就像没点上。这种情况下，你去改视觉、改交互，根本解决不了问题。所以，作为连接用户和团队的那个人，产品经理需要把问题拆解清楚，定位到功能层面，把用户需求转化成适合开发执行的产品功能描述和产品目标，再交给研发团队。
做这件事的时候，千万别一头扎进文档里，先跟团队聊。产品经理是信息的桥梁，多沟通才是避免埋头写一大通研发根本不理解的文档的关键。沟通这件事，首先要善于分享，而且重要的事情得反复说。事情越重要，越需要被多次提及，别人才会真正理解和记住。有经验的产品经理，往往就是通过一次次沟通，把产品的核心概念清晰地传递出去。另外，别怕提问，在沟通中保持开放。产品经理要做的事情很多，面对的问题也很多，有些问题就是应该留给垂直能力更强的专业人士。我们需要的是抛砖引玉，让研发团队真正理解产品的核心概念，然后由他们反过来帮你一起把需求描述进一步细化、落地。这样产出的需求描述，是建立在大家共同认知之上的，后面能省去很多因为理解不一致而引发的争论。
最后是输出：决定现在做什么，做好版本规划。
输出环节，说白了就是决定当前阶段到底要落地哪些需求。这既是为下一步需求评估划定范围，也是在给产品做版本规划。几乎每个部门在提需求的时候，都会觉得自己的需求最重要，包括老板。这时候千万别被牵着鼻子走，要稳住。记住，我们才是专业做判断的人，得有点“老子说了算”的霸气和骨气。当然，这并不是说优先级完全不能商量，适当调整是可以的，但基调得自己定。
做版本规划，不能只盯着一个需求看，而要站在整体视角，把需求之间的功能关联挖掘出来，在模块层面做横向串联。理清需求之间的关系之后，尽量把关联紧密的需求放进同一个版本里输出。长期来看，一组关联性强、逻辑严谨的需求集合，对项目快速推进帮助很大，也能避免反复拆东墙补西墙。
如果前面这些工作都做到位了，那文档输出其实是水到渠成的事。这个阶段，只需要形成一份简易文档或者原型就够了，后期的细节再慢慢深入。在启动阶段，重点在于沟通对齐，文档的作用主要是辅助沟通，而不是追求完美。
到这里，需求池管理的基本工作就算走完一圈了。简单回顾一下：先收进来，做好优先级排序；然后主动跟团队沟通，把用户需求转化成产品需求描述；最后联动需求，规划版本，输出沟通文档。
每个人都有自己的工作方式，最重要的还是找到适合自己的。我这篇只是抛砖引玉，希望能给你带来一点启发。下一期，我们聊聊需求评审，不见不散。