如何高效地做设计评审

最新推荐文章于 2021-06-08 19:41:27 发布

cdai

最新推荐文章于 2021-06-08 19:41:27 发布

阅读量1.5k

点赞数 2

分类专栏：软件工程文章标签：软件设计设计评审

本文链接：https://blog.csdn.net/dc_726/article/details/96301357

版权

设计评审是降低开发风险的重要环节，但往往效率低下。本文介绍了亚马逊VP的经验，包括设置阅读时间、提问时间与回答时间，强调设计者不应在提问阶段回答问题，以及明确设计目标、问题空间和评审目的。通过这些方法，可以提高设计评审的效率并确保有价值的反馈。

摘要由CSDN通过智能技术生成

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

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

1.典型的设计评审

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