第195期：用时约2分882字

【需求评审】产品新人如何开需求评审会？

为什么要需求评审？

让与会者清晰的了解需求是什么，需求从哪里来，对现有业务有什么影响，预期收益是什么；让技术及测试对产品方案有详细的了解，以便后续开发更高效，没有谁愿意在后续的编写测试用例及开发阶段再去反复沟通确认，毕竟那是非常低效的做法，当然，特殊情况除外；

让与会者清晰的知道自己在整个方案落地过程中处于什么位置，职责是什么，需要做什么，准备什么，提供什么帮助，对各自负责部分的实现难度及排期有一定的心理预期；

评估产品方案的技术难度及实现周期，一期实现，还是分期实现，投入产出比怎么样？毕竟互联网产品讲究小步快跑，快速验证迭代，怎么样权衡产品设计（用户体验），技术成本以及商业利益是产品经理主要工作之一。

和谁进行需求评审？

一面视需求大小来看，如果仅仅是一个迭代需求，三五人随便找个地儿快速就搞定了；如果是一个中大型需求，然而除了技术、架构、测试以外，往往UE/UI经常被产品经理忽略，尽管UE/UI内部可能有自己的评审，但技术评估环节往往会涉及到一些交互和设计的实现需要沟通确认。

一面视公司项目流程来看，大公司和小公司项目流程有时差异比较大，大公司分工细，并行项目多，尽管涉及的干系人较多，但是可能仅仅来那么几个主要干系人；而小公司因为项目比较聚焦，讲究执行力，反而比较容易召 集所有干系人参加。

什么时间进行需求评审？

就算一次评审通过，会后也有些细节需要完善补充，沟通确认；

中间间隔太久，很可能等到开发的时候，很多技术实现细节会遗忘，因为并行项目较多，这是难免的事儿；

运气不好的话，有可能遇到开发及测试人员调整；

很可能需要进行二次甚至三次评审对需求评审有了初步了解之后，把需求评审拆分为评审前、评审中、评审后三个阶段，这三个阶段产品经理究竟要做些什么。

评审前

1.保证物料齐全

2.提前小范围沟通

3.提前把方案发出来

4.其他事项

评审中

1. 明确会议背景及目的

2. 切勿立马进入方案细节

3. 掌控节奏，切勿争（si）论（B）

4. 需要别人给予什么帮助或者反馈

评审后

整理遗留问题，找相关同学沟通解决

完善方案，更新产品文档，上传至jira/wiki

发送会议纪要，同步以上信息

后续工作计划，明确责任人及反馈排期

Powered by Froala Editor