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

产品老司机手把手教写文档,10天线上课程,零基础掌握产品经理必备7大文档撰写法。了解一下>

作为智力输出岗位的产研团队,不能总想着适应环境,而是应该想着如何改善环境。如果你也觉得自家的工程评审会有点“又臭又长”,看完这篇文章后,你或许会找到解决办法。

那是一个再普通不过的工作日,在昏暗的会议室里,投影放着我们再熟悉不过的PRD。有些刺眼,不过十几个小伙伴还是“认真地”听着两位前后端的主程(主要负责开发的程序员)为了一个细节具体实现争论不休,一场由PM发起的工程评审会就这样”自然而然地“江山易主了。

原计划一小时的会,就这样……

显然,这种沟通效率是不能够接受的。

那么怎样的工程评审会是比较理想的呢?

还是得先回到我们开始的地方,问问自己:

一、为什么要开工程评审会

我认为只有两个目的:

1.  尽快启动工程开发

从契约精神的角度上来讲,会议具有天然的仪式感,是与会人员签订的一份虚拟协议,会议结束后双方就应该履行各自的义务。为此,越早的启动会议,越会提前上线日期。

‍2.  提高工程开发效率

互联网公司最大的成本就是沟通成本,这在单人净值都非常高的产研团队尤为突出。如果不能充分发挥其杠杆效应,无疑将对公司的现金流造成沉重的负担。

会议是解决沟通效率的一种有效手段,为此避免开发过程中的额外沟通成本,也是工程评审会的主要目标之一。

二、如何开工程评审会

建议如下:‍

1.  会前

  • 会议邀请主程必须参加
  • 尽量提前一天周知会议相关方案文档,推荐发送会议邀请的时候附上文档地址。

2. 会中

  •  讲清楚当前工程对公司业务的量化价值和战略意义(充分调动RD的主动性)
  •  讲清楚PRD每一处细节,同时要不断地提醒,丑化说在前头,有问题不清楚的随时说,会议结束后就不再做任何修改了(除了有争议的部分)。
  •  仔细收集RD反馈的工程问题(注意:不是业务问题)

3. 会后

  • 跟与会人员再次确认是否还有补充,提示会后就要先开发达成一致的部分。
  • 有分歧的部分会单独和主程及相关人员小范围的开会确认,会尽快确认并周知。

我认为任何这个议程之外的事情都是在浪费时间,是一种低效的表现。‍‍

三、你可能不太认同的几个点

有的人会说,不对啊!工程能否实现也很重要,应该放到会议上讨论啊。‍‍没人说不重要,我说的是不应该在这个会议上讨论。‍

工程能否实现的问题,在PRD设计阶段就应该和主程沟通清楚了(出门左转见《写给程序猿的一封情书-PRD》)。

也有的人会说,工期和排期也应该在会上讨论出个大概。这个说明要么你遇到的都是很NB的工程团队,要么就是你被工程团队坑的次数太少。

一般来说,工期和排期要给研发团队一些时间(我一般会给一个工作日),这个时间是不能省的,要知道给了时间承诺的工期和没给时间拍脑袋给的,在工程团队中的影响力差别还是很大的。

当然更会有人会说,在所有可能的方案中,当前方案是否为最优解,其实也有必要讨论一下。

这种讨论我是强烈反对在工程评审会上讨论的——除非PM并没有在撰写方案前主动与主动沟通达成一致意见,否则就是典型的没有尊重过程的意识和素养。

除此之外,达成目标最重要的两个因素就是:正确的方向和强大的执行力。

在团队内部大家有明确的分工,产品对需求的方向和价值负责,研发对工程的质量负责;如果部门之间都互相遇阻代庖的指责对方的不正确性,谁又来保证自己模块的正确性,又谈何具有强大的执行力?

所以综上两点,我认为即使在工程评审会上对方案是否最优有质疑,也不应该在会上提出(那就不是那个阶段该干的事儿!),必要的情况下可私下反馈。

当然如果真出现这种情况,产品leader应该警惕,考虑现有的产品内审机制是否存在放水现象。理论上来讲,PM做方案的时候各种可能性都应该考虑到了。

四、感谢有人“砸场子”

被人“砸场子”(仅指针对方案内容提出的质疑,而不是针对会议流程),当面挑战你的方案!

这时候该怎么办?

你应该心怀感激的找时间请他吃饭。

说真的,能提出问题,哪怕是挑战类的问题,说明他认真看过你的文档思考过了。另外从某种角度来讲,问题在开发前暴露远好过上线后暴露。

其实最可怕的是:开会的时候什么问题都没有,会议结束后又各种问题不断涌现,反反复复的修改、同步,最终严重影响了工程的进度。

这里要稍微多说一句:遇到挑战的时候,能三言两语解释清楚的更好;说不清楚的,记下来承诺个时间点会后一般人也都可以理解,甚至是认同(对于提问者本身来说,问题被认真对待是一种被尊重的表现)。

作为智力输出岗位的产研团队,还是要有一定的进取心的,不能总想着适应环境,而是应该想着如何改善环境。

如果你也觉得自家的工程评审会有点”又臭又长“,那就赶紧做点什么吧!就像张伯伦说的那样——“不要因为走得太远,忘记了我们为什么出发”。

 

本文由 @吴天 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 作者:吴天,微信公众号:【竹林杂记 】,欢迎关注~

    回复