从需求池整理到需求确认的全过程(产品经理)

从需求池整理到需求确认的全过程

需求分析是整个项目计划阶段的重要活动，也是软硬件生存周期中的一个重要环节，该阶段是分析系统在功能上需要“实现什么”，而不是考虑如何去“实现”。

需求分析的目标是把用户对待产品提出的“要求”或“需要”进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软硬件需要实现哪些功能，完成哪些工作。

此外，软硬件的一些非功能性需求（如：软硬件性能、可靠性、响应时间、可扩展性等），软硬件设计的约束条件，运行时与其他软硬件的关系等也是软硬件需求分析的目标。

第一步：整理需求池

需求池整理示例。

示例如下：

列表字段：编号、需求分类、需求描述、场景描述、需求来源、提出时间、是否解决、优先级、备注等。

文档说明：

（1）需求分类：一般需求可以划分为五类。

（2）场景描述：主要描述需求发生的场景。

（3）需求来源：主要是记录需求产生的方式。

（4）优先级：主要是描述需求优先级排列方式。

（5）备注：一般用于抒写，不解决的原因和如果解决需要注意什么。

第二步：需求讨论

汇总完所有的需求到需求池后产品经理就需要组织需求大会了，邀请相关同事参会，讨论

V1.0

版本需要做哪些需求。

参会的人员：相关领导、项目经理、产品相关人士、运营、财务、技术。

会议记录：产品经理。

会议说明：

（1）会针对每一个需求进行探讨，V1.0版本做与不做，所以会议时长一般会很长。产品经理需要对每一个讨论过的需求标记优先级，是否需要第一个版本实现做备注，延后处理的需求，需要标明延后原因等等。一般都是在我之前列表的需求池列表的后面做处理。

（2）针对需求一般会围绕以下几个维度进行讨论：

第三步：初稿需求整理

会议结束，产品经理需要做的事情，就是把需求池列表的需求进行过滤，把V1.0版本初步需要做的需求进行进行一个需求的整理，单独做成V1.0需求列表。

我简单做了一个需求列表的Excel的表格，仅供参考：

列表字段：编号、所属模块、子模块、需求描述、场景描述、优先级、备注等。

备注说明：分别把前端、后台和硬件的需求分开列。这样展示会更清晰明了。

第四步：需求确认会

确定汇总后所有的V1.0版本需求。

参会的人员：相关领导、项目经理、产品相关人士。

会议记录：产品经理。

会议说明：

（1）确认需求的过程中一般又会爆发新的一轮需求的讨论。

（2）产品需要记录这次会议上针对需求提出来的一些讨论结果的记录。

第五步：最终需求表

需求的确认会有可能会有很多次的需求会议，才会确认下来，但是不管经历了几次需求确认会，都会走到最终定下来的这一稿。

最终需求列表：

列表字段：编号、所属模块、子模块、需求描述、场景描述、优先级、产品负责人、完成时间、预计用时、对应开发人员、完成情况等。

技术需求池确认

项目技术需求表

文档说明：

项目需求的定义、修正、落实、澄清、锁定、细化的目的在于在项目实施过程前、中、后使客户与项目组之间建立对需求的共同理解，维护需求与其它工作成果的一致