项目经验 需求评审与技术评审

序

做开发应该对需求评审，技术评审并不陌生。

但常有小伙伴抱怨，需求评审会参加了不少，会上定下来的东西却不多，需求朝令夕改也是常态。久而久之，需求评审就变成了立项动员会，走个过场，没起到实际作用，开发小伙伴当然不想参加啦。

那有人说了，技术评审应该不会这样了吧，毕竟是开发内部自己讨论。但从我的实践经验来看，也不一定，大家规划的好好的摩天大楼，盖着盖着就变成了草房的事情也发生过。

现实就是这样魔幻。本文，我将站在开发的角度，结合真实经验，给大家说说，怎样开好需求评审会，技术评审会。

需求评审

需求评审，是产品，开发和测试的双向沟通（诶诶？怎么会把测试拉进来？没错，我司需求评审就是要求测试参与，原因后面会讲到）。

产品就好像老师在台上讲，但开发，测试作为学生不能（断句）不懂装懂，有问题一定要大胆提出来！我们强调***双向沟通***！以免发生需求评审会上，开发拍着胸脯说，没问题没问题，开发到一半才发现实现不了，灰溜溜地跑去给产品说，然后双方大打出手的事情。

那么需求评审需要做哪些事情呢？

• 原型图
• 理解需求
• 定结论
• 通知相关人员

原型图

作为开发，测试，我们对需求没什么话语权。但是！在需求评审会上，我们要求产品必须给出***原型图***！就算没蓝湖画的，在笔记本上画，那也得有照片！

俗语说：说者无意，听者有心。人说出来的，和自己心里想的，不一定匹配！同一句话，不同人也会理解出不同意思！

而落在画面上的原型图可以消除这种差异。点这里出这个弹框，如果这样还能理解出花样来，那你的脑洞优秀的。

需求评审会决定之后的开发方向，如果方向都错了，然后就没有然后了。

建议

使用线上原型图工具，这样大家通过一个地址都能看到。

如果中途修改了需求，尽快更新到原型图上，并***通知大家***。

定结论

如果一个会议开完都没有结论，那就等于没开。所以我们至少得确定以下几点：