题，但是那时说什么都晚了。还可能出现有些需求实现方式与需求评审时的结论有所出入，会陷入尴尬的境地
3、总结
（1）日常型和复杂型的区别
日常型流程的需求评审会融合复杂型的立项会议和需求评审这两个环节，相当于合二为一
日常型流程不会对设计、测试进行评审，在需求评审完成且没有问题后，开发人员便开始编写代码。与此同时，测试人员撰写TC用例。两者同步进行，多线程开展项目
（2）适用场景
复杂型：大公司或者0-1搭建产品，产品还原度高但周期长
日常型：创业公司或者从1-N迭代产品，迭代效率高但质量堪忧
2.需求评审
之所以要把需求评审单拿出来讲，可见其在产品工作中举足轻重的位置。需求评审的本质其实就是：
把用户的需求语言转化为产品功能并翻译成开发能听懂的技术语言
开会的目的是为了告诉组内成员：我们要做什么东西、为什么、做多少、最后需要达到什么程度
如果在评审过程中力压群雄，自然可以在开发测试同学心目中树立起了专业形象，往后的项目推进也会更加顺利。相反，如果事先没有准备充分，评审过程漏洞百出、逻辑混乱，则会让大家觉得产品没有考虑清楚，大家自然也就马马虎虎
一般来说，需求评审分为3个阶段：会议前、会议中以及会议后，接下来会详细展开讨论
会前准备
1、PRD 需求文档
作为我们展示需求内容的工具，它的质量或多或少会决定项目之后的路是否平坦。在下一章讲有关项目文档管理的内容时，我们会对其详细说明
2、邮件通知
我们需要在会议开始前，给参加会议的所有相关人员发送一封邮件，最好提前1-2天，好让大家合理安排好时间，尽量避免出现缺席的情况
在邮件中主要说明以下几点内容：时间、地点、会议议题、内容的精简描述（20字以内）、会议时长、并在最后附上PRD文档
会中讲解
1、逻辑清晰
有整体讲解的思路框架，建议由总及分的形式，比如：本次迭代主要是开发一个社交功能，目的是为了提高用户留存并激发用户活跃。该功能主要由以下4部分构成，首先...其次...然后...最后
2、明确背景与目的
要让团队成员明白我们为什么要做这个需求、它能解决什么问题、我们最终要实现什么样的效果，从宏观角度去剖析项目意义。无论什么岗位的人都需要一种团队归属感，避免让人变为一个接收任务并完成任务的工具。要让团队中每个人都了解项目的来龙去脉，这样做会更有利于达成共识并落实项目
3、铁证胜于雄辩
一定要有支撑需求的论点，可以是数据分析得来的结论、用户反馈的痛点问题、市场调研的问卷信息等，千万不要说因为老板想做或者我觉得用户需要这个功能
4、会议记录
在会议中，把已确认无误的需求标记出来，并对存在歧义、有待商榷的需求进行记录。因为可能在会议上，有的需求会被质疑。如果该问题你没有想过，那么就不要嘴硬的去争论。别忘了大家的初心是一致的，都是为了能把自己的工作做好从而更好的服务于产品本身
（1）5分钟原则
如果一个问题在大家讨论了5-10分钟后，还没有一个可行的实现办法时，我们就不应该再做无谓的讨论，而是选择在会后思考对策，不占用公共时间，
（2）60分钟原则
需求评审时长最好保证在60分钟以内，因为一个人有效的工作时长，或者说精力集中的时间最多45分钟。如果一个会议长达2、3个小时的话，对参会人员和项目开展都是弊大于利的
5、FAQ环节
一定要在会议的最后或者部分内容讲完后留下提问环节，因为好多时候他们其实发现了问题，要不就是对哪部分讲解没有领悟，但可能因为从众心理或者他误以为你就是这么设计的而没说，最后导致在开发过程中反复确认修改。
首先这样不利于整个项目的推进，因为开发人员发现有问题时还要同步给测试人员，导致拖慢节奏。而且如果大家都按照自己误以为理解的去做，最后做出来的产品可能和预想大相径庭
会后总结
1、查漏补缺
要对会议提出的修改内容进行重新编辑，包括PRD以及配合设计师修改UI图等
2、会议共识
要在问题整理清楚后发布会议共识，包括会议决议以及遗留问题，具体内容可参见下图：
小结
本文针对项目流程管理的知识点及方法内容进行了汇总，它在项目中主要起到规范项目框架的作用，并通过对流程的管理助力项目实施
在项目环节，一共会涉及到四种管理手段。其中，和流
