如何高效地做设计评审

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

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

1.典型的设计评审

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

2.如何提高效率

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

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

3.个人的一点经验

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

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