又到了年末，产品之路走了近两年，回顾两年经历，所学确实繁杂，但很多尚未内化，形成自己的方法论。于是决定一步步总结一下“日常级”“项目级”“战略级”工作中运用的各种工具，从工具延展到工作流中，敦促自己形成流程并不断完善，以期向更高处迈步。

这篇文章主要讲讲需求池。

需求池是产品经理的工具箱中十分重要的一个，许多产品人产品之路开始于需求的搬运、分析与传达。需求既是产品经理的金矿也是命符，怎么能没有一套系统去运用呢。

1 toB与toC需求池的差别

toB与toC需求池的差别其实也就是二者需求的差别。

如果说toC产品的需求是产品的指南针，toB产品的需求就是产品的镣铐，在镣铐中跳舞。

toC需求池小部分来源于用户，大部分来源于产品团队，与其说是需求池，更像是个想法集，从中找到产品迭代的灵感和方向。

而tob需求池基本来源于切实的业务方，每一条需求都必须有始有终，更像是个待执行清单，这种需求，需要我们进行生命周期管理。

2 “定义”需求池

身为产品经理，就要明白流程化的魅力，学会利用产品经理的优势，用结构化的方法论分析和最大化利用每个工具。

• 产品定义：一个提高效率、减少错漏的需求生命周期管理工具
• 用户及其声音：使用者自己，没有阅读者。
  • 希望能够监控需求的状态，做到每个需求都有回应；
  • 每一个需求查询筛选都很方便，便于需求分析、需求评审的时间安排；
  • 对需求的开发执行与结果反馈有记录，便于总结和跟进；
  • 对需求留档记录，追溯还原需求提出与实施背景和成果，便于沟通和撕逼。
• 场景
  • 每日确认需求状态，为没有进行需求分析的规划时间，进行需求分析的准备约会议室评审，评审通过开发的提交排期，延期开发或不予开发的注意答复并说明原因，交付的敦促验收。避免遗忘而搁置进度或忘记答复。
• 用户/商业价值：流程化需求，提高效率，减少错误，避免遗漏
• 频次：高频，每日管理，即时更新

通过产品规划，确定载体平台是excel，核心功能是规范化状态，便于对需求的分类检索。将需求池分成四个部分：需求记录、分析评审、排期开发、验收反馈。

3 需求池的阶段

3.1 需求记录

字段： 需求记录部分.png

这个阶段主要是对需求的收集

• 【需求时间】【需求来源】需求是谁什么时候提出的？
• 【需求对象】【需求内容】针对哪个产品功能模块有什么样的需求？需求内容尽可能还原需求方原话，有邮件或文件的附带名称，作为原始数据避免过多的加工。
• 【限定时间】需求有没有一个明确的限定时间（紧急程度）？
• 【需求状态】待分析、待评审、待开发、开发中、待验收、结束、中止。需求状态是日常跟踪需求的核心筛选项，严格定义。

在与需求方沟通获得需求后，初次整理做到这个阶段就足够了。

3.2 分析评审

字段： 分析评审部分.png

这个阶段是对需求进行分析，评估需求的类型、涉及模块、优先级，并对需求作出答复（无论是否进入开发环节）

• 【需求类型】功能、交互、界面 功能需求视情况作为发版节点，交互和界面一般跟随下一版本发布。规范的发版流程可以控制一部分不合理的紧急需求。
• 【指向页面】【涉及功能】【逻辑变更】衡量功能、数据、逻辑变更，有变化的要找相应产品或开发前期商讨。
• 【优先级】结合需求方的意见和开发意见在评审阶段讨论确定。
• 【需求状态】其他阶段需求状态与需求记录阶段保持一致
• 【需求答复】重要，对需求进行评审过后，一定要对需求方进行答复，保证“需求有回应”

3.3 排期开发

排期开发阶段.png

这个阶段不用多说了，对需求所形成的各功能数据更改进行开发。

如果公司普及了项目管理系统，可以如图只记一个开发版本和开发时间，其余在项目管理系统流程中完成，定时同步状态就好；如果没有项目管理系统，设计、前端、后端、测试各开发时间都可以记录在这里做简单的备份与跟踪。

3.4 验收反馈

image.png

在中大型公司做toB产品的人，或多或少都有一点与需求方撕逼的经历，或许是需求不明，或许是理解有误，或许是仅仅是没有做好需求验收跟踪。这个阶段是对需求的收尾，时刻提醒自己明确状态，最大限度避免撕逼。

• 【验收状态】【验收时间】请求验收、待验收、已验收、拒绝验收
  如果条件允许，一定通过正式邮件进行验收并记录状态。