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