人人车检测师（需求评审面面观）

上次笔者同大家聊了聊如何写出一篇优秀的PRD（【万字长文】PRD面面观，手把手带你写出优秀的PRD）。

写完PRD之后，最重要的当然就是组织评审啦。

根据实际情况，比如公司要求或心里没底，可在组织正式评审之前，发起需求内审。

一、需求内审

进行需求内审的好处有很多。问题暴露越早，造成的影响和修正成本越小。此时只有产品经理投入了时间和精力，进行产品内审可以有效避免设计资源的浪费和需求评审时的争论。

1. 邀请对象

• 产品负责人（必选）；
• 同组的产品同事（可选）；
• UX/UI设计师（推荐）；
• 技术Leader或骨干（必选）；
• 需求关联业务方，运营、售后、商务等（推荐）。

2. 邀请准备

提前约好大家的时间，发送会议邀请，概括评审主要内容并附上评审用到的PRD文档。

如果有拿不准或者可能有争议的点，可以在会邀中说明，让与会者预先有个准备。

大多数情况下，与会者是不会看你的会邀内容和PRD的，因此要提前找到关键的同事讨论，对主要问题达成一致。

比如对于某个产品功能是否能满足用户和商业需求，可以同产品负责人或业务方讨论；对于页面跳转、导航等设计的合理性，可以同UX设计师沟通；对于功能的可实现性，可以找相关的技术同事请教。

在评审前做好充足的准备，可以提高沟通效率、节约与会者的时间，避免因为重大问题返工导致重复召开内审会议。

3. 评审技巧

在做内审时，最基本的要求是沟通表达能力，要做到吐字清晰，注意放慢语速（人在紧张是容易语速加快），陈述逻辑清晰，使用内部沟通语言（同写PRD时的要求）。

请一位熟悉文档的同事帮你记录会议纪要，包括：

• 讨论比较激烈且达成一致的点。
• 需要更改的点。
• 遗漏，需要补充的点。
• 多余，需要去掉的点。
• 未达成一致性、需要会后讨论的点。
• 表述PRD内容要做到顺序合理。想做好其实也不难，可以按照写PRD的思路。
• 交代需求背景，向大家讲清楚本次迭代为谁做、为什么做、要做什么。虽然不是实质功能，但是这点非常重要。你要尽量把与会者带入情境，人的思考脱离了情境就可能偏颇。
• 对照着业务流程图，讲述业务流程。先讲涉及的业务场景和角色，再讲主要的业务流程，最后补充次要业务流程。让大家对本期的需求范围有个直观的认识。这个部分非常重要，一定要讲出关键的流程、对之前流程的变动和可能存在问题的点，带着与会者去思考。一旦流程出现问题，往往就是大问题。
• 对着需求List告诉大家本期要做哪些需求，每个需求要按照Story的格式去讲，进一步强化为谁做、要做什么，为什么要做。
• 最后是讲每个需求的具体产品需求。这个部分是问题最多的部分，除了表述清晰之外，要说清楚自己这么设计的原因什么，不要只呈现结果。

评审过程中，要鼓励、引导参会者发言，充分收集各方的想法和建议。要尊重每个与会者的意见，即便可能是不成熟的。要善意的肯定对方的建议，表达自己的想法并和对方达成一致。

但是也要注意控制时间。一旦发生争论激烈或短时间难以有结果的点，要适时打断并跳过，避免陷入无休止的争论，浪费大家的时间。

在准备充分的情况下，不应该出现激烈争论的点。此时你要做好会后反思了：

• 争论的实质是什么？
• 应该怎么解决？
• 为什么我会前没有注意到？
• 下次该怎么避免？

会后务必要发送会议纪要，一方面是对与会者付出的尊重，大家提的意见我都收到了。另一方是二次确认，避免后续可能出现的扯皮。

根据会议纪要更新完PRD之后，也要记得再次发出来给大家确认。

二、关于UED设计

如果需求比较简单或对自己的PRD比较有信心，可以提交UED设计需求。

在人力充足的公司，UX设计会由专业的交互设计师担任；而在人手不足的情况下，产品经理就要兼职交互设计了。

在目前各类交互设计规范比较成熟的情况下（例如iOS人机交互指南、Material Design、Ant Design等），交互设计做到合格还是比较容易的。

UX完成后就是UI设计。UI设计建议让专业的UI设计师担任，尤其是用户端界面。一个好的设计师对于用户体验具有举足轻重的作用。

给新手产品经理几个建议：

• 跟设计师沟通不要只讲功能需求，要从用户需求开始讲起。让设计师理解为什么要做这样的需求，设计师才能有的放矢。
• 一定要定好设计排期。在追求完美设计的道路上时间永远是不够的。
• 打铁还需自身硬，平时一定要注意产品设计的积累。
• 在别人的专业领域多听建议，少指手画脚。
• 必要时拉上前端开发的负责人或技术骨干一起讨论，可能有意外收获。
• 不要用手指点设计师的屏幕，真的很惹人烦。

UX和UI完成之后一定要仔细验收，验收点包括：

• 界面流程和功能是否能够满足用户需求，是否有用、好用；
• 交互和界面设计是否与产品需求一致，比如想要突出的重点信息等；
• 设计是否具备可实现性，或者工作量适中。此类问题可以把开发同学拉到你的战壕里，一起说服设计师；
• 是否符合产品以往的设计习惯和设计规范；
• UX的标注是否合理、清晰、易于阅读等。

对于界面设计风格，除非有十足的把握，否则尽量不要和设计师争论，因为容易被设计师视为质疑其的专业性或者觉得你啥也不懂。即便要争论，也要态度谦和、有理有据，切忌得理不饶人。

三、需求评审

当设计稿都确认之后，就可以开始激动人心的需求评审了。需求评审主要思路和需求内审相同，后文主要描述需要额外注意的事项。

即便进行了设计内审，评审时也必须要完整的评审完，因为会议会有很多新的同事参加。

1. 邀请对象

• 产品负责人（必选）
• UX/UI设计师（推荐）
• 技术Leader或骨干（必选）
• 前后端等开发（必选）
• 测试（必选）
• 需求关联业务方，运营、售后、商务等（推荐）

2. 邀请准备

会议邀请要将PRD、UX和UI一并发送给与会者。

会议前记得拿着PRD、UX和UI和关键同事，比如技术骨干、业务方等沟通。一个顺利的会议都建立在会前充分沟通的基础上。需求评审会最主要的作用在于达成共识而非讨论。

3. 评审技巧

同样要发挥自己的沟通技巧，让与会者能够听清、听进去，避免在开发过程中才暴露问题，导致产生延期风险和开发资源的浪费。

同样需要请一位同事做会议纪要，除了记关键的事情之外，还要记录时间和负责人。比如对于一个有争论的需求，那么需要指定负责确认需求的负责人和要在何时之前确认解决方案。

在具体评审流程时，也有一些技巧分享给大家。

• 表述PRD的需求背景、业务流程、需求list同需求内审。
• 需求描述部分可以快速带过或者不讲，因为人面对大段文字之时，往往会产生抵触心理。比如阅读我的文章。
• 具体需求的功能可以对着带标注的UX讲解。图文对照，可以讲得更清楚，更易于与会者理解。
• 讲每个功能之前，同样要先讲清楚功能是为谁、为什么做，然后再讲怎么做。
• 将怎么做的时候，要讲清楚这是什么页面，怎么跳转进来，怎么跳转出去，页面内的主要功能、次要功能、默认状态、空状态、异常处理等。

准备充分的话，一般会有一些小修小改的问题。对于敏捷开发的团队（尤其是C端），会马上开始分配任务、评估故事点、进行迭代排期等。

这种做法对技术Leader、项目经理和开发团队的要求都很高。本人主要从事B端工作，没有经历过如此敏捷的团队。有需要的道友可以自行查阅资料。

会后的会议纪要也是必须要发送的，明确事、人、时间，以及完成项目排期的Deadline。

更新完相关的产品文档再次发送，就可以进入产品迭代了。

讲完需求评审的方法，笔者还想再详细解释其背后的原因。以帮助各位读者理解PRD评审的重要性。主要围绕几个关键点展开。

四、为什么要让与会者提前看PRD

1. 理解信息的过程

人在理解信息的时候，虽然发生在一瞬间，但其是有复杂的过程的。可以简单分为：

1. 外界刺激+感觉获取信息；
2. 调用相关的知识储备（记忆、知觉）；
3. 通过逻辑推理形成对信息的理解。

第1点即是通过PRD去传递信息，想要正确地传递信息，对PRD的质量有极高的要求。如何写好PRD可以参考我之前的文章。

第2点即是读者的专业知识、工作经验、对本项目的知识积累等。因此不同角色的人，看到PRD的关注点和理解也是不同的。

• 产品经理会关注业务逻辑、功能设计的合理性，以及能否满足用户需求。
• 设计师会关注通过怎样的设计能够更好的传达产品信息，满足用户需求的同时兼顾商业目的。
• 前端工程师会思考界面有哪些功能，使用那种架构、控件去实现；后端工程师则会关注数据的传递、存储、读取等。
• 测试工程师则会思考如何设计测试用例，才能覆盖所有产品功能测试。
• 对于同一种角色，不同经验的人理解也是不同的。比如资深的开发会先想整体的技术架构，考虑兼容性、耦合性、拓展性等；而新手开发则可能会想功能怎么用代码实现。

第3点即是结合逻辑推理，最终形成对当下产品需求的认知和结论。

形成完善的认知，得出完整的结论是需要思考时间的，到了评审会议上再临阵磨枪，往往难以达到预期的效果。

而让与会人员提前阅读PRD，哪怕只是囫囵吞枣的读一遍，那么思考的种子已经在潜意识中种下（人的绝大部分思考都是通过潜意识完成的，感兴趣自行检索相关资料），到了评审的时候会理解会更快、也会有更多更完善的思路。

2. 如何让与会者提前看PRD

少部分工作认真的同事会看你写的PRD。大部分同事都有自己的事情要忙，有的是本来想看，后来忘了；有的压根没有提前阅读的习惯。

根据“谁得利，谁负责”的原则，需要你主动的去达成该目标。

比如挑选在大家都不太忙的时候发送会议邀请。发送会邀后一段时间和评审会议前1小时，再次提醒与会者看PRD。对于关键人物（产品负责人、技术骨干等）则要提前约时间线下沟通，其他人则可以在平时交往时，有意无意的问问对新需求的看法等。

当然还有最重要的前提，把PRD写好了。本来阅读大段文字就很难，阅读一大段没有逻辑的文字，真是吃shi一般。

五、为什么要避免在评审会议上争论

首先我们可以换位思考一下，在私下两个人争论的时候，是否愿意承认自己想法的错误？那么这个场景又放到一个全是熟悉的同事的会议上呢？

如果你都能够坦然承认错误，那么我对你表示恭喜。但是很多人在私下争论都是难以服软的，就不要说在公开的会议上了。

因此一旦在公开场合提出不同意见，就如覆水难收。他的意见对了，你会很尴尬；他的意见错了，他会很尴尬。因此针对事情的讨论往往会演变成捍卫个人脸面的争论。

再者说，很多观点是很难说清楚对错的，可能大家都是出于对产品的善意，提出了自己的见解，只不过相互不能理解罢了。同时，这种脸面之争很容易跑题，甚至互相进行人身攻击。

即便有一方真的吵赢了，且不论输的一方颜面尽失、形象受损，而且得出的结论真不一定是有益的，可能只是胜者更善于争论。往往双方都是输家。

因此一定要把更多功夫花在会前沟通上，避免评审会议陷入无休止的争吵。再次强调，评审会议最重要目的是为了确认。

六、为什么跟设计师强调时间

1. 设计工作的特性

设计本身是一个很主观的事务，没有明确的判断标准。因此设计师的工作不像开发，有个明确的设计文档作为目标。设计工作往往是边做边想，可能经历无数的推翻重建的。

“文无第一”，任何一个设计需求理论上都可以拉的非常长，能够不断发现新的思路和可以调整的地方。因此如果没有明确的时间截点，将会是一场项目灾难，可能设计师搜集材料、寻找灵感的时间就超过了你心中的成稿截止日期。

2. 设计师的特征

设计师尤其是UI设计师，往往身上带有艺术家的色彩。他们有自己的艺术追求和对专业的骄傲，思维发散，渴望自我思想的表达。

一个优秀的设计师需要这样的特质，否则按部就班的设（chao）计（xi）很难做出引爆市场的产品设计。

3. 一些小建议

除了强调截止时间以外，你也帮助设计师更好的完成设计。

• 交代清楚项目背景、使用场景、用户需求和商业需求等关键信息。
• 必要总是提一些“高大上”、“五彩斑斓的黑”等很虚的词，可以找一些不错的竞品设计供设计师参考。切忌只找一个竞品并告诉设计师“按这个抄一个出来”。
• 与设计师一起克服抄袭的误区。齐白石先生说“学我者生，似我者死”。我们要认识到，市面上主流的设计规范和趋势的背后是无数的优秀设计师的群体智慧，你是不可能强过他们的。如果能做到聪明的“抄”，抄的明白，理解为什么要这么设计，并且能够适应自己的产品，就是成功的设计。

七、为什么推荐使用UX稿评审

首先要搞清楚人的认知习惯。在人类几十万年的进化道路上，我们80%以上的信息都是通过视觉获得，且产生文字是最近几千年的事情。人类的整个认知系统其实对于文字的提取和理解效率其实远不如图片高。

其次，文字是对世界的描述，但是其表现力是有限的。我们在写PRD的时候就会感觉到，如果想把一个功能用文字描述出来就会很困难，且要使用大量的逻辑描述。如果通过原型图、流程图等可视化的手段，就会简单很多。

最后，文字的信息噪声往往是高于图片的。主要原因是对于相同的词汇，不同人的认知可能是不同的。比如很经典的一个关于程序员的笑话，“下班顺路买十个包子，如果看到卖西瓜的，买一个。”

其实在评审中，避免信息传达失真最好的方式是高保真原型，每个功能的细节都能动态展现的清清楚楚。但是其制作成本过高，且随着行业发展，交互规范、专业术语等能够极大改善信息失真的状况。

因此带标注的设计稿是我认为目前性价比最高的形式。

八、为什么写会议纪要

写会议纪是为了对大家在达成的共识进行书面确认，以作为后续执行的依据。这并非是对团队的不信任，目的也是为了信息的一致性。

口头传达是信息失真非常严重的手段，因此才会需要有PRD、UI、UX等各种产品设计文档，否则直接口头传达不是更方便。同样的，评审会议也需要清晰的将会议要点记录下来，保证大家的理解是一致的。

后续一旦发生问题，会议纪要是非常好的证据，可以对企图歪曲事实的同时进行实锤。

这样的同事有时候也并非故意，而是人的记忆会随着时间的推移而越来越模糊。同时人有强大的心理补偿机制，面对发生问题，往往会按照对自己有利的方面回忆甚至加工记忆。

更多的，会议纪要还有如下的作用：

• 提供仪式感：仪式感对人类的心理、情绪的作用非常大，可以参考宗教仪式。发送一封评审会议纪要作为迭代的开始，很有必要。
• 明确责任人和时间截点：公开的邮件对于责任人是一种无形的、有效的社会压力，有利于后续项目管理。
• 帮助记录：帮助自己和责任人记忆会后需要跟踪的事宜，防止遗忘。
• 广而告之：告诉老板、业务方等未参会的人员，评审是否顺利，产品迭代是否开始等信息。

关于如何做好需求评审的经验就这里。祝愿每一位产品汪都能够写好PRD、做好需求评审，不要给程序猿们挖坑。这样团队更容易保持团结的氛围，团队成员之间也能保持良好的私人关系。

产品经理提前做一点、多做一点、做细一点，收益的不仅是团队，更大的受益者其实是自己。

本文是投票期间笔者发布的第7篇文章，今天也是最后的投票。

亲，请不要吝惜手中的票票，给笔者继续做产品经验分享的动力！

为我投票

我在参加人人都是产品经理2022年度作者评选，希望喜欢我的文章的朋友都能来支持我一下~

点击下方链接进入我的个人参选页面，点击红心即可为我投票。

每人每天最多可投35票，投票即可获得抽奖机会，抽取书籍、人人都是产品经理纪念周边和起点课堂会员等好礼哦！

专栏作家

一直产品汪，微信公众号：apmdogy，人人都是产品经理专栏作家。逻辑型产品经理，致力于将科学思维与产品经理方法论结合。关注人工智能、教育领域，擅长产品孵化、需求挖掘、项目管理、流程管理等产品技能。

本文原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。