原创

如何高效地做设计评审

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://daichen.blog.csdn.net/article/details/96301357

设计评审(Design Review),即在真正开始开发之前,组织一次或多次会议,先评审设计,以降低日后返工甚至项目失败的风险。相信工作过一段时间,开始主导一个功能模块甚至整个系统的同学,都对设计评审不会陌生。今天偶然看到了一篇亚马逊VP及Distinguished工程师Brad Porter的一篇博客,讲述了设计评审容易陷入的问题以及他主张的一些最佳实践。也许并不适用于所有公司和项目组,但不妨一听,借鉴其中对自己有用的部分。

先放上英文原文供感兴趣的同学阅读,标题就是:《Why Design Reviews so Painful & How Fix》,为什么Design Review如此痛苦,如何改善它。


1.典型的设计评审

典型的设计评审是什么样呢?召集一群项目相关人员,主要是经理和工程师们。工程师又主要由比较有经验的架构师、高级工程师等组成,当然也会有其他工程师旁听。会议开始后,一般有经验的工程师会更主动表达自己的想法。这点是可以预料到的,因为他们的宝贵经验会给予他们多个视角来看到你要解决的问题。但问题是,每个人可能都会有好几种想法,假设#想法=3,如果5个人发言的话,去掉相近的,可能就产生了10-15种视角。于是设计评审会议就开始失控。最终的结果就是:评审人觉得自己很聪明,表达了很好的观点,而你最后发现没有几条具体的建议可以采纳。于是,一次低效的设计评审就结束了。


2.如何提高效率

作者在文章里提出了一套设计评审的流程供大家参考:

  1. 阅读时间:即便提前在会议邀请邮件中附上了设计文档,可能也很少有人会仔细看。所以,会议一开始就是大家一起安静看文档的时间。出于这个原因,至少第一次在会议,大家都不熟悉背景的情况下,设计文档不能过长。作者主张最多6页,包括附录。
  2. 提问时间:接下来就是提问时间,把大家的问题记到墙上的白板。这一步是关键,作者的秘诀就是:不要回答!不要回答!不要回答!
  3. 回答时间:收集完问题后,可以让大家休息五分钟,同时设计者你开始思考设计文档中哪一部分可以解答这些问题。等休息结束后,就对这些问题一一解答。这样每个人都有机会表达自己的观点,即便之后的讨论再次失控,最坏情况下你得到了一份有价值的问题列表。

3.个人的一点经验

前面的内容基本是对原文最精华部分的总结。这里再加上一点个人的建议,结合在一起基本上可以很好地应付多数评审:

  • 明确要解决的问题:在开始介绍你的技术方案前,我们技术人员最容易忽视的一点就是要解决什么问题(Problem Statement),是不是对我们或者客户有价值。这个价值取向的动机才是你设计的立足之本。
  • 明确问题空间:就像刷题时要考虑输入数据的Domain一样,项目设计的问题空间(Problem Space)或者范围(Scope)也很重要。因为本质上不管是小算法题还是大项目设计,都是要解决一个问题。在设计文档中一上来就应该写清楚哪些问题你已经考虑过了,但是因为什么原因不准备在这一期项目中实现。明确了之后,听众们后续也就不会再提无关的问题(Out of Scope)。
  • 明确设计评审的要达到目的:设计评审不是让大家读一遍你的文档,而是对于一些关键的设计决策(Design Option & Decision),收集大家的建议,这才是评审最有价值的部分。对于每个点,你自己都应该列出你能想到的方案及trade-off,而不是抛出来让其他人帮你在会议当场去想方案。
  • 像节目主持人一样把控节奏:即便精心准备,做好前面说到的每一点,也肯定有意想不到的情况发生。关于节奏的把控,要像电视节目主持人一样,控制好每个问题讨论的时间,确实没有想过的问题就先记下来,最后发会议纪要和下一轮会议时再解答。关于这一点,只有不断练习才能提高,可能第一次主导评审时多数人都会被问的焦头烂额,时间长了就会游刃有余,没有什么秘诀。
文章最后发布于: 2019-07-17 13:46:46
展开阅读全文
0 个人打赏

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览