需求池管理模板,需求池的梳理和总结

需求池模板，最近不少朋友在找需求池的梳理和总结的相关介绍，兔宝宝游戏网给大家详细的介绍一下，希望对大家有帮助。

1、需求池管理模板：

（1）需求来源

  需求，作为产品经理，日常会受到大量的需求，其中可能是来源于部门意见、用户反馈、技术反馈、运营反馈、团队讨论、老板需求、自身需求等。这些需求源源不断的涌向你，如果没有及时梳理和规划管理好需求，你将会面临一大堆问题，甚至会影响到你的工作效率。

（2）将会面临的问题

    没有统一的需求管理，当我们面对源源不断的需求时，可能有的同学会随手写个便签，或者电脑上新建一个文本记录下，更甚者有的同学过分自信，直接用脑子记住。过来人告诉你们，短期内，你可能还会记得住。时间一长，你甚至忘记这个需求是谁跟你说的。

   这些都是因为将零散的需求存储到不同的地方所导致的，时间久了还会导致需求遗漏；各种需求提出人来问，之前提的需求为什么还没有实现？然后产品经理压根不记得或是找不到这个需求。

        如果不做统一规范的管理，设想这些需求，包含自己收集的，也包含其他人收集到的需求经过几手最后到你手上的；

        当我们在做产品设计的时候发现一些问题或者对需求内容不理解，想找人确认时，这时想找需求提出人又想不起来或不知道是谁提出的。

        那么就产生了无法追溯需求源头的问题，如果按照我们自己理解的方式去做，最后就会导致需求变形。甚至一直坐着错误的需求，犯下无法弥补的错误。

    假设产品人员没有有效将需求信息收集归档，让信息散乱在各个地方；也没有用足够的时间去分析需求，规划需求，都在低头做事，认真的把一个个需求都实现。

    但他没有思考什么需求该做，什么需求不该做；什么需求有价值，什么需求没有价值。

    这样一来：一方面会造成开发资源一直紧张得不到疏通；另一方面，这些对产品人员来说最重要的思考方式，长期以往没有得到锻炼，三五年之后，也就自然跟不上其他人的节奏。

        简单说：产品经理将所有和产品相关的需求信息按一定的规则进行汇总记录的地方。

        这些规则包含了对需求的基本描述，需求的简单优先级划分、需求的价值评估、需求干系人等关键元素。

        需求的来源主要有用户需求、老板需求、用户反馈等，如果没有需求池，这些需求会散乱在各处；需求池首先解决的问题是将散乱在各个地方的需求汇总，我们可以将任何人，任何时间，任何方式产生的需求统一归总到需求池中，避免丢失。

        其次我们在收集需求的第一时间可以和需求提出人了解清楚需求的详细信息，避免过很久后在追溯，找到需求提出人时不记得了，容易导致错过需求。

        创建好需求池后，我们可以通过需求池中统计的信息去判断需求和需求之间的关联性，同时可以通过这些信息判断并明确需求的优先级，从而做好产品的版本规划；我们在日后工作过程中可以按照优先级随用随取，也可以按照制定好的版本按顺序开发。

        简单理解，需求池是装需求的池子——是需求管理和项目管理的依据；我们可以根据这些规则信息进行制定需求的版本规划，同时通过需求的记录可以追溯到需求提出人，后续有问题作为和领导、老板沟通的依据。

创建需求池的目的是将散乱在各处的需求汇总，那么创建需求池首先要建立固定的格式；

为了方便记录和管理，我参阅了一些资料和咨询了一些朋友，在结合自己理解以及工作环境，整理一份需求池文档格式模板。

1）需求编号： 需求的唯一标识，可用序号罗列，也可以用日期+当天提交需求的序号统计；作用是作为每条需求的唯一编号和快速查询需求。

2）需求模块： 根据产品模块去划分，通过将需求信息归属到一个模块中，从而更好的管理需求。例如“用户中心”作用是将需求统一归类到某个模块下，在进行版本规划时，可以优先从某个模块中筛选，同时便于根据模块查询。

3）需求名称： 简单的需求名称可以快速的表达出需求的核心内容，不需要过多的文字。

4）需求描述： 需要描述清楚需求的完整性、一致性，需要精准的描述；假设没有需求描述，产品人员可能一时想不起这个需求是什么，更何谈准确设计功能。

5）功能点： 简单描述需求的功能，也就是要做什么；这样我们快速查看某个需求时，能一眼看明白这个需求是要新增或修改哪个功能。

6）场景描述： 了解用户在什么场景下产生的需求，便于我们分析需求背后的价值，在给开发转述为什么要增加这个需求时，可以清晰的说明是因为哪些原因，更能说服开发愿意做这个需求。

8）人物属性： 人物属性包含提出人、提出时间；有了这两个字段，相当于知道了什么人在什么时间提出了一个需求。

       —— 提出人：原需求的提出人，便于日后有疑问可追溯。

       —— 提出时间：需求的提出时间，方便我们了解是什么时间提出的需求，同时可以利用提出时间来规划需求的紧急程度。

9）需求层次： 分为基础需求、增值需求、扩展需求；便于产品经理了解需求属于哪个层级，可根据需求类型、需求价值、优先级、需求层级等结合考虑版本规划。

10）需求类型主要包含：

        ——新增功能：目前平台没有实现的功能；

        ——功能改进：对目前平台已实现的功能进行优化；

        ——bug修复：系统功能使用出现问题，与正确的设计逻辑不一致；

        ——用户体验：例如页面按钮摆放的问题，发送消息时发送按钮放在右侧，可以按照用户的使   用习惯设计；

        ——UI优化：页面体现内容，如按钮颜色；

        ——内部需求：公司内部产生的需求，如开发一个内部OA系统；

        ——删除需求：对平台已有的功能进行简化；

        ——接口需求：使用对方提供的接口，或给对方提供接口。

        产品经理可以根据这些类型区分，在产品开发阶段根据需求类型考虑先实现哪些，例如：在时间紧急的情况下，有新增功能和bug修复的情况下，我们会优先解决bug修复这类型的问题，先保证项目不会出现问题。

11）优先级： P0紧急重要 → P1紧急不重要 → P2不紧急重要 → P3不紧急不重要；可根据实际情况根据商业价值、需求类型、需求层次等信息综合判定优先级，按照四象限法则将需求分别放进这四象限中，最后按照顺序一一完成；可以帮助产品经理有条不紊的完成工作，也可基于优先级这几个分类考虑到版本规划中。

12）商业价值/需求价值评估： 可以按照0-10标注，不需要考虑实现难度，在需求讨论时团队讨论决策即可；提前分析好商业价值能帮助我们了解清楚当前需求是否值得做，做完后能带来什么价值；不做的话会有什么损失。

13）开发成本预估 ：需求的开发工作量，可以通过这个信息规划开发每个版本的工作内容，也方便我们了解每个需求的开发难度。

14）拟定完成时间： 拟定完成时间是产品人员根据需求工作量进行评估。

15）需求状态 ：需求的生命周期，待讨论、暂缓（标注原因）、拒绝、需求中、开发中、已发布、取消；主要作用是可以对需求的流转状态进行跟踪，可以了解需求在不同阶段的状态，发现问题及时调整。

    需求状态主要有：

        ——待讨论（刚提出或尚未调研或技术尚未确认的需求）；

        ——暂缓（讨论完成尚未排期的需求）；

        ——设计中（产品设计解决方案期间）；

        ——需求中（已经完成排期）；

        ——开发中（已经进入开发或尚未发布的需求）；

        ——已发布（已经发布上线的需求）；

        ——取消（无效需求）；

16）需求跟进人： 指定责任人，负责跟进需求整个生命周期，确保落实到实处。出了问题马上就能找到责任人。

17）相关链接： 连接一些需求相关资料，如参考资料、原型图，流程图，或者聊天记录等信息，这里可根据实际情况可选补充。

这里主要是方便产品人员在处理该需求时，提供一些信息参考，更好的完成工作；

18）备注： 对需求的最终处理结果进行描述，一些特殊情况可以在备注中说明；比如需求完成状态，取消需求为什么需求的原因之类的，完成对需求的闭环。

        需求池是产品经理不可缺少的工具，本文中主要根据没有需求池容易产生的问题介绍了什么是需求池、创建需求池的目的及创建需求池所需要的字段信息。

        最终的模板字段需要按照公司实际业务灵活变动，文中提供的字段信息仅为参考，主要目的是为了帮助产品经理创建并管理自己的需求池。

        需求池主要的作用就是记录需求的来龙去脉：谁在什么时间提出了一个什么样子的需求？需求有什么价值？开发花费的成本如何？这个需求是谁在跟进？进度如何？最终的解决方案是什么？目的是为了帮助产品人员更好的管理需求。

2、【产品】需求池管理模板：

开门见山，先上图：

下面分别介绍表格中的几个重要字段。

即需求属于哪个平台，比如：是APP端、还是小程序？或者是客户端、还是后台管理？

即需求所属功能模块，比如：后台管理端的用户管理模块。

需求类型一般可分为bug类、优化类（可分为体验优化与功能优化）、新增功能等，类型可根据具体情况自定义。

即用简短的语言描述需求，便于快速定位该条需求的主旨。

即需求的具体描述，描述要清晰，保证完整性、无二义性。

需求来源可以是客户、领导、销售、运营、竞品等。

由于研发资源有限且需求“鱼龙混杂”，需求一定要有优先级，不是所有需求都能被满足，也不是所有需求都要马上做。需求优先级评估方法可参考之前的一篇文章《【产品】如何评估需求优先级？》。

即需求的当前状态，如：待排期、开发中、已完成、拒绝、暂停等。

这三个字段对应被接受的需求，便于后续需求完成情况的追踪。必要时，可增加开发人员、测试人员字段。

总结：以上内容就是针对需求池管理模板,需求池的梳理和总结的详细介绍，大家可以参考一下。