解决方案

一、规范

1、建议引入需求封版节点，需求评审后原则上不允许修改需求内容，除非项目人员达成一致
2、建议需求需要改动需要形成更新机制，规范需求修改的流程
3、建议整理一份前端规范，让产品、研发、测试 达成一致共识

二、评审前

（1）、产品经理

1、和业务方认真推演产品要解决的问题,深挖业务述求,业务方是供的产品方案可以作为参考,不能作为指南。
2、充分准备需求原型和PRD,反复推敲产品方案,确保所有的功能点都能实现闭环,正常和异常场景都要考虑。
3、提前找到此项目对应的技术负责人,认真沟通方案和想法,让技术人员可以参与到前期设计中,技术前置驱动
4、提前将完整的原型和PRD发给相关人员,以便他们提前阅读相关文档,深刻理解需求,有疑问的点提前标注出来,方便在开会的过程中积极地去参与这个会议,抛出疑问点。
时限:建议提前一天,确定会议时间、地点、预计需要时

（2）、研发、测试

1、团队制定好规范,利用各自碎片化时间,提前介入进来理解解需求。前期了解过程中除了关注功能要求,还需要关注数据类型、接口定义、性能要求、安全性等,这个根据具体业务进行评估,例如高并发场景,频繁请求的场景等。同时还需要考虑一些隐性需求。
2、技术负责人可以前置到需求沟通和设计阶段,给产品经理提供必要的技术支持,协助评估产品方案的可行性。
时限:建议提前2天

三、评审中

（1）、后端

1、关注方案可行性的评估,重点在需求逻辑可行性、技术难度、工作量和改动成本上
2、关注需求逻辑的覆盖度,帮助产品经理做好逻辑的查漏补缺
3、关注研发过程中的实现风险

（2）、前端

1、关注需求场景及业务合理性
2、关注页面样式交互,为产品经理提出一些更合理的样式交互建议
3、关注技术方案和成本评估,尤其关注新页面中交互与已有统一标准组件的评估"

（3）、测试

1、关注需求的逻辑性及合理性
2、关注需求描述的准确程度、是否排除二义性等
3、关注整个迭代的质量风险及进度,保证交付的稳定性"

四、评审后

（1）、产品经理

会议纪要：
1、待讨论
2、待完善
3、已确认

（2）、项目经理

待办项跟进：
1、整理会议中记录的问题,在原型和PRD中进行调整和补充,有需要的话,可以拉上相关的人员针对这些问题,进行二次评审。
2、开发过程中,如果涉及到需求的调整.一定要在原型和PPRD中标记修改记录,并且及时通知相关的人员,确保理解一致

四、交付需求

1、如果交付日期不变，则可以考虑：
砍：砍掉优先级低的需求，来减少工作量。
加：增加人力或部分工作外包，来分摊工作量。
降：牺牲部分不重要的质量来保交付，比如只精测优先级高的需求，优先级低的风险低的可以让开发自测，或产品验收测试。
2、如果交付日期可变，延长交付时间。

五、度量需求影响

1、统计各需求情况，分析各产品人员的情况
返工时长：由于需求缺陷或变更造成返工的工作量；
延期次数：由于需求缺陷或变更造成项目或迭代延期的次数；
延期天数：由于需求缺陷或变更造成项目或迭代延期的总天数；
2、需求问题的类型，需求相关的耗时等，以便分析影响，还有后续的统计分析。

问题：

图片.png