背景
上图为[产品迭代开发协作流程]，上次聊了一下关于 Code Review 的一些思考。
在上面的流程中，需求评审通过后，要产出最终的需求文档、原型等交付物，还要对本次需求封版；在测试阶段的补充需求的处理方式；上线后记录或反馈的问题列入下一版的迭代。
可是，流程中都是比较理想的状态，现实工作中并没有达到设想的目标。作为一个开发人员，分别站在产品经理的角度和开发人员的角度分析一下问题的可能原因。
需求挖掘和需求管理
由于自己是开发人员，所以对需求的挖掘和管理并没有什么经验，所以分享人人都是产品经理中的一篇文章：需求评审之前，需求挖掘和需求管理怎么做？，其中最后一部分也写到了如何进行需求评审
需求评审会的目标
为了保证需求评审能够顺利进行，一般都会提前做好相关的准备，产品经理要能够讲清楚需求的来源，为什么用这个需求，加入这个需求有什么意义，解决了谁的什么问题，这个需求需要哪些配合，同类竞品是否有该需求……整个需求评审的过程，考验了产品经理对需求的熟悉程度以及对需求的判断能力。
在这里总结一下需求评审的目标：
- 避免做过多无用需求；
- 评审需求的技术可行性，是否有技术难点；
- 减少需求变更的风险；
- 保证需求质量，避免开发过程中才发现需求不合理再去调整；
- 确定需求优先级别；
- 当然也会有砍掉一些需求的可能性，也可能会增加一些需求；
- 收集大家有效建议，改进需求；
需求讲解的目标
需求讲解阶段可能也有部分内容与评审一致，在向参会的设计、研发和测试团队，讲清楚需求的背景和来龙去脉（需求的来源，为什么用这个需求，加入这个需求有什么意义，解决了谁的什么问题，这个需求需要哪些配合，同类竞品是否有该需求……整个需求评审的过程）
产品经理需求用自己的理解复述给大家听，一方面确定自己的需求，就是需求的背后真正的动机，二是要让需求去实现产品需求的这一票人能听懂并正确理解产品逻辑
在这里总结一下需求讲解的目标：
- 交代需求背景、场景；
- 本次需求要达到的目标；
- 向参会的设计、研发和测试团队准确地传达需求；
- 让设计师清楚自己要产品设计成什么样；
- 让研发人员给出合理的技术方案；
- 让测试团队输出正确的测试用例；
需求评审和讲解别敷衍交差怎么办？
- 有时大家会把需求评审和讲解这事儿当成一个过场，在这个阶段不重视需求，到真正开发实施的时候才发现风险（产品经理很委屈）
- 大部分开发人员对业务知识比较欠缺，更注重的是技术，所以在听需求的时候需要一个思考的时间和过程，而在没有铺垫的前提下（即使有邮件提前通知了，但是也没有见到原型、需求文档等资料）突然开评审、讲解需求，可能参会人员还没有反应过来，需求已经顺利且愉快的结束了，开发同学抱着会后自己看原型的心态，在会上也给不反馈，等做的时候发现问题一大堆（开发抱怨产品经理需求讲得烂）
各有个的说辞......
向前迈出一小步，问题可能就解决了
假如说
产品经理在发送约会邮件的时候，同时把自己的原型和需求文档提前发给参会人员，提前做些铺垫，给大家一个思考的时间和过程。
认真对待这几次会议，把这些当成一次次对自己综合能力的考验机会，把自己当成领头人，带着大家向正确的方向上前进。把这每次需求的评审或讲解当成自己产品的路演过程，不但会顺利很多，也会为自己在团队中的影响力加分。要想达到这样的效果，自己也需求付出更多的努力，努力丰富的业务知识，等等
另一些能力欠缺、准备不充分的产品经理来说，组织每次会议都可能是一场场噩梦哈。。
而对于开发同学，也需要认真对待这些事，仔细查阅收到的邮件及资料。站在用户、运营、管理者等多个角度去分析和判断需求。更重要的是，平时要多学习业务领域知识，做到“能听懂产品经理在说什么”，有利于正确理解需求、判断需求是否合理、关键时候能给出合理的建议或解决方案，思考业务流程的边界条件、异常情况，等等
而且每个阶段双方都要有相应的交付物，比如：开发会对产品经理有原型、文档、规则等的需求。同时产品经理也会向我们要开发计划，XP 更新，demo 时间等。每个阶段都有相应的清单（每个阶段或环节上要做哪些动作）如：发布后要看日志、要从页面是否能正常地请求到数据等等
总结
上面聊了从需求挖掘到需求讲解、传递的过程，以及每个阶段的目标，还有理想与现实产生差距的原因，最后说到如何为需求做准备，如何做会前预习，以及各自丰富自己的知识。
正确的心态去做这件事，需求评审未必会成为一个仪式化的流程环节，目标是规避各种风险，产出一个稳定的需求。然后工程师在设计开发的过程中，可能还会不断跟产品经理交流，来进一步明确需求，可能需求分析的过程直到产品上线的一刻。这种情况不可避免，但是尽量要避免（需求评审和讲解就是解决这些问题的方案），不然会影响需求从产生到实施的整个周期。
希望重视需求评审和讲解，在开发流程中发挥作用。如果有哪些地方总结得不合理或需要补充的，欢迎一起交流～
