让工程评审会更高效你需要这么做

　　作为智力输出岗位的产研团队，不能总想着适应环境，而是应该想着如何改善环境。如果你也觉得自家的工程评审会有点又臭又长，看完这篇文章后，你或许会找到解决办法。
　　那是一个再普通不过的工作日，在昏暗的会议室里，投影放着我们再熟悉不过的PRD。有些刺眼，不过十几个小伙伴还是认真地听着两位前后端的主程（主要负责开发的程序员）为了一个细节具体实现争论不休，一场由PM发起的工程评审会就这样自然而然地江山易主了。
　　原计划一小时的会，就这样
　　显然，这种沟通效率是不能够接受的。
　　那么怎样的工程评审会是比较理想的呢？
　　还是得先回到我们开始的地方，问问自己：
　　一、为什么要开工程评审会
　　我认为只有两个目的：
　　1。尽快启动工程开发
　　从契约精神的角度上来讲，会议具有天然的仪式感，是与会人员签订的一份虚拟协议，会议结束后双方就应该履行各自的义务。为此，越早的启动会议，越会提前上线日期。
　　2。提高工程开发效率
　　互联网公司最大的成本就是沟通成本，这在单人净值都非常高的产研团队尤为突出。如果不能充分发挥其杠杆效应，无疑将对公司的现金流造成沉重的负担。
　　会议是解决沟通效率的一种有效手段，为此避免开发过程中的额外沟通成本，也是工程评审会的主要目标之一。
　　二、如何开工程评审会
　　建议如下：
　　1。会前
　　会议邀请主程必须参加
　　尽量提前一天周知会议相关方案文档，推荐发送会议邀请的时候附上文档地址。
　　2。会中
　　讲清楚当前工程对公司业务的量化价值和战略意义（充分调动RD的主动性）
　　讲清楚PRD每一处细节，同时要不断地提醒，丑化说在前头，有问题不清楚的随时说，会议结束后就不再做任何修改了（除了有争议的部分）。
　　仔细收集RD反馈的工程问题（注意：不是业务问题）
　　3。会后
　　跟与会人员再次确认是否还有补充，提示会后就要先开发达成一致的部分。
　　有分歧的部分会单独和主程及相关人员小范围的开会确认，会尽快确认并周知。
　　我认为任何这个议程之外的事情都是在浪费时间，是一种低效的表现。
　　三、你可能不太认同的几个点
　　有的人会说，不对啊！工程能否实现也很重要，应该放到会议上讨论啊。没人说不重要，我说的是不应该在这个会议上讨论。
　　工程能否实现的问题，在PRD设计阶段就应该和主程沟通清楚了（出门左转见《写给程序猿的一封情书PRD》）。
　　也有的人会说，工期和排期也应该在会上讨论出个大概。这个说明要么你遇到的都是很NB的工程团队，要么就是你被工程团队坑的次数太少。
　　一般来说，工期和排期要给研发团队一些时间（我一般会给一个工作日），这个时间是不能省的，要知道给了时间承诺的工期和没给时间拍脑袋给的，在工程团队中的影响力差别还是很大的。
　　当然更会有人会说，在所有可能的方案中，当前方案是否为最优解，其实也有必要讨论一下。
　　这种讨论我是强烈反对在工程评审会上讨论的除非PM并没有在撰写方案前主动与主动沟通达成一致意见，否则就是典型的没有尊重过程的意识和素养。
　　除此之外，达成目标最重要的两个因素就是：正确的方向和强大的执行力。
　　在团队内部大家有明确的分工，产品对需求的方向和价值负责，研发对工程的质量负责；如果部门之间都互相遇阻代庖的指责对方的不正确性，谁又来保证自己模块的正确性，又谈何具有强大的执行力？
　　所以综上两点，我认为即使在工程评审会上对方案是否最优有质疑，也不应该在会上提出（那就不是那个阶段该干的事儿！），必要的情况下可私下反馈。
　　当然如果真出现这种情况，产品leader应该警惕，考虑现有的产品内审机制是否存在放水现象。理论上来讲，PM做方案的时候各种可能性都应该考虑到了。
　　四、感谢有人砸场子
　　被人砸场子（仅指针对方案内容提出的质疑，而不是针对会议流程），当面挑战你的方案！
　　这时候该怎么办？
　　你应该心怀感激的找时间请他吃饭。
　　说真的，能提出问题，哪怕是挑战类的问题，说明他认真看过你的文档思考过了。另外从某种角度来讲，问题在开发前暴露远好过上线后暴露。
　　其实最可怕的是：开会的时候什么问题都没有，会议结束后又各种问题不断涌现，反反复复的修改、同步，最终严重影响了工程的进度。
　　这里要稍微多说一句：遇到挑战的时候，能三言两语解释清楚的更好；说不清楚的，记下来承诺个时间点会后一般人也都可以理解，甚至是认同（对于提问者本身来说，问题被认真对待是一种被尊重的表现）。
　　作为智力输出岗位的产研团队，还是要有一定的进取心的，不能总想着适应环境，而是应该想着如何改善环境。
　　如果你也觉得自家的工程评审会有点又臭又长，那就赶紧做点什么吧！就像张伯伦说的那样不要因为走得太远，忘记了我们为什么出发。