一个健康的需求池，能让使用者直观地看到各项需求的进度和接下来要推进哪项；也能帮助使用者诊断版本迭代中的问题；还能让使用者看到每个需求的实现需要各岗位准备什么。

相信很多产品经理有这样的痛苦：需求多且杂，需要对接的岗位很多，而且即使一个需求也往往涉及多个岗位。这时候我们需要一个好用的工具管理各项需求，这个工具就是需求池。需求池之于产品经理，就像甘特图之于项目经理。

需求池不是需求的简单罗列。一个健康的需求池，能让使用者直观地看到各项需求的进度和接下来要推进哪项；也能帮助使用者诊断版本迭代中的问题；还能让使用者看到每个需求的实现需要各岗位准备什么。

什么是不健康的需求池？

• 没有标注各项需求的优先级
• 不涉及各岗位如何配合，不能促进沟通
• 没有厘清各个需求之间的前后续顺序
• 没有版本规划
• 把BUG也进行排期，或者根本不记录BUG
• 需求池很复杂，每天要花很多时间才能维护好
• ……

怎么维护健康的需求池？

1. 需求池的表头

• 优先级：我的习惯是A+、A、B、Z。A+表示马上就做，A/B是候选，等消化完A+就从AB里任命新的A+。Z表示暂缓，一时半会儿做不了。还有的需求不确定要不要做我直接不标注优先级。EXCEL的自定义排序功能可以很方便地实现按优先级排序。
• 需求模块/关键词：方便快速查找，也方便相关需求放到一起规划。不过负责单一模块的产品经理不需要这个字段。
• 需求详细描述。
• 补充说明：记录重要变化，如技术表示什么有难点、需求方需求有变化等。为了防止遗忘最好加上记录时间，一般我的格式是：XXXXXX@181120。
• 进度：一个需求的生命线往往是这样：提出并讨论需求→分解需求（常形成流程图）→沟通预估工期→排定优先级→具体规划（常形成需求文档）→排期并完成。在维护需求池时，我把需求分为需求调研、规划中、方案已确认、技术对接中、开发中、已完成几种状态。而且会根据和技术沟通结果写明预计什么时候达到什么阶段。
• 产品负责人：记录每个需求分给了谁，当然只用记录自己的需求就不用这个字段了。

2. 怎么评估优先级

从3+1个维度评估：重要性、紧急程度、粗估工期、加一个BUG。

1. 重要性和紧急程度的确定也不是产品一个人说了算，需要和上级领导、需求方沟通确定；
2. 粗估工期需要请技术同事给出，很简单的需求优先级提高。最好同时记录开发给出的预估工期和实际完成工期，帮助了解自己团队的需求消化能力；
3. BUG一定要记录在需求中，但是不用排期，要第一时间解决，所以BUG永远是优先级最高的。

在以上三个维度评估的基础上，摘出下2个版本要做的事,在表中进行清楚的标注。

（PS：出于用户体验考虑，控制发版频率，尤其当你的产品是APP时，每次大的版本都需要重新下载。即使是可以自动更新的迭代也要控制频率。）

3. 为什么这样的需求池是健康的

1. 对需求从整体上进行审视，提高迭代效率；每件事单独看起来都是非常重要且紧急的级别，但是需求永远会大于消化能力，本着要事优先的原则，必须通过共同的审视摘出最重要且紧急的代办项目。从而让迭代向着对整个项目最好的方向进行。
2. 对利益相关者广播优先级和项目进度，提高团队透明度，使大家互相理解，更少抱怨更高效率。

三、谁来维护需求池

维护者当然是产品经理，但是数据来源却涉及开发同事和不同部门的需求方。这个时候大家坐下来快速高效地审视一边需求，一定要有决定权的领导在场防止扯皮。

当着所有人的面（尤其领导的面）把每个需求再认真定义一遍也很重要，因为有的时候需求不是从产品整体考虑，会被老板砍掉。绝对不要让自己的开发团队陷入到没有被认真审视过的需求里浪费时间。

产品经理的工作，尤其当到达一定级别开始带团队，需求池=TO DO LIST，最好每天都过一遍需求，不要让他们在表中荒芜。

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

题图来自Unsplash，基于CC0协议