从需求池整理到需求确认的全过程产品经理.docx
《从需求池整理到需求确认的全过程产品经理.docx》由会员分享，可在线阅读，更多相关《从需求池整理到需求确认的全过程产品经理.docx（8页珍藏版）》请在冰豆网上搜索。
从需求池整理到需求确认的全过程产品经理
从需求池整理到需求确认的全过程（产品经理）
从需求池整理到需求确认的全过程
需求分析是整个项目计划阶段的重要活动，也是软硬件生存周期中的一个重要环节，该阶段是分析系统在功能上需要“实现什么”，而不是考虑如何去“实现”。
需求分析的目标是把用户对待产品提出的“要求”或“需要”进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软硬件需要实现哪些功能，完成哪些工作。
此外，软硬件的一些非功能性需求（如：
软硬件性能、可靠性、响应时间、可扩展性等），软硬件设计的约束条件，运行时与其他软硬件的关系等也是软硬件需求分析的目标。
第一步：
整理需求池
需求池整理示例。
示例如下：
列表字段：
编号、需求分类、需求描述、场景描述、需求来源、提出时间、是否解决、优先级、备注等。
文档说明：
（1）需求分类：
一般需求可以划分为五类。
（2）场景描述：
主要描述需求发生的场景。
（3）需求来源：
主要是记录需求产生的方式。
（4）优先级：
主要是描述需求优先级排列方式。
（5）备注：
一般用于抒写，不解决的原因和如果解决需要注意什么。
第二步：
需求讨论
汇总完所有的需求到需求池后产品经理就需要组织需求大会了，邀请相关同事参会，讨论V1.0版本需要做哪些需求。
参会的人员：
相关领导、项目经理、产品相关人士、运营、财务、技术。
会议记录：
产品经理。
会议说明：
（1）会针对每一个需求进行探讨，V1.0版本做与不做，所以会议时长一般会很长。
产品经理需要对每一个讨论过的需求标记优先级，是否需要第一个版本实现做备注，延后处理的需求，需要标明延后原因等等。
一般都是在我之前列表的需求池列表的后面做处理。
（2）针对需求一般会围绕以下几个维度进行讨论：
第三步：
初稿需求整理
会议结束，产品经理需要做的事情，就是把需求池列表的需求进行过滤，把V1.0版本初步需要做的需求进行进行一个需求的整理，单独做成V1.0需求列表。
我简单做了一个需求列表的Excel的表格，仅供参考：
列表字段：
编号、所属模块、子模块、需求描述、场景描述、优先级、备注等。
备注说明：
分别把前端、后台和硬件的需求分开列。
这样展示会更清晰明了。
第四步：
需求确认会
确定汇总后所有的V1.0版本需求。
参会的人员：
相关领导、项目经理、产品相关人士。
会议记录：
产品经理。
会议说明：
（1）确认需求的过程中一般又会爆发新的一轮需求的讨论。
（2）产品需要记录这次会议上针对需求提出来的一些讨论结果的记录。
第五步：
最终需求表
需求的确认会有可能会有很多次的需求会议，才会确认下来，但是不管经历了几次需求确认会，都会走到最终定下来的这一稿。
最终需求列表：
列表字段：
编号、所属模块、子模块、需求描述、场景描述、优先级、产品负责人、完成时间、预计用时、对应开发人员、完成情况等。
项目技术需求表
文档说明：
项目需求的定义、修正、落实、澄清、锁定、细化的目的在于在项目实施过程前、中、后使客户与项目组之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更（包括：
需求确认，需求变更和需求跟踪控制）。
需求
内容
基本需求
服务及保障
预投资额度
软件1700万，硬件2000万人民币
交付主体
拖期
超支
投诉
扣款
实施周期
工期理解
成本理解
基本目标
总体规划
基本功能
系统功能
业务功能
第三方对接要求
外部支撑资源状况
商务条件
组织范围
应用系统范围
物理范围
技术条件
设计依据
需求变更管理办法
保障条件
实施条件
会审保障条件及依据
争议解决办法
功能需求
系统功能需求
系统构架
系统模块
系统交割分工界面
系统扩容方式
系统数据精确度
系统数据精确度时间特性
系统数据精确度适应性
软件业务逻辑功能需求
功能结构清单
软件模块组成图
第三方产品
系统支撑
数据库支撑
WEB应用
软件争议解决办法
软件应用逻辑功能需求
内部数据控制机制
内部数据调度方式及过程
内部模块数据处理流程图
硬件功能需求
系统支撑硬件及性能指标
技术参数
安装环境要求
网络环境
外部结构
业务逻辑
应用逻辑
多次性费用说明
交付依据及验收测试方案
验收标准
功能测试内容
性能测试内容
测试条件
测试方法
测试过程
服务技术要求
技术手册
系统说明文件
安装
测试
操作
维护
排除故障
软件资料
使用手册
代码所有权
硬件资料
安装
测试
操作
维护
排除故障
技术响应要求
会审
会审意见
签名（会议记录员）：
日期：
会审签名
签字：
日期：
升级会员 