在最后一篇文章中，我们讨论了需求分析，主要从需求对象、需求意图和需求成本三个维度进行讨论。


接下来，让我们谈谈需求池。


对于圈内的产品人来说，需求池是理所当然的，因为几乎每天都要面对，但你有没有认真想过为什么会有需求池？ 在时间方面，需求的收集可能相对分散，但也可能蜂拥而至，需要进一步的评估和转化才能将需求传达给设计和研发，这需要很多时间。


此时，需求池提供了平衡需求供应的缓冲空间。


同时，需求池也是调节项目周期、规划版本的重要工具。


需求池看似简单，但做好并不容易。


让我们了解管理需求池的重要环节。


若将需求池形象化，则蓄水池再合适不过了。


蓄水池是一种蓄水设施。


如果你想储水，你自然需要有水流入。


蓄水的目的是平衡水的流出。


如果你想让蓄水池发挥更先进的作用，你可以通过过滤悬浮颗粒、去除有机污染物、处理可溶性无机化合物等过程净化水质，使其流入污水和净化水。


管理需求池可分为需求输入、需求转换、需求输出三个重要环节。


让我们逐一讨论这三个环节。


一、输入：需求输入 在之前的用户需求分析之后，我们得到了需求的总体外观。


作为一个缓冲区，需求池需要清楚地记录需求的基本信息。


它不仅要清楚地描述原始需求，还要记录分析后的场景和服务对象。


下次，它可以恢复需求的本质而不产生歧义。


储蓄字段 只要能清楚地描述需求，就可以简单地使用表格文档或项目合作工具。


一个合格的需求池应该有以下字段： 需求来源：从该渠道记录需求，便于后续跟踪和检查。


需求描述:记录第一手需求描述，便于后期跟踪核对。


需求场景：场景是需求演绎的重要依赖。


服务对象：需要仔细筛选，提出者与需求受益者不一致。


本质意图:不同于需求描述，分析后记录需求目标。


提出时间：有些需求存储时间过长，需要重新选择或重新分析。


优先级：是输出版本规划的重要依据。


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


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


更特别的是分类，大多数需求池都有。


但事实上，有很多分类只是为了存在，这对描述需求没有多大帮助，有些甚至会导致误导。


这需要自己的工作流形成一个明确的需求分类，这是一个需要注意的细节。


优先级排序 至于优先级，很多人总结了一套完整的流程，大致是通过KANO模型对用户满意度的分析，根据基本需求、期望需求、兴奋需求、无差异需求、方向需求五个特点对需求进行评分，然后综合应急程度、开发成本、研发周期等。


它看起来很棒。


这种精细分析是针对大需求或整个产品进行研究的。


分析效果很好，但几乎不可能广泛应用于每个需求。


首先，需求满意度从何说起？ 模型必须通过用户研究或数据分析建立，这需要大量的人力和时间，显然不适合应用于每个需求。


但如果不这样做，模型只能依靠产品经理的主观经验来确定，然后得分。


那为什么要绕一个大圈子来掩饰自己的主观意识呢？我不推荐。


该工具的方法很好，但不应随意使用，诚实地结合当前的产品周期，设定需要完成的时间，并通过此时间进行排序。


在后期，优先级也可以根据研发时间表灵活调整，承认这确实取决于工作经验，但随着实践次数的增加，判断将变得越来越准确。


二、转化:需求转述 当我们忙着做很多工作时，我们一定想找人分享，把一堆需求锅扔给设计师、程序猿，给他们一些麻烦，想想就是兴奋。


但直接失去估计是打架，互联网八卦我们忍不住谈论，记住不要这样做。


转化产品需求描述 虽然在此之前，我们已经确定了需求背后的意义及其基本可操作性，但从开发的角度来看，这被称为用户需求，是对用户意图的实际描述。


然而，设计师和程序猿可能无法很好地理解如何做。


例如，用户的问题是某个页面的按钮非常困难。


从产品的角度来看，放大按钮和调整位置似乎有助于改善用户体验。


哪一个？一起改？解决这个问题的方法是模糊的。


事实上，还有另一种可能性，不是按钮太小和位置问题，而是点击按钮时会有短时间的无响应。


这在用户看来是没有点击的。


这样，无论如何修改视觉交互，问题都无法解决。


因此，作为用户与团队对接的第一人，产品经理需要拆解问题，分析功能，将用户需求定位到位，最终转化为适合产品开发的功能描述和产品目标，然后传达给研发团队。


先和团队交流 由于产品经理承载着用户和团队之间的沟通桥梁，多沟通是避免梳理大量研发团队无法理解的文档的关键。


要做好沟通，首先要善于分享，这需要多次重复。


事情越重要，就越需要被反复提及才能被理解和记住。


有能力的经理通过沟通清楚地传达了产品的核心概念。


其次，要不羞于提问，在沟通中保持开放，产品经理做了很多工作，会面临很多问题。


有些问题需要留给垂直能力突出的专业人士。


我们需要做的就是吸引玉石。


只有研发团队了解产品的核心概念，然后然后通过它们进一步转换相关的需求描述。


这样，需求描述就建立在每个人的共同认知之上，以避免以后的歧义争论。


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


承受外部压力 几乎每个部门前需求时，几乎每个部门都认为他们的需求是最重要的，包括老板？ 不要被各个部门牵着鼻子走，记住我们是专业的；老子说了算，要霸气，要骨气。


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


需求关联 版本规划不应该关注一个需求，而应该从整体的角度来思考，挖掘需求功能，并在需求模块中水平连接。


在澄清需求之间的关系后，将在同一版本中输出相关的需求计划。


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


简易文档 如果前面的工作都做好了 ，所以文档的输出是自然的。


这里需要形成的是简单的文档或原型，然后在后期逐渐深入。


这是启动阶段，主要是谈判，文档主要是沟通。


这样做的时候，需求池管理的基本工作已经结束了，下面总结一下流程。


首先，优先排序需求输入； 二是积极与团队沟通，形成产品需求描述； 最后，联动需求规划版本输出沟通文档。


以上是本期的内容。


每个人都有自己的工作方式。


最重要的是找到适合自己的。


小龙只是抛砖引玉。


我希望它能激励你。


下一期需求评审，怎么不见不散？ 特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。


本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。


如有侵权行为，请联系网站管理员删除，。