项目产品需求评审流程及详细的评审规范实例

本文由医药研发项目管理软件整理：项目过程中产品需求评审至关重要，需求评审会议组织的如何直接决定了后续项目的实施是否顺利，而产品评审流程设置的如何直接考验了项目经理的管理水平，今天分享给大家一个产品需求评审流程图及详细的说明实例，供大家参考。

1. 项目负责人与各干系人未界定:

负责人应该在项目启动时确定（需求方的高层管理人员、中层管理人员、具体操作人员、IT主管、采购主管；供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家等等。）

2. 需求文档的背景、目的未说明，部分项目成员并未理解业务目标:

项目背景、项目目标、需求概述和需求详细描述，必要的时候可以带上项目风险（说明此次版本可能带来的问题或考虑不够完善的地方）和业务流程图（对某些复杂功能/逻辑的分解）。

（在项目确定初期，由需求方提供需求概要，列出主干功能并简要描述，研发与测试负责人来判断需求功能要不要实现。在需求交出初稿的时候，研发与测试负责人即可以进行分工和排期）

3. 需求文档归档至SVN/Git（需求文档+原型图）:

发布在云端的需求文档要求最新版本，每次要是有需求改动的部分，在禅道上，SVN/Git要将原有的需求文档替换覆盖，并且整理出相关的修改点（如第几章第几点修改，方便定位需求变动部分）（需求统一说明细节问题：如金额保留两位小数、模糊查询、跳转页面）

（减少隐藏需求：如果是功能改造或优化的需求，提供原有的需求说明，如邮费部分的功能，提供之前的相关需求如满500包邮、XXX免邮等）

4. 需求定版不明确，会后常有改动和变更：

开发过程中不确定或歧义需求太多，未走正规需求变更，直接给研发加任务。研发与测试都不明白的功能找产品了解时，直接转换成新需求。

（避免口头需求，提成需求反馈，或者bug指派、抄送给产品）

需求变动不可避免，变动记录和协调问题，按照变动大小：

4.1 有些改个字啥的，不用做变更记录。

4.2 超过10分钟以上的需求，和项目负责人商量，确定这一期变更，再添加对应需求，更改项目排期；

4.3 再者一些很大变更，不允许变更的情况，直接收集记录下来由下一期做。

5. 需求负责人变动时，需求交接;

争议问题，目前由于没有项目负责人，还是需要产品、研发、测试的负责人进行讨论得出。

PS：统计各主流系统的项目流量，并在新增需求项目上线后再次统计项目流量。

在需求初稿的时候，研发与测试负责人分工安排，对于需求完成稿发送后给相关人员阅读文稿的前置时间：（提供参考时间）

难易程度正常（难易程度等其他因素时长误差为0.5h）

熟悉新增：0.7~1h

熟悉修改：1.4~2h

陌生新增：2.1~3h

陌生修改：2.8~4h

网站流量分析：（热力图、眼动热点图、条形图、饼状图、曲线图）

网站访问量的增长趋势图、用户访问最高的时段、访问最多的网页、时段访问量统计分析、日段访问量统计分析以及周月访问量统计分析

需求评审时常发生的情况 ：

1、与会人员对需求的目标不明确，易发散思维，最终偏离方向。

2、对某个需求点相持不下，认为该需求不合理/开发周期长不划算，从而导致场面混乱，长时间僵持下去。

3、对技术方案探讨不定，对问题点无限引申。

4、遗漏评审时的待改动的需求点，会后找相关人员再次确认。

需求文档：

1. 项目背景

2. 项目目标

3. 需求概述

3. 需求详细描述

4. 业务流程图（对某些复杂功能/逻辑的分解）

5. 项目风险（说明此次版本可能带来的问题或考虑不够完善的地方）

需求检查单可以分成2类：需求形式的检查单和需求内容的检查单。

需求形式的检查可以由QA人员负责，主要是针对需求文挡的格式是否符合质量标准来提出的

需求内容的检查是由评审员负责的，主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等，这是需求评审的重点。

需求文档自查清单：

1. 需求的逻辑表达清楚没歧义

2. 对各个细节描述清晰（如金额保留两位小数）

3. 业务流程（功能的交互步骤和数据的流转）

4. 各输入输出项（涉及到表单/数据的输入输出）

5. 计算规则（某些特定须给出计算的规则）

6. 判断逻辑 （业务流程中出现的一些判断逻辑、各种判断下的反馈情况、账号的权限范围）

7. 特殊情况（如是否支持横屏啊之类的）