序
做开发应该对需求评审，技术评审并不陌生。
但常有小伙伴抱怨，需求评审会参加了不少，会上定下来的东西却不多，需求朝令夕改也是常态。久而久之，需求评审就变成了立项动员会，走个过场，没起到实际作用，开发小伙伴当然不想参加啦。
那有人说了，技术评审应该不会这样了吧，毕竟是开发内部自己讨论。但从我的实践经验来看，也不一定，大家规划的好好的摩天大楼，盖着盖着就变成了草房的事情也发生过。
现实就是这样魔幻。本文，我将站在开发的角度，结合真实经验，给大家说说，怎样开好需求评审会，技术评审会。
需求评审
需求评审，是产品，开发和测试的双向沟通（诶诶？怎么会把测试拉进来？没错，我司需求评审就是要求测试参与，原因后面会讲到）。
产品就好像老师在台上讲，但开发，测试作为学生不能（断句）不懂装懂，有问题一定要大胆提出来！我们强调双向沟通！以免发生需求评审会上，开发拍着胸脯说，没问题没问题，开发到一半才发现实现不了，灰溜溜地跑去给产品说，然后双方大打出手的事情。
那么需求评审需要做哪些事情呢？
- 原型图
- 理解需求
- 定结论
- 通知相关人员
原型图
作为开发，测试，我们对需求没什么话语权。但是！在需求评审会上，我们要求产品必须给出原型图！就算没蓝湖画的，在笔记本上画，那也得有照片！
俗语说：说者无意，听者有心。人说出来的，和自己心里想的，不一定匹配！同一句话，不同人也会理解出不同意思！
而落在画面上的原型图可以消除这种差异。点这里出这个弹框，如果这样还能理解出花样来，那你的脑洞优秀的。
需求评审会决定之后的开发方向，如果方向都错了，然后就没有然后了。
建议
使用线上原型图工具，这样大家通过一个地址都能看到。
如果中途修改了需求，尽快更新到原型图上，并通知大家。
定结论
如果一个会议开完都没有结论，那就等于没开。所以我们至少得确定以下几点：
- 开发，测试理解了需求解决的业务问题。
- 需求优先级
- 参与人员，时间节点
- 通知相关部门
开发，测试理解了需求解决的业务问题
首先，需要开发纠正一个观念，那就是——产品要求的我做就是了，其他的我一概不管。我说了，产品需求会是一个双向沟通的过程。在过需求时，开发在理解需求后，最好根据自己的经验，对原型做出评价。
什么意思呢，举个栗子，产品新增了一个用户退款的需求，用户不用联系客服，自助退款。这时，我会把自己代入用户的角色，来看看用原型图的方式退款，一，是否能完成操作流程，二，是否方便，三，同类产品退款功能是怎么做的。同时，我也会把自己代入管理员的角色，后台，退款要不要自动操作？如果需要人工介入，管理员怎么操作？退款人数过多，是否需要批量操作？如何审计？可能会出现哪些风险？
比如，别人退款都是按一个套路做的，产品搞个特立独行的设计，我脑袋里模拟了一下，哪有这样搞的啊，那我就得提出来呀——你这是什么鱼唇的需求？！我第一个不同意这门亲事！
再比如，我发现操作到某一步骤，我想反悔，而原型图上没有相关功能，那我就得提问。
重要的不是喷，你得提出你的观点！你得提出产品没有看到，没有想到的地方。帮助产品去补完原型。产品改不改需求是ta的事，但你必须参与其中。互联网公司大家都是阅历相近的人，大多都是讲道理的，产品觉得你说的有道理，ta自然会去改。
这样，就避免了一部分做到中途改需求的事发生（当然，可不能百分百不改需求，但我这样做之后，自感需求变动较之前少了很多）。当然，产品不改，那我们就拿小本本记着，毕竟开发没有决定权。
如果需求有不理解的地方，或者有歧义的地方，无论开发，测试都应该当场提问。坚持需求不明确就不动工！
测试为什么要理解需求？你测试都不知道这个需求在搞什么事情，你测啥？
建议
需求不合理处，提出同行一般解决方案。
若你提出的方案被产品否决，记录下来，等待正式服用户验证（也许这种做法也不是错的，只是不常见，万一用户接受呢？万一用户喜欢呢？现实是很魔幻的）。
需求不明确不动工。
需求优先级
如果只有一个需求，break。
如果有多个需求，必须确定优先级。这个没什么好说的，永远先开发最重要的需求，就算项目延期，至少核心功能还能上。
参与人员，时间节点
这个也没什么好说的。这里着重说一下时间问题。
有时，有些需求不急，产品不会给死线，但从我的经验来看，没有时间节点=没有目标，没有目标=根本没人会主动去做。
还有时，产品不定时间节点，我们吭哧吭哧一会儿搞完了，产品又说这个需求不搞了（呵呵，你这个善变的人）。
所以，不管需求急不急，也定一个时间节点吧，产品不定时间的需求也不要慌着去搞。
如何评估开发时间？其实这是一个无解的问题，你一定对下面的场景非常熟悉：
产品：什么时候能做完？
开发：大概XXX天吧。。。（心虚）
产品：啊？这么久？不行啊！这时候做出来黄花菜都凉啦。
开发：那你什么时候要？
产品：当然是越快越好啦，再不济，也得XXX号之前吧。
开发：好。。。好吧（哭唧唧）
一般而言，开发对死线没有话语权，不过问题你总得回答吧，这里给出我的方式：
首先确认产品的死线定的是上线时间，还是提测时间，还是开发完成时间。这点非常重要！你不问他不说，最后大家都哦豁（GG的意思）！
开发天数=预估天数*风险系数。
预估天数根据经验定，风险系数根据团队研发效率定（这个系数一般是1.x，当然也可以是0.x）。
这里测试也要给到测试时间。测试知道开发死线，也可以变相监督开发按时完成（因为那天ta会找你要测试地址呀）。
建议
每个需求定下时间节点。
明确时间节点到底是上线时间，还是提测时间，还是开发完成时间。
任何需求变化通知开发Leader，而不是具体开发人员，Leader没通知到开发是Leader的失职。
通知相关部门
有些需求需要其他部门配合，在需求评审会结束后立刻通知相关部门。
某次，有个需求需要其他部门提供接口，这事在很久之前碰过一次。我们这边开发的时候没有通知对方，结果我们都开发完了，正准备找他们联调的时候，才发现他们根本没开始做。。。因为我不知道呀，你没告诉我呀！
建议
确定合作方接口人，大小事宜只找接口人。
对方最好能提供他们的死线。
需求评审会的结论，必须落到协同办公工具上，然后发送给每一位与会者。
对于极善变的产品，保留第一版代码，设计，因为大概率ta都会改回去（这不是段子，这不是段子，这不是段子）。
技术评审
技术评审会比需求评审稍微好一些，毕竟都是圈内人。但会议的目的是定结论：
- 选型——语言？必须
- 架构——单体？负载集群？分布式？必须
- 框架——组件？版本？必须
- 中间件——可选
- 风险及预防措施——并发？大流量？异常？必须！别告诉我没风险！
- 前后端对接——可选
后端需要考虑的东西很多，这里不细讲，后面会单独讨论。
后端
技术评审，我个人倾向敲得越细越好。
我也是从小项目干过来的。那时候项目小，需求一下来，根本不用技术评审，一梭子代码就敲上了。也会时常遇到搞到一半大修大改，甚至推翻重来的情况。但毕竟是小项目，就算艹了重来，时间也够。可后来随着项目规模越来越大，吃过几次大亏之后发现，对于中大型项目，如果搞到中途才发现路走不通，基本就没退路了！
那要细到什么程度？
对于后端，你得把所有接口，入参，出参，过程查询哪些表，更新哪些表，经过哪些中间件，在业务流程中，各个接口如何配合，全部在脑戴里过一遍！
什么？这太变态了？不，从我的经验来看，即使做到这种程度，在开发过程中还是有的改！你一定听过8分时间设计，2分时间编码的理论。我最早也对此嗤之以鼻，但现在却奉为圣经。从效果上看，这样做，虽然不能保证完全不改，但至少可以保证不会推翻重来！
前端
对于和前端对接的项目，最好在评审时拉上前端，先简要描述一下接口的出入参，让前端评估是否需要修改参数，字段。别自己先做出来了，粗暴的丢给前端，前端一接，这也是问题，那也是问题。
至于出现矛盾，前后端谁改的问题，我认为要秉承公平原则：
- 分页的事儿总该你后端做吧，那就别让前端假分页。
- 数据格式转换的事儿，最好也让后端来做。
- 数据展示，要拼接一些字段，这个事儿前端就别让后端冗余字段了吧，自己拼吧。
- 前端需要一些额外参数辅助，后端就帮忙加一下。
- 后端对参数格式有要求，前端传的时候就帮忙转一下。
- 等等
谁也别让谁养成了坏毛病，该谁干就谁干，久而久之，默契了，就不会出这么多幺蛾子了。一般来说，即使前后端一起评审，开发过程也难免需要前或后端改动，但我们尽量在前期规避掉大部分。
建议
事先约定错误码，包括HTTP码，和业务逻辑码。
后端给出在线接口文档，不要自己写，用工具生成。
如果团队氛围活跃，要避免争论不休，当有多个方案，或没有优质方案时，使用最保守的那一个（我是保守派）。
如果团队氛围沉闷，要一锤定音，Leader要定下方案，即使错的，也要执行，团队必须要有执行方向。
技术评审会的结论，必须落到协同办公工具上，然后发送给每一位与会者。
最后
虽然开发专注于技术，但你会发现文中很多重点却不在技术，而是在做人做事方面。你会换位思考，站在他人的角度看问题，你尊重他人，才会去想这个事应该我来做，你会揣测他人的意图，ta表达的到底是不是这个意思，等等。
我一向认为，开发，技术是硬实力，它关乎做不做得出来的问题，沟通协作是软实力，它关乎做不做得好的问题。
我自己虽然技术不怎么样，但做事的时候，会去主动思考这些问题，会尽量让大家配合得更丝滑一些，大家和和气气，顺顺利利地朝同一目标整活，这难道不香吗。
本文到此结束，谢谢大家。欢迎提出意见，也欢迎参与讨论。
