如何进行真正有效果的review (评审)? 能不开的会是坚决不能开的
共 1308字,需浏览 3分钟
·
2022-06-17 20:38
入职不久的一位研发同学希望能组织一个会议讨论评审他做的设计,我告诉他,你先看一下我写的一篇公司内部博客。今天把我写的这篇内部博客公开出来,希望能给业内的研发同学特别是研发负责人一点启发。
我们在实际工作中,经常要做各种review (评审), 包括设计、代码、文档等等。大家习惯性的做法,是召集相关的人开会,内容的负责人会走读一次,介绍一下,为什么这么做,这么写,然后汇集大家的意见做些调整。通过多年的实践,我认为这套方法是走过场的,是形式主义的review,难以达到review的目的。表现在几个方面:
review的人没有做充足准备,思路只能跟着主讲人的思路跑,发现的问题往往是违反规范,或其他显而易见的问题;
review的人提的问题是现场提的,不是经过思考提出来的,因此有可能是不完整的,甚至不合逻辑或错误的;
参与开会的人,很多是心不在焉的,整个会议是一句话都不说的,完全没有产出。
那么怎么做有效果的review呢?我们需要做到以下几点:
内容负责人提前准备好内容:对照<Amazon 的秘密管理武器 - 「6页备忘录」> 检查一下内容是否满足要求。对于特别具体的文档,比如背景、解决的问题或需求大家都十分清晰的,准备的内容可以直奔主题(但建议用参考文档的方式放在内容最后,以免有不熟悉了解的人)
在Confluence的文档里直接@,或飞书通知相关的人进行review,并给出需要收到review回复的时间。
所有需要review的人,在指定的时间之前,仔细阅读内容,将自己的反馈直接写在 confluence或飞书文档上。
内容负责人收到review反馈后,看反馈的意见是否可以接受或持不同意见。对于可以接受的,直接接受,更新内容。对于不接受的,或有疑惑的,可以在confluence或飞书里互动,但互动回合不宜超过3次,过多的话,最好语音沟通,或进行会议。
内容负责人如果觉得大家的反馈都被吸收、或疑惑都已经解决、澄清,那么无需组织任何会议,review就完成了。
如果有书面交流争执不下或模糊不清的,再决定召开会议。召集会议,参会的人,是必须已经提供过书面反馈意见的。没有提过意见的,不应该邀请参会。
原则上,任何交流沟通都应该遵循《如何高效的沟通交流》里定的原则,而且要以书面文字为主,万不得已,不采用会议方式。
这么review的好处是:
每个人是真正的review了,而且反馈、互动在系统里都有记录;
任何时候,任何人都可以参与进讨论,而且不会讨论重复的问题;
尽可能不组织会议,这样便于远程办公,便于不同时区的人协同工作;
避免滥竽充数,只听不出的人参加会议。
那么有人总认为,只有会议、语音才能给大家解释清楚自己做的工作、文档、设计或代码,这是错误的认识。任何一项工作、文档、设计等等就必须用文字或代码清晰的、逻辑的表达,只要有模糊不清的地方,一定是自己没有想清楚。你可以明确告知大家,某一块没有想清楚,还模糊,求助大家,或等自己想明白,再清晰的用文字表达,之后请大家review。
陶建辉
2021年10月18日于北京
点击阅读原文,体验拥抱开源的TDengine!