需求池概念
需求池一个记录需求、跟进需求、管理需求的池子。
需求池原则
宽进严出，进来容易，出去难。（记录需求不进行审核，需求执行落地需要评审）
为什么会有需求池
1.需求池中的需求可能由不同岗位的人员填入，因此要有个池子进行管理。
2.人的脑容量是有限的，需求的数量少则几十，多则近百，单纯的依靠脑子是无法记录/无法记录完整，因此需要需求池。
3.需求的下一环节是产品设计，任何的App、所有的功能点、甚至页面中的元素（如文案、样式），都是基于需求来的，抛开需求谈解决方案就是耍流氓。因此，要有个池子，记录需求，团队根据这个池子中的需求，进行评审，选择高价值的真需求进行设计、开发、上线。
需求池的维度
前文提到，需求池需求池一个记录需求、跟进需求、管理需求的池子，且需求的数量不止一条。基于此，具备以下维度：
维度：序号
因为需求不止一条，所以肯定有个维度是【序号】。
序号：从1开始，依次向后递增，序号的作用是为了，同事之间沟通需求的时候，可以快速定位到此需求
维度：需求描述
因为是记录需求，所以，肯定有一个维度是【需求描述】,可以从用户、场景、诉求/期望角度描述。
需求描述：需求的描述不能仅仅一句话带过，在记录需求的时候，尽可能记录全量信息，防止后续评审、设计环节，因信息缺失导致需求无法推进。
维度：需求状态
因为需求需要评审、分析之后，才决定要不要开发上线，所以要有维度【需求状态】，用来表示，哪些需求我们要做，哪些需求我们不要做，状态有：未评审、已拒绝、已通过
又因为需求评审通过之后，我们要进行设计、研发、测试、上线，因此，【已通过】的状态又可以继续拆分为【设计中】、【开发中】、【测试中】、【已完成】，又因为可能会存在存在一些突发情况，导致需求进度受到影响，因此有一个特殊的需求状态【需求暂停】
需求状态分为：未评审、已拒绝、设计中、开发中、测试中、已完成、需求暂停。
维度：提出人、登记人
因为，脑容量有限，需求有很多，记录需求的人也可能很多（产品、运营、开发、销售、售前），那么多的人员，那么多的需求，对于产品经理来说，记录是比较困难的，因此要有【登记人】、【提出人】维度，两者都是具体的人，比如张三。当需求认知不清晰的时候，首先联系登记人，询问具体细节，若无法解决问题，再联系提出人（提出人可能和登记人一致，也可能不一致，比如需求提出人是客户，登记人可能是是销售、运营）。
提出人、登记人：具体的人，有名有姓，不能是一类角色
维度：优先级
需求有很多，评审之后，要做的需求也有很多。但是资源（开发、UI、时间等）是有限的，总要有一个先后顺序。因此，要有【优先级】维度，用来表明需求的实现顺序。
优先级：P0（重要且紧急）、P1（不重要紧急）、P2（重要不紧急）、P3（不重要不紧急）
维度：需求来源
需求来源有很多渠道，比如：竞品分析、客户反馈、同事（运营、开发）、市场分析、产品经理自己，因此要有【需求来源】维度，记录需求的来源。同时，可以通过此数据，来判断哪个渠道提供的需求更优质，比如100条需求，评审过了70条，这70条中，有40条来源与竞品分析，就说明竞品分析渠道来的需求更优质。
需求来源：竞品分析、客户反馈、同事、市场、产品经理等，按照自己业务需求来源进行灵活调整。
维度：需求类型
不同的需求类型，也是我们选择需求，评审需求的标准。比如我们每次版本迭代（除0-1阶段）不可能只迭代基础型需求，要结合业务，选择部分期望型需求或兴奋型需求。
维度：备注
还有部分信息，如参考文档链接，如需求暂停的原因等，都可以写在备注中。
维度：提出部门、所属产品、所属模块、提出时间等等
这些也都是需要记录的维度，原因不做过多解释了，和上面的思路是一致的。
总结
需求池，本身来说，也是一个【产品】，我们要根据使用用户、应用场景、用户的诉求及期望去思考、去完善需求池，以上仅仅是“部分通用”的模块，要根据自己的业务需求、业务现状进行灵活调整。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
