如何开一场高效的需求评审会

1. 谁参加

沟通最核心的在于效率，不要同样的内容，分不同的人讲解几次。一次会议把相关干系人都叫到位！

• 产品，会议本身的组织者
• 前端&后端，主力开发人员，靠他们实现你的想法
• 测试，任何一个项目，必须有测试
• 运营/市场，了解产品，指定后续的运营/市场策略

这里有个小技巧，只要是涉及到一个项目的立项或者准备，一定要单独拉IM群，通过群传递后续所有项目信息。避免信息掩盖和丢失！

2. 是什么

在会议的开场，避免直接进入主题，我们应该先和全体参会的人员，普及一些专业知识：

• 让参与的人知道，你要做的东西是什么
• 我在这里可能要承担什么，让所有参与人员都带着任务来参加这次会议

我见过对于业务一窍不通的技术人员可以直接按界面开干的。最后的结果就是问题百出，需求遗漏。

2.1 用户视角解说

• 谁用
• 帮助用户解决什么问题
• 用户怎么操作，操作后，在前台看到什么

2.2 专家视角解说

了解产品的大逻辑最好的方式，就是梳理产品的业务流图

业务流程图

3. 说背景

为什么改，并不是每个人都了解你的动机：

• 用户需求驱动，比如市场上目前都是直播，商家迫切想知道直播的ROI
• 用户问题的倒逼，产品已经烂到用户无法忍受了，再不改就要抛弃我们了
• 竞品倒逼，竞品有，你没有（从侧面看也是用户需求的驱动）

为什么要说背景，核心就是产生价值认同。如果你的团队不认同你的价值主张，那么在后期开发过程中会产生很多不开心的事情，比如：质疑你的需求！！！

如果研发认同你的价值主张，哪怕你的需求有错误/不足，他也会主动帮你梳理，和你一起找到正确的解决方案。作为产品经理，不要想当然的认为每一个人都认同你的想法，很多时候码农真的只是在码代码。

希望达到的项目目标是什么（OKR的思维）

• 解决用户需求
• 解决用户问题
• 打造差异化和竞品进行对抗
• 在XXX时间内实现这样的目标

4. 说需求

基于用户问题点和用户需求，转化为具体的产品需求点，以表格形式罗列清楚。

• 不同需求的优先级是什么样子的
• 和竞品对比这个需求是怎样的，竞品有还是没有，我们和他们的差异化点是什么

5. 说方案

5.1 说界面

界面本质是在深度理解需求的前提下构建的交互解决方案。大部分人都缺乏空间想象力，我们需要将我们的需求一点点的在界面内说清楚

界面的讲解，切记直接落地到具体的界面元素，我们依然需要从整体出发：

• 是什么
• 解决什么用户需求
• 这个界面最核心的要点是什么（说给技术听），需要向用户传递什么（说给设计听）
• 这个界面，我们优化了什么，和旧版的区别是什么，为什么改

5.2 说流程

这里的流程其实是任务流程，是为了完成每一个任务需要形成的用户路径和系统反馈

• 单节点的用户任务，应该最可能简洁的
• 每个判断节点，都应该有充分的反馈
• 对于一些关键节点，需要和技术人员进行细节沟通。比如消息传递的效率。是否会产生类似大批量堆积任务

5.3 说细节

做产品就是做细节，说清楚每一块的逻辑规则

• 状态
• 限制
• 操作
• 反馈
• 动画

6. 轻收尾

会议的本质目的是拿结果，一场评审会议开完，我们必须要拿到我们想要的结果项目，比如：

• 项目人员，谁来做，任务怎么细分
• 项目排期，多长时间可以联调、提测、上线
• 运营层面，如何针对当前项目进行宣传和推广
• 指标设定，如何考核本次迭代的效果预估

7. 再沟通

• 将会议中形成的结果，利用协作工具（如语雀、石墨）等，将相关结果同步给全体项目人员
• 及时更新产品文档，增加修订记录