17 架构决策，是技术管理者最重要的能力
你好，欢迎来到我的专栏：「乔新亮的 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 ：你对他刚才的阐述难道没有疑问吗？
这样一来二去，方案背后的逻辑就会更加清晰，管理者也就更容易进行决策了。
结语
今天，我们聊了聊有关架构决策的认知、体系框架，以及高层管理者需要具备的基本素质。
对于初级管理者来说，要尽早培养自己的架构决策能力，尤其重视思维模式的培养、个人技术栈的深度扩展以及逻辑思维能力的锻炼。
对于高级管理者来说，则要做好认知层面的储备。很多 CTO 面对下属的架构决策求助，回复都是“我忙着呢，过两天吧”、“你自己再想想，晚点再说”。
高级管理者不能总是瞎忙，如果你真的意识到，架构决策是技术管理者最重要的任务之一，就一定会为类似的决策会议腾出时间。
拖延做决策的管理者，要么是不懂，要么是战略懒惰，很少有第三种情况。而所谓“战略懒惰”，常常表现为管理者自己冲到一线“拼杀”，却对团队的方向性问题反应迟钝。
当然，做管理的时间一长，确实也会怀念“带队冲锋”的感觉，我觉得没什么问题。但要注意，“冲锋”这个动作，一定发生在战略决策之后。而善于做决策，又敢于冲锋的管理者，在现代商业环境中，一定大有可为。
好了，关于架构决策，我们就聊这么多。
让我们下一讲再见！
- 蹦哒 👍（11） 💬（1）
乔老师，弱弱的问一句，做客户端（大前端），也有能力成为cto吗？ 我在大厂做客户端，出去面试一些中型公司，发现并没有什么能让他们感到稀奇的，感觉竞争力有限，不管是架构设计还是功能实现，以及跨平台等；如果是做后端，可以和业务关系很大，也可以涉及分布式等技术，中型公司有可能没这方面经验，这样就显得有竞争力了。 另外，客户端做后端的工作一般短时间难以胜任，相反后端可能只需要改变思维方式和学些知识点就能上手客户端开发了。 是因为技术深度不够吗？是不是足够深也能听懂相关（后端）专家的讲解，从而可以做决策；还是说做客户端的天花板确实低一些，那这该怎么突破呢？ 希望得到老师的指点
2020-12-09 - sunnyrqw 👍（8） 💬（1）
对乔老师专栏中认知和管理部分的内容做了总结，内容在如下链接：https://mp.weixin.qq.com/s/WDxXxU1gIp3yCtvgrUQHgA
2020-12-02 - adang 👍（6） 💬（1）
1. 没有完美无缺和永不过时的方案，公司向前发展，当时选择的"最优方案"也会慢慢不适用，需要管理层不断做决策； 2. 如果管理者能够结合自己的知识维度提前做好预判，做好布局最好，也就是上医治未病； 3. 如果下属提出想法，管理者能给予支持，由成员分析设计提供方案，结合自己的经验给予指导，最终拍板，大家都会有成长； 4. 有些时候，可能会需要找一些对公司业务价值影响不大的地方练兵，提升团队作战能力，也就是工欲善其事，必先利其器； 5. 技术管理者不可能是全面专家，所以管理者要有快速学习和知识整合能力，能给出自己的见解； 6. 敢于承担后果也是管理者的重要能力，最怕一心只想保住自己头上乌纱帽，不敢做决策，遇事就用"拖"字决的管理者；
2021-02-16 - spark 👍（5） 💬（2）
通过这篇专栏建立了技术管理针对技术方面的认知：首先要做架构决策。 架构决策不只是流程机制的环节，需要有技术内功。乔老师，主导架构决策的人应该是架构师？技术管理者或者CTO只是从宏观、资源层面等提供关键意见。 技术管理者如何和架构师分工？我自己感觉一不小心就从技术管理变成了架构师。
2020-12-02 - 今晚刀谁 👍（4） 💬（3）
乔老师，跟公司利润无关的技术优化，技术架构调整，一般很难得到领导的支持，特别是不懂技术的领导，作为项目经理，如何去推动架构升级的工作呢？
2020-12-02 - dbtiger 👍（3） 💬（1）
乔老师您好！ 我的收获： a.“T” 型人才，有一技之长，如扎根之树，固其根本方能茁壮向上生长！ 想咨询的问题： 1.EBS架构和分布式架构也是按业务场景来选型的吧？零售连锁如果不做互联网电商实际上EBS更加适合，电信领域一直也是EBS架构。 2.“坚决落地日历协同的文化和工具”跟您确认一下是前几篇提到的飞书是吧？ 3.现在的苏宁出问题了，乔老师有什么感触呢？
2020-12-15 - 骄之 👍（3） 💬（2）
乔老师，有没有什么好的办法能够有效提升逻辑思维能力？因为这方面的短板，经常被老板批，虽然我是做程序员的，而且数学也不错，但是逻辑思考总是不灵光。请老师指教。
2020-12-07 - 张浩 👍（3） 💬（1）
有一种思考方式，自己一直在使用，遇到困难或者问题的时候，要持续不断地思考，什么最重要、什么更重要，乔老师分享了架构决策能力是技术管理者最重要的能力，对自己的启发很大。 让我出发前，就知道未来要面对的问题，知道要重点关注什么，知道最重要的事情有哪些，感谢乔老师的真诚分享。
2020-12-05 - 术子米德 👍（3） 💬（2）
🤔☕️🤔☕️🤔 我们团队最近正在做软件架构的决策 其中讨论到架构原则的部分，就是说架构里应该如何的内容。刚开始几个架构师都很有自己的主见，提出不少一看就觉得有理，甚至觉得很棒的原则。 不过很快就出现了矛盾，那就是几个看起来都很有理的原则，它们之间居然有冲突，甚至是不可调和的矛盾。大家谁都说服不了谁，都觉得自己有理。 既然说服不了谁，那就各自回家写理由，把能支撑自己选择的理由写出来，就像这个小论文一样。而且，我们约定出了理由，还必须能举出例子，必须是我们业务和功能相关的例子，来支撑这个理由。 现在还在讨论进行中，不过给不出任何理由的，完全是直觉性的原则，都自动排名靠后，甚至自动淘汰了。
2020-12-02 - Geek_b68480 👍（3） 💬（4）
老师好，没有管理经验，也没有机会怎么过渡到管理岗呢？技术管理一定要技术比其他人优秀才能做吗？
2020-12-02 - 风飘，吾独思 👍（3） 💬（2）
一将无能，累死三军。一个好的CTO能给团队指引正确的方向，选择有时候比努力更重要。之前自己片面的人为，一个好的leader能够帮助下属做好工作。后来发现，授人以鱼不如授之以渔，真正聪明的leader是能够为下属指引好方向，关键事情做好决策，不让下属多走弯路。
2020-12-02 - 小乙哥 👍（2） 💬（1）
乔大，看到你说“一把手是团队的天花板”很有感触。如果一把手“满足了”，不努力了，下属难道只有转岗跳槽吗？感觉自己的上升通道已经明显受限于一把手与团队业务
2021-01-31 - 谷常生 👍（2） 💬（1）
这一讲的核心是两个字「决策」，CTO 和 CEO 的区别在于要做出和技术相关的决策。 《智识分子》这本书里介绍过的一项调查研究，美国各个阶层学校教育的教学方法和培养目标： * 底层强调「死记硬背」，要求严格按照流程操作，连数学都要背诵解题步骤； * 中层强调只要能「做对就行」，不管你用什么巧妙解法； * 专业人士孩子上的学校，强调「创造性和独立性」。鼓励孩子独立思考、自我表达，比如几个同学一起拍摄一部电影； * 而精英阶层强调的是「决策和选择」。老师不再要求孩子弄特别漂亮的 PPT之类，更在乎的是分析问题的能力。 专业篇的开篇讲「决策」真是意料之外，仔细想想又在情理之中。T 型人才的一竖，可以学习其他专栏 :P 这一讲要反复学习。虽然我们团队小，但是本讲介绍的架构决策流程和模板，特别是理念，值得借鉴。 「沟通创业价值，分享带来快乐」，坚持留言的第 11 篇。
2020-12-06 - Weehua 👍（2） 💬（1）
有两点感悟：1. 对于技术管理者，除非特殊情况需要尽快确定方案并执行，否则还是要用文章中的第二个方法，让相关小伙伴给出架构方案，最后大家沟通讨论，最好领导者拍板决定！这样做对于下属是有成长的，大家都有成长。2. 技术管理者肯定不会是全面的专家，对于自己不熟悉的领域，最起码要给出自己独到的见解指导团队。 有一个疑问：一般工作中的架构决策，到总监这个层面就会定了吧，不用再往上走了吧？我认为对于公司未来的核心技术规划需要到CTO这个层面，请乔老师指点！
2020-12-06 - leslie 👍（1） 💬（1）
老师的课程中讲到带队冲锋其实深有体会-：多少时间去冲锋，什么样的关键点其实必须冲很重要。梳理关键思路，冲关键难点，现场冲锋冲的都是关键思路和Key，团队项目超过10个且分散在各地时-带不动冲不动；不同项目不同思路，带他们冲时不做笔记-估计后面自己都忘了。 架构：广义上是系统的，其实这其中包含了人员、系统，有时觉得就像是带兵打仗；不清楚形式不用好每个兵-这仗没法打。
2021-03-07