18 17 | 架构决策，是技术管理者最重要的能力-526互联

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

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

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

感谢你！

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

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

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

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

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

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

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

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

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

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

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

……

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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