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