<audio id="audio" title="17 | 架构决策，是技术管理者最重要的能力" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c7/4d/c76c90d07cc6ee8d1254140e0626944d.mp3"></audio>

你好，欢迎来到我的专栏：「乔新亮的 CTO 成长复盘」第三章 —— 也是最后一章：「对专业成长的复盘」，我是乔新亮，很高兴能见到你。

说起来真的有点感慨，自从 10 月 26 日专栏上线起，眨眼间，我们共同度过了一月有余的时光。

在这段时间里，有超过 3500 人加入课程，与你我一起成长。专栏共发布了 17 篇文章，收到了超过 500 条留言，有好多同学是篇篇都留言，一路相随。基本上，每一条留言我都回复了，收获了许多感动与启发。

感谢你！

接下来，我们将以技术和架构思维为抓手，夯实管理者的成长基础，争取做一个底子打得扎实、向上生长快的优秀技术管理人才。最终，我们的目标是，成为一名优秀的 CTO。如果你觉得有收获，不妨把文章分享给其他人。不同的声音越多、交流的价值越大，成长的速度就越快。

好，我们言归正传，聊一聊如何理解和提升架构决策能力。

## 决策失误，是“技术债”的主要来源

你可能会想，老乔是在吊人胃口吗？在「专业成长」部分，不赶紧讲架构设计，反而去讲所谓的架构决策能力。

事实上，回顾这些年的管理经验和见闻，我认为架构决策能力不但非常关键，而且是技术管理者最重要的能力之一，而且职级越高就越重要。

2012 年初，我身在 IBM，为苏宁提供顾问服务。

当时，苏宁面临一个重大的架构决策问题：是继续沿用 ESB（企业服务总线）架构，还是转向分布式架构。

在今天看来，这个问题或许不需要讨论 —— 很多企业都在拥抱分布式架构，放弃 ESB 架构。但在当时，苏宁是更倾向于继续沿用 ESB 架构的。

因为在苏宁的技术架构内，是存在 SAP 服务和一些异构系统的，不能直接弃用 ESB，选择分布式等于同时维护两套系统。

但我坚定地支持采用分布式架构，理由有很多：

1. ESB 是一个集中点，风险非常大； 如果选择  ESB  架构并且让其承载大量的业务逻辑（系统间调用的处理逻辑），后续转型困难；
1. 系统内虽然存在部分异构系统，但大部分是同构系统，分布式系统完全可以支撑；
1. 在分布式架构中，不同服务可以直接访问，无需像 ESB 架构一样经过负载均衡系统和网络交换机，避免了资源的浪费；

……

虽然理由很多，但在工作性质上，我属于乙方，是企业外部人员；而持反对意见的是甲方，属于企业内部人员。大部分情况下，乙方不会在这种问题上和甲方争执到底 —— 如果甲方已经有非常明确的倾向和意见，那就顺从甲方，不是挺好的吗？

但我知道，架构决策事关重大，所以坚持表达了意见。最终，苏宁的 IT 系统也顺利转型为分布式架构，没有走上歧路。

最让我庆幸的是，2015 年我加入了苏宁。如果当初没有坚持转型分布式架构，三年之后，就会有一个庞大、臃肿、高风险的“烂摊子”架构在等着我收拾，那该有多么痛苦？

说了这么多，并非是要突出自己聪明。恰恰相反，我相信人人都很聪明，也非常专业，但如果在一个重要的架构决策失误了，企业就可能需要花三年、五年甚至更久的时间来“还债”。

你看，其实很多所谓的“技术债”，也就是由一次次的决策失误不断累加而成的。

那么什么是架构决策能力呢？简单来说，就是当团队因架构方案的选择，出现争议、迟迟不能决定时，管理者需要具备的、一锤定音的能力和方法。

新架构多久落地，说到底只是个效率问题。但如何拍板确定新架构的设计，则是重要的方向性问题。如果方向不对，那么无论团队里有多少精兵猛将，也只能跟着漫无目的地瞎忙，这就是所谓的“一将无能，累死三军”。

## 选择“不作为”，往往更加可怕

说句公道话，很多管理者虽然会出现决策失误，但至少做了决策，使业务在一定时间内可以维持增长。最不靠谱的是，管理者选择不做决策，导致团队工作无限期阻塞，严重影响业务发展。

举个例子，有两个团队成员坐在会议室里，争论两个架构设计方案孰优孰劣。他们各执一词，谁也说服不了谁。这时，你作为技术管理者，应该怎么办？

我大概见过三种处理方式：

1. 给大家分析哪一种方案更好，现场拍板；
1. 指出当前双方考虑不周到的地方，再给大家时间去准备，并在 Deadline 前决策拍板；
1. 泛泛地对大家说：“不够具体”、“没有重点”，“再回去想想”……

第一种、第二种其实都是正确的处理方式，建立在管理者内心已经有答案、有见解的基础上，前者追求决断效率，后者看重团队培养，都很棒。

但第三种就有点值得玩味了。很多时候，这代表某种“职场生存技巧”。表面上，管理者希望团队多多思考，但实际上，他是自己没想明白。至于接下来，无非是一个字：拖。

有些方案或项目甚至因此延期半年以上，这对于一家企业来讲是非常危险的。

所以，在这一讲的开始，有一个关键认知，我一定要同步给你：

**一把手是团队的天花板，并为团队的所有问题负责。**

作为管理者，尤其是前几年，我经常用以上认知告诫自己。映射到架构决策层面，也就是一把手一定要有勇气在方案之间做取舍，并承担相应的后果。

当然，架构决策也不能乱做，千万别说：乔老师说了，要敢于做决策，然后闭着眼睛挑了一个答案……

关于架构决策，其实是有一套意见反馈和流程模板的。

## 做好架构决策的流程和模板

当管理者需要做架构决策时，就意味着至少有两个、三个甚至更多架构方案摆在面前，各有利弊，需要高层协助决策。在苏宁时，我还为此建立了一套架构决策流程，决策流程如下：

1. 当事人发起架构决策申请；
1. 由产品负责人判断：该申请是在产研中心部门内协调解决，还是上升至 CTO 办公室解决；
1. 在产研中心部门内，或联合 CTO 办公室，完成架构评审；
1. 将结果发还至当事人征询意见；
1. 由当事人判断是否仍有疑虑，需要进行架构仲裁；
1. 若需要则发起仲裁会，解决分歧；若不需要则结案归档，执行决策。

过程中可能涉及的参与人包括：产品负责人、技术负责人、架构师团队、架构负责人、CTO 办公室负责人等。如果是部门内协调解决，则 CTO 办公室不参与评审；如果评审后仍有分歧，则 CTO 办公室连同其他负责人一起介入架构仲裁，快速解决问题。

你可能会想，设计这么长的流程和表单，难道不是人为地加长决策周期吗？有点不太“敏捷”啊。

没错，只要涉及到新增制度、新增流程，无论考虑得多完善，都会降低团队敏捷度 —— 初创团队几乎总是动作最快的，万人大厂相对来说就要迟缓一些。因此，在管理小团队时，我可能不会推行以上决策流程，因为我的精力足够覆盖团队每一次重要决策；但对于大型企业来说，上述制度就开始变得非常重要。

同时，我们也要认识到，用体系化的解决方案解决组织问题，是正确的认知。但体系化的解决方案一旦在实际工作中开始落地，也非常容易“变形”。**在上述决策流程里，最困难的不是架构评审和架构仲裁，而是向下推进的动作和速度。**

越是高级管理者，日程排得越满，越难约时间开会。决策流程一旦涉及到 CTO 级管理者，推进速度就可能变得非常慢，这在很多企业都是切实存在的现象。

我的解决方法，是回到我们专栏的第二章第二节：《管理者最重要的三个任务（二）：加强组织协同效率》，坚决落地日历协同的文化和工具。当团队做好日历协同时，只要管理者某一时段的日历是空白的，就可以预定会议，对组织全体适用。若有特殊情况，单独沟通。

所以你看，任何策略、体系化的解决方法，都很难脱离企业文化而独立存在。有一句话说得好：文化吞噬策略如早餐。

管理者要优先配合下属做好架构决策，反过来，下属也要进行细致准备，节约时间、提升效率。在架构评审发起前，发起人最重要的工作之一，就是填写和提交一份意见反馈表单，表单内容大致如下图所示：

<img src="https://static001.geekbang.org/resource/image/11/05/11f313a7698c1c4566d4ace1d7659a05.png" alt="">

通常，当你看到这份表格，很可能会最先注意到「业务需求」、「可选方案」、「决策结果」和「决策理由」等关键字。毕竟，这几项直接构成了基本的决策流程，确实非常重要。

但是请注意，当整个决策流程完成时，表格中每一项都应该被填满，没有例外。我们先来看看，表单其他部分的设计目的：

- 从「待决策内容」到「决策申请编号」，这部分内容是为了更好地将决策事件归档，以备以后参考、调研、借鉴；
- 「假设条件」是为了注明可选方案的依赖条件，以免出现建设“空中楼阁”的情况；
- 「重要性」的标注是为了提升决策效率；
- 「因决策而产生的需求」和「其他相关决策」，则是确保决策可以落地。

不过具体到表单的某一项，模板中是没有字数限制的。填写意见反馈表的标准是：逻辑清晰、完整，能让他人能够准确理解。

相比决策流程，这张表单的泛用性可能更高，作用也非常关键，我认为大概有四点：

第一，这套流程和意见反馈模板，可以让当事人及各参与方，做好充分的思考和准备，避免浪费大家的时间；

第二，所有分歧会落实到纸面上，能防止沟通出现歧义，也预防推诿、扯皮的现象发生；

第三，可以培养所有人的大局观和架构决策能力，间接推动人才梯队建设；

最后，用体系化方案解决团队问题，追求的是“一劳永逸”地解决问题。

**更重要的是，无论是流程还是表格，都不仅是一样工具，更是一种思维模式**。越早养成这种思维模式，对个人成长的帮助越大。如果你能在思考、验证后，将其沉淀为文档，相信有一天，你也能起草适合自己公司和业务的架构决策模板。

写到这里，我不得不承认：即便拥有了架构决策流程和模板，要高效率地进行正确的决策，对于管理者而言，依然是个巨大的挑战。各领域、各方向的架构设计往往有其独特的一面。尤其是业务架构的设计，可能还会掺杂一些“历史原因”。如果不是代码维护者，几乎很难讲清楚业务逻辑。

这时，管理者怎么做架构决策呢？

## 技术管理者如何做好架构决策

我认为，要做好架构决策，管理者至少需要具备两项特质。

**第一项特质：要学会站在全局视角看待问题，学会看到技术架构的“外部价值”**。这种“外部价值”包括：公司利润、人效、资源利用率、业务风险，等等。

说到这里，请你暂停并回想一下：在这一讲的开头，我提到了 2012 年在苏宁完成的架构决策：在 ESB 和分布式架构之间，我选择了分布式架构。这个决策具备哪些“外部价值”呢？

这是个有关企业技术平台的架构决策，所以和收入、利润的关联度都很小。但分布式架构确实大大降低了业务风险，也在系统交互层面提高了资源利用率。这些都是非常明显的优势。

但如果只能看清“外部价值”，也不能让技术管理者做好架构决策，否则一个不懂技术的 CEO 才是最好的架构决策者。

这就要求决策者具备**第二项特质：具备相当的技术深度，以及非常好的学习能力和逻辑思维。**

时隔 8 年，今天再谈起在苏宁选择分布式架构的往事，总是有点云淡风轻。但在背后，是一箩筐的技术细节：你要知晓 ESB 和分布式架构支持同构、异构服务时，各自的优劣势；你要知晓两者通过 TCP/IP 和 IP 协议交互所带来的效率区别；你要知晓 ESB 架构中，负载均衡系统和交换机的存在，以及由此而来的资源浪费，等等。

在前面的内容里，我们一直强调做 “T” 型人才，其中一个重要的原因就在此时得到了体现：有一条足够深入的技术栈，是你前进的巨大倚仗。

那么，是不是分布式专家就只能参与分布式架构的决策呢？当然不是，CTO 几乎不可能成为真正意义上的全栈技术和架构专家 —— 在一个梯队建设较为成功的企业里，走技术路线的下属，几乎总是会在某一专业领域胜过你。

这时，管理者的学习能力和逻辑思维就会派上用场。做架构决策时，我们要求写好意见反馈模板，其中一个重要意图是让当事人将架构背后的逻辑讲明白。

而管理者要做的就是：通过下属的表述，快速理解业务和架构逻辑，短时间内成为这一细分问题的专家，然后进行决策。

“只要你能讲清楚，我就一定能掌握”，如果通过坚持不懈的练习，养成了这一专业素质，管理者将在架构决策方面无往而不利。

你可能会说，老乔啊，我们团队的成员，嘴都比较笨，真的是说不明白。没关系，管理者可以多加引导，一个很好用的小技巧是：引导对决策存在分歧的双方，就方案合理性互相“攻击”。

你可以要求当事人 A 首先阐述方案，并进行提问，比如：你凭什么说这个方案就能节省资源？在当事人 A 回答完之后，询问当事人 B ：你对他刚才的阐述难道没有疑问吗？

这样一来二去，方案背后的逻辑就会更加清晰，管理者也就更容易进行决策了。

## 结语

今天，我们聊了聊有关架构决策的认知、体系框架，以及高层管理者需要具备的基本素质。

对于初级管理者来说，要尽早培养自己的架构决策能力，尤其重视思维模式的培养、个人技术栈的深度扩展以及逻辑思维能力的锻炼。

对于高级管理者来说，则要做好认知层面的储备。很多 CTO 面对下属的架构决策求助，回复都是“我忙着呢，过两天吧”、“你自己再想想，晚点再说”。

高级管理者不能总是瞎忙，如果你真的意识到，架构决策是技术管理者最重要的任务之一，就一定会为类似的决策会议腾出时间。

拖延做决策的管理者，要么是不懂，要么是战略懒惰，很少有第三种情况。而所谓“战略懒惰”，常常表现为管理者自己冲到一线“拼杀”，却对团队的方向性问题反应迟钝。

当然，做管理的时间一长，确实也会怀念“带队冲锋”的感觉，我觉得没什么问题。但要注意，“冲锋”这个动作，一定发生在战略决策之后。而善于做决策，又敢于冲锋的管理者，在现代商业环境中，一定大有可为。

好了，关于架构决策，我们就聊这么多。

让我们下一讲再见！
