使用过的招数，第二次，就更特么灵了！

前天镜同学正在WC认真做着王者荣耀的竞品分析，这次使用典韦打野，峡谷游走正酣，草丛里突然蹦出个残血卤蛋，二话不说，对我一顿猛轰。把我吓得，还没来得及反应，他特么就挂了。

呵，不知道我典君有反刺伤甲么？

正当我准备越塔去对面泡温泉时，领导打来电话：腿麻了没有，麻了的话，走两步，走出个虎虎生风，特么该你表演了，赶紧来开需求评审会！

这特么不是逼我挂机么？

一边是仨核桃俩枣又无比苦涩的工作，一边是至高无上的团队荣耀，哪个重要，我特么没有点AC数么？

提上裤子我就冲进了会议室。

的确，需求评审会对产品经理来说太重要了，差不多就相当于反刺伤甲对典韦的重要程度。

好在，咱早就准备好了。

于是乎，我打开了PPT，屏幕上闪烁的几个大字，强劲有力，像是对卤蛋的无情嘲讽：《××××金融平台采购融资系统需求评审提纲》。

不得不承认，有时候肌肉比头脑管用！

在我看来，这份提纲，就是典韦的宗师之力，就是凯哥的暗影战斧，就是产品经理的肱二头肌啊。

我参加过很多场婚礼，哦，不是，参加过很多场评审会，毫不客气的说，咱也是见过大场面的人，形形色色的产品，折叠起来看，大致可简单分为三种：

一是，上来就评审原型的，多见于缺乏社会毒打的新手产品。

二是，先讲下业务背景，展示清楚架构设计图、业务流程图，然后评审原型设计的中级优秀产品经理。

三是，准备的有个PPT评审方案，先从全局说明下本次评审会的流程和关键节点，用结构化思维阐述下关键主题，将需求设计历程统揽展示，然后再穿插着逐项评审产品成果，诸如，背景介绍、系统架构设计、业务流程、原型设计及需求说明文档等。

是的，镜同学就属于第三种，低调低调，弱水而已，不过谦山。

高渐离：该我上场表演了。

需求评审会是产品经理的主场，既然是会议，那肯定就得有主题，核心主题是什么呢？说白了就是需求传递。

需求评审的本质就是将需求设计向上下游进行传递，对业务、对技术、对测试、对运营等。

围绕这个核心主题，便需要从各个支线的产品成果去培训和讲解，如何有效的让后排的同学也听得到讲台上的声音，不会跑神或分散注意力，高效地理解需求，正是评审会的灵魂期望。

跟随镜哥的脚步，走完这七步，保证丑小鸭变漂亮的丑小鸭。

第一步，我们需要先整一个思考框架

这个框架重点是梳理评审会需要表演的节目，更多的是自己的思路和草稿，围绕着要评审的需求去整理，最好整理成思维导图，比较清晰明了，同时，也可以为接下要做的PPT提纲打下基础。

第二步，选择一个合适的PPT模板

PPT模板一定要骚气，哦不，一定要大气。

提醒两点，一是，界面风格一定要结合产品属性，比如，科技风或者工业风；二是，最好把公司logo加上去，显得走心和正规。

大哥，你是了解镜同学的，吃独食这事儿，我从来不干，我如果出手，趴桌子上（写方案）的，应该是我自己。

所以，镜同学亲自下海，一宿一宿的，精挑细选了个沉稳、大气、逼格满满的通用模板。

第三步，着手编写需求评审提纲，先梳理出目录

PPT提纲的目录就是评审会的主要议程，我一般会通过这四部分来分析，包括产品背景、业务流程、需求设计和讨论沟通。

梳理好之后，就可以按这四大块内容，展开评审会的具体议题。

第四步，详细介绍产品背景

产品背景就是针对你设计产品的项目背景、需求调研情况、可行性分析、业务现状等内容，讲清楚为什么做这个产品功能。

所以，我介绍产品背景时，一般分为项目背景、需求调研和业务现状。

1. 介绍项目背景时

交代下项目背景整体情况，主要从宏观层面说一下，显得高大上，但不要说太多，表述下和产品设计有价值的参考点，做好伏笔。

2. 介绍需求调研时

需求调研可以从调研概括入手，概括描述下需求调研的情况，包括调研的对象、调研目的及调研成果等。

然后用数据指标直观展示，用几个核心数据体现下调研情况，如，访谈用户数、平台规模、建设情况等。

最后结合产品和需求调研的融合，根据需求调研情况，结合产品功能的定位，描述下融合后的优势和挑战点。

3. 介绍业务现状时

将产品要服务的业务场景现状表述清楚，详细罗列下关键的业务情况，提取关键指标值，结合产品规划，有所侧重，将现状陈述清晰。

这里有一个小技巧，在讲述功能前，PPT用一页，简单的文字描述下，再加一个解释文字，不用花里胡哨，却给阅读人以想象的空间。

这就像是水墨画留白的妙处。

第五步，原有与现在的业务流程

接下来就是核心的业务流程，要讲清楚产品功能的主要业务逻辑，使用VISIO提前画好泳道流程图，把业务关系、业务规则及主要流程讲清楚。

只有先搞清楚了业务流程，让其他评审人员初步了解到大致的业务流程，有了感性的认识，接下来的原型评审才能更顺畅。

业务流程可以先从原有的流程入手，然后结合调整和融合的地方，因为很多产品是迭代，即便是新产品也是在产品体系下的发展，离不开原有流程的影响。

最后再展示下现有的业务流程，在介绍流程时，可以根据原有业务流程和现有流程调整的地方入手，分析下优势和劣势，最后再总结下融合后带来的商业机遇，以及产品规划可能遇到的挑战，包括产品设计的工作与思考。

第六步，核心的需求设计环节

接下来就进入了需求设计的重要环节，需求设计的重点是要讲清楚产品功能，需要通过功能架构设计图、原型设计和需求文档进行准确表达。

1. 功能架构设计

讲一下该功能的产品架构设计，若与产品体系或者其他产品线有交织的，一块在产品架构设计图上有体现。

首先可以通过逻辑功能图展示下全部功能，也可以罗列下核心的产品功能，也就是本次设计的核心模块，让参加评审的同学，尤其是开发同学有直观的认识，方便进行数据库或者其他开发设计工作。

其次，要进行功能架构设计图演示，演示时可以嵌入到PPT提纲里，也可以单独进行展示，重要的是，要清晰地表达功能设计的意义。

这里多说一句，在实际产品设计过程中，若你负责的功能与其他产品设计有关系的，提前评审一下，沟通到位，确保方向没有偏差。

2. 原型设计

接下来就进入到了原型设计的演示，我们便可以离开PPT，去展示我们的原型设计。

所以你看，按照我们的提纲推进的话，可以将我们产品设计的完整历程，关键节点，逐一去展示，不仅仅是为了提高我们的专业表现力。

更重要的是，通过对业务背景的熟悉，逻辑功能的了解，再去看原型设计，理解起来会更加容易。

而我们评审的本质就是高效完成需求的传递，如果没有一个清晰的思路，再加上直观的表达，评审节奏就很容易乱，常见的表现就是顾头不顾尾，或者在某个小事上纠缠不清，如果有提纲做指引，就会事半功倍。

3. 需求说明书

原型演示完毕后，我们还需要评审下需求说明书，需求文档的重要性大家都很清楚，既是对我们产品本身的总结和提炼，促进需求完成向下有效传递的工具，也是我们追溯的重要凭证。

所以我们一定要写规范，详细需求内容一般会分为五大核心，包括功能描述、业务流程、界面描述、页面元素、业务规则。

原型评审完毕后，我们就需要将需求文档评审，以便后续开发进行参考设计。

这里多说一句，需求文档和原型设计应该先写哪一个呢？欢迎关注镜同学的后续文章，我将结合实际经验以及调研汇总情况，予以解答哦。

第七步，组织下问题的沟通讨论

原型设计和需求文档评审结束后，评审会的进度条就90%了，不过，我还是建议你不要直接宣布散会，再组织下沟通讨论。

这一部分重点是收尾，那么在收尾之前，可以回顾下产品设计的历程，重点是表达下自己的专业性，你不得不承认，有时候权威往往决定需求开发的速度和遇到问题时沟通的效率。

其次，要确定需求沟通的方法、形式，强调需求沟通的重要性，凝聚共识，统一思想，更容易提升团队的作战效能。

这里建议我们提前表达下产品设计可能存在的不足，考虑不到的地方，一来是谦虚的态度，二来这也将会是以后需求变更及后续沟通的润滑剂。

同时，要打破信息不对称的情况，建立信息对等的匹配机制，将产品设计的成果，比如调研方案、系统架构、业务流程、原型设计、需求文档都共享，并且建立沟通交流机制，确定沟通形式，随时接受反馈意见。

最后，再讨论下问题清单，这个清单是需要在设计过程中记录的，是需要和相应岗位的同学交流讨论的。

有可能需要同开发同学确认某些问题，也可能需要同业务人员或者运营同学交流沟通，最后一定要讲问题清单沟通到位，当然，也可以让参与评审的同学提问，自己再进行逐一解答。

在我看来，产品需求评审提纲，更重要的是建立一种结构化的思维习惯，这也是我想表达的地方，产品经理不仅是需求的设计师，更是需求的火炬手。

我们要尽可能认真、专业、系统化，结构化去表达和传递需求，才能做好需求的全流程设计与管理，实际上，这份提纲就是将专业化设计，用结构化思维，进行系统化表达，从而实现几何化的效果。