产品评审流程图

整理文档（邮件）

修改

了解、确认需求及各自负责部分

逐条需求确认通过

N

项目背景目标需求概述（邮件）

分工：确定参与人员（邮件/群聊）

评审前：确认需求

Y

汇总问题及解决方案，并整理上传至wiki

初稿（邮件）

需求全部通过

（变更）内容是否完整

文档是否需要变更？

测试

评审后

正式评审产品、研发、测试确认需求理解（可迭代）直到评审通过

针对某条需求是否存在疑问？

考虑的问题

产品（产品、产品负责人）

研发

项目阶段

确认需求内容是否达到了系统目标、是否有遗漏、是否有错误等：1. 不确定的方案给确定下来2. 探讨方案实现的难易程度3. 确保某些需求的可行性4. 发现可能与原有产品逻辑相冲突的地方5. 后续功能实现的规划，考虑是否与现有逻辑有冲突

需求评审时常发生的情况 ：1、与会人员对需求的目标不明确，易发散思维，最终偏离方向。2、对某个需求点相持不下，认为该需求不合理/开发周期长不划算，从而导致场面混乱，长时间僵持下去。3、对技术方案探讨不定，对问题点无限引申。4、遗漏评审时的待改动的需求点，会后找相关人员再次确认。需求文档：1. 项目背景2. 项目目标3. 需求概述3. 需求详细描述4. 业务流程图（对某些复杂功能/逻辑的分解）5. 项目风险（说明此次版本可能带来的问题或考虑不够完善的地方）需求检查单可以分成2类：需求形式的检查单和需求内容的检查单。需求形式的检查可以由QA人员负责，主要是针对需求文挡的格式是否符合质量标准来提出的需求内容的检查是由评审员负责的，主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等，这是需求评审的重点。（需求文档自查清单）：1. 需求的逻辑表达清楚没歧义2. 对各个细节描述清晰（如金额保留两位小数、跳转也，3. 业务流程（功能的交互步骤和数据的流转）4. 各输入输出项（涉及到表单/数据的输入输出）5. 计算规则（某些特定须计算的规则）6. 判断逻辑 （业务流程中出现的一些判断逻辑、各种判断下的反馈情况、账号的权限范围）7. 特殊情况（如是否支持横屏啊之类的）

1. 项目负责人与各干系人未界定：负责人应该在项目启动时确定（需方的高层管理人员、中层管理人员、具体操作人员、IT主管、采购主管；供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家等等。）2. 需求文档的背景、目的未说明，部分项目成员并未理解业务目标；项目背景、项目目标、需求概述和需求详细描述，必要的时候可以带上项目风险（说明此次版本可能带来的问题或考虑不够完善的地方）和业务流程图（对某些复杂功能/逻辑的分解）。（在项目确定初期，由需求方提供需求概要，列出主干功能并简要描述，研发与测试负责人来判断需求功能要不要实现。在需求交出初稿的时候，研发与测试负责人即可以进行分工和排期）3. 需求文档归档至svn（需求文档+原型图）发布在云端的需求文档要求最新版本，每次要是有需求改动的部分，在禅道上，svn要将原有的需求文档替换覆盖，并且整理出相关的修改点（如第几章第几点修改，方便定位需求变动部分）（需求统一说明细节问题：如金额保留两位小数、模糊查询、跳转页面）（减少隐藏需求：如果是功能改造或优化的需求，提供原有的需求说明，如邮费部分的功能，提供之前的相关需求如满500包邮、深圳龙岩免邮等）4. 需求定版不明确，会后常有改动和变更：开发过程中不确定或歧义需求太多，未走正规需求变更，直接给研发加任务。研发与测试都不明白的功能找产品了解时，直接转换成新需求。（避免口头需求，提成需求反馈，或者bug指派、抄送给产品）（需求变动不可避免，变动记录和协调问题，按照变动大小：4.1 有些改个字啥的，不用做变更记录， 4.2 超过10分钟以上的需求，和项目负责人商量，确定这一期变更，再添加对应需求，更改项目排期；4.3 再者一些很大变更，不允许变更的情况，直接收集记录下来由下一期做）5. 需求负责人变动时，需求交接争议问题，目前由于没有项目负责人，还是需要产品、研发、测试的负责人进行讨论得出。PS： 统计各主流系统的项目流量，并在新增需求项目上线后再次统计项目流量。在需求初稿的时候，研发与测试负责人分工安排，对于需求完成稿发送后给相关人员阅读文稿的前置时间：（提供参考时间）字数1000，图5，难易程度正常（难易程度等其他因素时长误差为0.5h）熟悉新增：0.7~1h熟悉修改：1.4~2h陌生新增：2.1~3h陌生修改：2.8~4h网站流量分析：（热力图、眼动热点图、条形图、饼状图、曲线图）网站访问量的增长趋势图、用户访问最高的时段、访问最多的网页、时段访问量统计分析、日段访问量统计分析以及周月访问量统计分析关联需求功能点？？？？！！！！

评审前：非正式评审

开发负责人

是否小修改？

合理性评定质疑需求优先级

结束或启动新流程

需求修改、变动

测试负责人

可行性评定（系统实现成本）

理解需求功能划分

逐条模拟场景说明

提出建议/争议点

与所有人确定时间发起评审

1. 上传文档（svn、禅道）2. 通知需求评审已完成（邮件）3. 跟踪问题，保证评审结果落实

产品评审流程图

讨论确定

分期延期

评审中：正式评审

答疑

需求完成稿（邮件）

小范围的沟通技术可行性分析（迭代）直至确认需求可行

需求变更复审：1. 产品评审2. 研发阶段3. 测试阶段

1. 记录会议纪要2. 罗列出会议中有争议仍待解决的问题、改动的部分和结论（上传至wiki）