在产品设计流程中，需求评审是必备环节之一，那么，产品经理要怎么确保需求评审的顺利进行呢？这篇文章里，作者就结合自己的经验，谈了谈自己关于需求评审的理解，或许会对你有所帮助。
需求评审是产品设计流程中的必备环节。评审时，产品经理可能会遇到各种刁钻又犀利的问题，一不小心就变成了“撕逼现场”、“批判大会”。评审会似乎成了产品经理面临的一项挑战。
不过我认为只要认真准备，评审会没有那么可怕，只是产品经理成长过程中的一道槛儿而已，跨过去之后会很多事情就水到渠成了。
今天跟大家聊聊我对需求评审的理解。
我理解的产品需求评审实际包含两个环节——“需求评审”和“需求设计评审”。
实际工作中，产品绝不缺少“需求来源”。除了产品经理主动挖掘需求外，业务、市场、运营、客户、领导都会提各种需求。这些需求并不一定是真正符合产品定位的“需求”，甚至是“伪需求”。所以需要通过评审的方式把控产品需求，避免造成资源浪费。
需求评审属于产品规划层面，侧重于确认需求是否有价值，是否要实现，以及实现的优先级和版本计划等。需求汇聚到产品经理手中之后，大部分需求在产品团队内部评审后就可以确定，一些重大需求则需要向上汇报后确定。
当然不同的公司有不同的工作方式，有些公司的产品需求主要是产品 leader 和上级确定的，产品经理很少参与需求定义过程，只是接收需求，所以需求评审的工作并不多。
需求评审只是定义了需求是什么，但是实现方式有多种。B 端产品经理对需求理解更深入，为了方便沟通，减少需求传递过程的认知偏差，会直接产出产品原型。完成设计方案后，需要通过评审会确定设计是否满足产品需求，以及设计的合理性，这就是“需求设计评审”。
设计评审侧重于需求设计方案和实现逻辑的评审，一般包含团队内部评审和产品线评审。
内部评审主要是通过团队的力量查缺补漏，减少正式评审时可能遇到的阻力。对于 B 端产品，系统之间的关联性比较强，通过内部评审还可以拉通、对齐关联系统，实现系统间的有效联动。
产品线评审主要是面向业务方、技术团队，目标是确认设计方案，推动设计落地，评审中包含了大量设计细节的澄清。
需求设计评审是从设计转到开发非常重要的环节，如果方案问题较多，修改后需要进行二次评审。如果评审不充分、不到位，后续的开发测试容易出现各种意外，产品经理则要不断地填坑。
评审是很重要的一种信息拉通方式，不同公司对需求评审的重视程度不同，带来的工作结果也是千差万别。
有些公司产品需求主要是自上而下逐级传达而来，也就是大家常说“一句话需求”。产品经理接到来自上级的需求后，为了保证对需求理解的准确性，需要了解需求的背景、用户场景，拆解需求，挖掘需求的本质。转化成产品需求后，再去跟上级汇报确认产品需求是否正确。
沟通过程中，需求评审会就简化成了“需求确认”。这种方式的好处就是参与的人数少，比较容易达成一致。但是由于评审范围只是局限在产品经理和直属领导之间，很难收到更广泛的、大众的意见。尤其是有些需求并非来自直属领导，这种方式就无法保证需求的准确性。
我就曾经经历过这种情况，本以为需求已经确认过了，不会再有大的分歧了。但是沟通范围扩大后，仍然有不同的意见，甚至从根本上推翻了产品需求。
所以对于一些小需求可以简化需求评审的形式。但是对一些重大需求，还是要拉上相关的评审人员，尤其是需求提出人，这样才能达到评审效果，避免后期出现不必要的扯皮。
正常流程下，需求设计评审是面向技术人员的。不过对于一些重要的产品需求，领导比较关心实现效果，产品经理还要将设计方案向上汇报。评审通过后，才能推进需求开发。
面向领导汇报和面向技术实现还是存在较大区别的。
1）向上汇报
为了方便领导做决策或者指出修改方向，产品经理最好准备 2-3 个方案。同时需要准备大量的材料作为设计方案的铺垫，比如流程图、数据分析、竞品报告等。
这些材料的目的是让领导了解设计依据，让后续的设计表述有理有据，增加领导对设计方案的信心。汇报时，这些材料重点讲解结论即可，不需要做细节阐述、达成一致，领导感兴趣时会主动发问。
如果评审过程中领导对设计点有疑问时，这些材料还可以成为重要的佐证。
2）向下落地
评审会是对完整设计方案的评审，不是技术讨论会。上会的设计方案必须是明确的，能够有效地指导开发工作。如果设计方案时存在技术上的疑问，产品经理要及时与技术人员确认解决，不要带到评审会上讨论。否则设计评审会就容易变成需求、技术讨论会。
面向技术的设计评审会，核心目标是对齐需求、传达设计方案。评审会前要消除 80% 的分歧和问题，评审会上对 20% 的问题查缺补漏，完成方案优化迭代。
评审时面对各个团队的同事甚至领导，产品经理要保持自信、冷静，这样才能让自己从容地应对别人的质疑。人在着急、紧张的情况下，思路容易混乱，反而让自己的思路不完整，缺乏条理性。当然自信是建立在充分准备的基础上，盲目自信也不可取，该认怂时就要认怂。
如果确实无法做到自信冷静，可以在正式评审前自我预演一遍，逐步建立自己的自信心。
无论评审前如何充分准备，过程中总会遇到意想不到的场景。这很正常，也是评审会的意义所在。如果会上可以解决的，那就当场弥补。如果无法解决就记录下来，作为遗留问题会后解决。不要欲盖弥彰，大家的眼睛都是雪亮的。后期开发阶段暴露出来，问题会更严重。
评审会是交流沟通的机会，产品经理既要把自己的思路、方案输出给参会人员，也要能够接收、倾听别人的意见，这样才能了解别人的想法。千万不要别人一提问题就着急，要通过摆事实、讲道理去化解别人的疑问。
设计评审会人数通常比较多，大家各抒己见，思维会比较活跃，可能会激发出很多奇思妙想，造成会议跑题。产品经理要及时控制会议讨论的范围，保证会议的效率。
评审会后还有后续的跟进，这些细节就不一一赘述了。
需求评审会可以看作是产品设计的总结和记录，甚至是产品的提前预演，也是个人能力的重要组成部分，值得不断总结和提升。
不过相对于评审过程中的各种技巧，我觉得设计阶段的充分准备和日常工作中的有效沟通更加重要。好比是人已经上了战场，才想起来要磨枪，其实一切都晚了。
祝愿大家评审会顺利、丝滑～
专栏作家
子牧先生，公众号：子牧UXD（HelloDesign），人人都是产品经理专栏作家。产品体验设计师。8年互联网行业经验，擅长体验设计思维、设计方法论、交互设计研究。
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。