编辑导语：作为产品经理，最常接触的就是需求评审。那么，如何写需求评审大纲就显得尤为重要，这对你后续的产品设计起着很大的作用。作者总结了《评审提纲》，教你如何设置框架。
用过的招数，第二次，更特别！
前天，我的同学景在WC认真做王者荣耀的竞技产品分析。这一次，典韦用来打野的时候，峡谷里正如火如荼，突然草丛里蹦出一个残血卤蛋，二话没说，就给了我一记猛轰。我很害怕，还没等我反应过来，他就挂断了电话。
哦，不知道有没有防刺甲？
正当我准备过塔泡温泉的时候，领导打来电话：你腿麻了吗？如果是，走两步，走出一虎一虎。轮到你表演了。快来需求评审会！
这不是让我挂了吗？
一方面是三个核桃两个枣的苦功，另一方面是至高无上的团队荣耀。哪个更重要？我没数过空调号吗？
穿上裤子，我冲进会议室。
确实，需求评审会对产品经理来说太重要了，几乎相当于反刺甲对典韦的重要性。
幸运的是，我们已经准备好了。
结果我打开PPT，屏幕上闪现了几个大字，很厉害，像是对炖鸡蛋的无情嘲讽：《金融平台采购融资系统需求评审提纲》。
不得不承认，有时候肌肉比大脑好用！
在我看来，这个大纲就是典韦的宗师实力，凯歌的暗影战斧，产品经理的二头肌。
我参加过很多婚礼，哦，不，我参加过很多评审会。说白了，我们也是见过大场面的人，各种产品折叠起来大致可以分为三种类型：
首先，从一开始就判断原型比缺乏社交跳动的新手产品更常见。
第二，先讲业务背景，清晰展示架构设计图和业务流程图，然后回顾中级优秀产品经理的原型设计。
第三，有准备的PPT复习计划。首先从全局角度解释本次评审会议的流程和关键节点，用结构化思维解释关键主题，展示需求设计过程，然后穿插对产品成果进行逐项评审，如背景介绍、系统架构设计、业务流程、原型设计、需求描述文档等。
是的，镜生属于第三类，低调，弱水，但谦虚如山。
高建利：轮到我表演了。
需求评审会议是产品经理的家。既然是会议，肯定有主题。核心主题是什么？说白了就是需求传递。
需求评审的本质是将需求设计传递给上下游、业务、技术、测试和运营等。
围绕这一核心主题，有必要从各支线的产品成果进行培训和讲解。如何有效地让后排的同学也听到讲台上的声音，不走神不走神，高效地理解需求，是评委会的灵魂期待。
跟随景哥的脚步，完成这七个步骤，保证丑小鸭变成美丽的丑小鸭。
#第一步，我们首先需要一个完整的思维框架。
这个框架的重点是整理出评审会议需要执行的程序，更多的是你自己的想法和草稿，围绕需要评审的内容进行组织。最好把它们组织成思维导图，越来越清晰。同时也可以为接下来要做的PPT大纲打下基础。
#第二步，选择合适的PPT模板。
PPT模板一定要闷热，哦不，一定要大气。
提醒两点。一是界面风格必须与产品属性相结合，如技术风格或工业风格；第二，最好加上公司logo，看起来很周到，很正式。
大哥，你认识镜子同学。我从不单独吃饭。如果我做了什么，我应该做我自己。
于是，景先生亲自下海，夜复一夜，精心挑选了一个冷静、大气、引人注目的万能模板。
#第三步先写需求评审大纲，整理目录。
PPT大纲目录是评审会议的主要议程。我通常通过这四个部分来分析，包括产品背景、业务流程、需求设计和讨论沟通。
整理好之后，我们就可以根据这四个主要内容开始评审会议的具体议题了。
#第四步，详细介绍产品背景。
产品背景是你设计的产品的项目背景、需求调查、可行性分析、业务状况，并说明清楚你为什么要做这个产品功能。
所以我在介绍产品背景的时候，一般分为项目背景、需求调研、业务状态。
## 1
\. 介绍项目背景时交代下项目背景整体情况，主要从宏观层面说一下，显得高大上，但不要说太多，表述下和产品设计有价值的参考点，做好伏笔。
## 2\. 介绍需求调研时
需求调研可以从调研概括入手，概括描述下需求调研的情况，包括调研的对象、调研目的及调研成果等。
然后用数据指标直观展示，用几个核心数据体现下调研情况，如，访谈用户数、平台规模、建设情况等。
最后结合产品和需求调研的融合，根据需求调研情况，结合产品功能的定位，描述下融合后的优势和挑战点。
## 3\. 介绍业务现状时
将产品要服务的业务场景现状表述清楚，详细罗列下关键的业务情况，提取关键指标值，结合产品规划，有所侧重，将现状陈述清晰。
这里有一个小技巧，在讲述功能前，PPT用一页，简单的文字描述下，再加一个解释文字，不用花里胡哨，却给阅读人以想象的空间。
这就像是水墨画留白的妙处。
# 第五步，原有与现在的业务流程
接下来就是核心的业务流程，要讲清楚产品功能的主要业务逻辑，使用VISIO提前画好泳道流程图，把业务关系、业务规则及主要流程讲清楚。
只有先搞清楚了业务流程，让其他评审人员初步了解到大致的业务流程，有了感性的认识，接下来的原型评审才能更顺畅。
业务流程可以先从原有的流程入手，然后结合调整和融合的地方，因为很多产品是迭代，即便是新产品也是在产品体系下的发展，离不开原有流程的影响。
最后再展示下现有的业务流程，在介绍流程时，可以根据原有业务流程和现有流程调整的地方入手，分析下优势和劣势，最后再总结下融合后带来的商业机遇，以及产品规划可能遇到的挑战，包括产品设计的工作与思考。
# 第六步，核心的需求设计环节
接下来就进入了需求设计的重要环节，需求设计的重点是要讲清楚产品功能，需要通过功能架构设计图、原型设计和需求文档进行准确表达。
## 1\. 功能架构设计
讲一下该功能的产品架构设计，若与产品体系或者其他产品线有交织的，一块在产品架构设计图上有体现。
首先可以通过逻辑功能图展示下全部功能，也可以罗列下核心的产品功能，也就是本次设计的核心模块，让参加评审的同学，尤其是开发同学有直观的认识，方便进行数据库或者其他开发设计工作。
其次，要进行功能架构设计图演示，演示时可以嵌入到PPT提纲里，也可以单独进行展示，重要的是，要清晰地表达功能设计的意义。
这里多说一句，在实际产品设计过程中，若你负责的功能与其他产品设计有关系的，提前评审一下，沟通到位，确保方向没有偏差。
## 2\. 原型设计
接下来就进入到了原型设计的演示，我们便可以离开PPT，去展示我们的原型设计。
所以你看，按照我们的提纲推进的话，可以将我们产品设计的完整历程，关键节点，逐一去展示，不仅仅是为了提高我们的专业表现力。
更重要的是，通过对业务背景的熟悉，逻辑功能的了解，再去看原型设计，理解起来会更加容易。
而我们评审的本质就是高效完成需求的传递，如果没有一个清晰的思路，再加上直观的表达，评审节奏就很容易乱，常见的表现就是顾头不顾尾，或者在某个小事上纠缠不清，如果有提纲做指引，就会事半功倍。
## 3\. 需求说明书
原型演示完毕后，我们还需要评审下需求说明书，需求文档的重要性大家都很清楚，既是对我们产品本身的总结和提炼，促进需求完成向下有效传递的工具，也是我们追溯的重要凭证。
所以我们一定要写规范，详细需求内容一般会分为五大核心，包括功能描述、业务流程、界面描述、页面元素、业务规则。
原型评审完毕后，我们就需要将需求文档评审，以便后续开发进行参考设计。
这里多说一句，需求文档和原型设计应该先写哪一个呢？欢迎关注镜同学的后续文章，我将结合实际经验以及调研汇总情况，予以解答哦。
# 第七步，组织下问题的沟通讨论
原型设计和需求文档评审结束后，评审会的进度条就90%了，不过，我还是建议你不要直接宣布散会，再组织下沟通讨论。
这一部分重点是收尾，那么在收尾之前，可以回顾下产品设计的历程，重点是表达下自己的专业性，你不得不承认，有时候权威往往决定需求开发的速度和遇到问题时沟通的效率。
其次，要确定需求沟通的方法、形式，强调需求沟通的重要性，凝聚共识，统一思想，更容易提升团队的作战效能。
这里建议我们提前表达下产品设计可能存在的不足，考虑不到的地方，一来是谦虚的态度，二来这也将会是以后需求变更及后续沟通的润滑剂。
同时，要打破信息不对称的情况，建立信息对等的匹配机制，将产品设计的成果，比如调研方案、系统架构、业务流程、原型设计、需求文档都共享，并且建立沟通交流机制，确定沟通形式，随时接受反馈意见。
最后，再讨论下问题清单，这个清单是需要在设计过程中记录的，是需要和相应岗位的同学交流讨论的。
有可能需要同开发同学确认某些问题，也可能需要同业务人员或者运营同学交流沟通，最后一定要讲问题清单沟通到位，当然，也可以让参与评审的同学提问，自己再进行逐一解答。
在我看来，产品需求评审提纲，更重要的是建立一种结构化的思维习惯，这也是我想表达的地方，产品经理不仅是需求的设计师，更是需求的火炬手。
我们要尽可能认真、专业、系统化，结构化去表达和传递需求，才能做好需求的全流程设计与管理，实际上，这份提纲就是将专业化设计，用结构化思维，进行系统化表达，从而实现几何化的效果。
## #专栏作家#
产品大峡谷，公众号：产品大峡谷，人人都是产品经理专栏作家。七年B端产品经理，供应链物流与金融领域，擅长需求设计、业务指导、商业观察等。
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议
