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

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

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

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

第一步：整理需求池

需求池整理示例。

示例如下：

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

文档说明：

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

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

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

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

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

第二步：需求讨论

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

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

会议记录：产品经理。

会议说明：

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

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

第三步：初稿需求整理

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

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

列表字段：编号、所属模块、子模块、需求描述、场景描述、优先级、备注等。备注说明：分别把前端、后台和硬件的需求分开列。这样展示会更清晰明了。第四步：需求确认会

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

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

会议记录：产品经理。

会议说明：

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

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

第五步：最终需求表

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

最终需求列表：

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

项目技术需求表

文档说明：

项目需求的定义、修正、落实、澄清、锁定、细化的目的在于在项目实施过程前、中、后使客户与项目组之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更（包括：需求确认，需求变更和需求跟踪控制）。