|
|
# 17 | 架构决策，是技术管理者最重要的能力
|
|
|
|
|
|
你好，欢迎来到我的专栏：「乔新亮的 CTO 成长复盘」第三章 —— 也是最后一章：「对专业成长的复盘」，我是乔新亮，很高兴能见到你。
|
|
|
|
|
|
说起来真的有点感慨，自从 10 月 26 日专栏上线起，眨眼间，我们共同度过了一月有余的时光。
|
|
|
|
|
|
在这段时间里，有超过 3500 人加入课程，与你我一起成长。专栏共发布了 17 篇文章，收到了超过 500 条留言，有好多同学是篇篇都留言，一路相随。基本上，每一条留言我都回复了，收获了许多感动与启发。
|
|
|
|
|
|
感谢你！
|
|
|
|
|
|
接下来，我们将以技术和架构思维为抓手，夯实管理者的成长基础，争取做一个底子打得扎实、向上生长快的优秀技术管理人才。最终，我们的目标是，成为一名优秀的 CTO。如果你觉得有收获，不妨把文章分享给其他人。不同的声音越多、交流的价值越大，成长的速度就越快。
|
|
|
|
|
|
好，我们言归正传，聊一聊如何理解和提升架构决策能力。
|
|
|
|
|
|
## 决策失误，是“技术债”的主要来源
|
|
|
|
|
|
你可能会想，老乔是在吊人胃口吗？在「专业成长」部分，不赶紧讲架构设计，反而去讲所谓的架构决策能力。
|
|
|
|
|
|
事实上，回顾这些年的管理经验和见闻，我认为架构决策能力不但非常关键，而且是技术管理者最重要的能力之一，而且职级越高就越重要。
|
|
|
|
|
|
2012 年初，我身在 IBM，为苏宁提供顾问服务。
|
|
|
|
|
|
当时，苏宁面临一个重大的架构决策问题：是继续沿用 ESB（企业服务总线）架构，还是转向分布式架构。
|
|
|
|
|
|
在今天看来，这个问题或许不需要讨论 —— 很多企业都在拥抱分布式架构，放弃 ESB 架构。但在当时，苏宁是更倾向于继续沿用 ESB 架构的。
|
|
|
|
|
|
因为在苏宁的技术架构内，是存在 SAP 服务和一些异构系统的，不能直接弃用 ESB，选择分布式等于同时维护两套系统。
|
|
|
|
|
|
但我坚定地支持采用分布式架构，理由有很多：
|
|
|
|
|
|
1. ESB 是一个集中点，风险非常大； 如果选择 ESB 架构并且让其承载大量的业务逻辑（系统间调用的处理逻辑），后续转型困难；
|
|
|
2. 系统内虽然存在部分异构系统，但大部分是同构系统，分布式系统完全可以支撑；
|
|
|
3. 在分布式架构中，不同服务可以直接访问，无需像 ESB 架构一样经过负载均衡系统和网络交换机，避免了资源的浪费；
|
|
|
|
|
|
……
|
|
|
|
|
|
虽然理由很多，但在工作性质上，我属于乙方，是企业外部人员；而持反对意见的是甲方，属于企业内部人员。大部分情况下，乙方不会在这种问题上和甲方争执到底 —— 如果甲方已经有非常明确的倾向和意见，那就顺从甲方，不是挺好的吗？
|
|
|
|
|
|
但我知道，架构决策事关重大，所以坚持表达了意见。最终，苏宁的 IT 系统也顺利转型为分布式架构，没有走上歧路。
|
|
|
|
|
|
最让我庆幸的是，2015 年我加入了苏宁。如果当初没有坚持转型分布式架构，三年之后，就会有一个庞大、臃肿、高风险的“烂摊子”架构在等着我收拾，那该有多么痛苦？
|
|
|
|
|
|
说了这么多，并非是要突出自己聪明。恰恰相反，我相信人人都很聪明，也非常专业，但如果在一个重要的架构决策失误了，企业就可能需要花三年、五年甚至更久的时间来“还债”。
|
|
|
|
|
|
你看，其实很多所谓的“技术债”，也就是由一次次的决策失误不断累加而成的。
|
|
|
|
|
|
那么什么是架构决策能力呢？简单来说，就是当团队因架构方案的选择，出现争议、迟迟不能决定时，管理者需要具备的、一锤定音的能力和方法。
|
|
|
|
|
|
新架构多久落地，说到底只是个效率问题。但如何拍板确定新架构的设计，则是重要的方向性问题。如果方向不对，那么无论团队里有多少精兵猛将，也只能跟着漫无目的地瞎忙，这就是所谓的“一将无能，累死三军”。
|
|
|
|
|
|
## 选择“不作为”，往往更加可怕
|
|
|
|
|
|
说句公道话，很多管理者虽然会出现决策失误，但至少做了决策，使业务在一定时间内可以维持增长。最不靠谱的是，管理者选择不做决策，导致团队工作无限期阻塞，严重影响业务发展。
|
|
|
|
|
|
举个例子，有两个团队成员坐在会议室里，争论两个架构设计方案孰优孰劣。他们各执一词，谁也说服不了谁。这时，你作为技术管理者，应该怎么办？
|
|
|
|
|
|
我大概见过三种处理方式：
|
|
|
|
|
|
1. 给大家分析哪一种方案更好，现场拍板；
|
|
|
2. 指出当前双方考虑不周到的地方，再给大家时间去准备，并在 Deadline 前决策拍板；
|
|
|
3. 泛泛地对大家说：“不够具体”、“没有重点”，“再回去想想”……
|
|
|
|
|
|
第一种、第二种其实都是正确的处理方式，建立在管理者内心已经有答案、有见解的基础上，前者追求决断效率，后者看重团队培养，都很棒。
|
|
|
|
|
|
但第三种就有点值得玩味了。很多时候，这代表某种“职场生存技巧”。表面上，管理者希望团队多多思考，但实际上，他是自己没想明白。至于接下来，无非是一个字：拖。
|
|
|
|
|
|
有些方案或项目甚至因此延期半年以上，这对于一家企业来讲是非常危险的。
|
|
|
|
|
|
所以，在这一讲的开始，有一个关键认知，我一定要同步给你：
|
|
|
|
|
|
**一把手是团队的天花板，并为团队的所有问题负责。**
|
|
|
|
|
|
作为管理者，尤其是前几年，我经常用以上认知告诫自己。映射到架构决策层面，也就是一把手一定要有勇气在方案之间做取舍，并承担相应的后果。
|
|
|
|
|
|
当然，架构决策也不能乱做，千万别说：乔老师说了，要敢于做决策，然后闭着眼睛挑了一个答案……
|
|
|
|
|
|
关于架构决策，其实是有一套意见反馈和流程模板的。
|
|
|
|
|
|
## 做好架构决策的流程和模板
|
|
|
|
|
|
当管理者需要做架构决策时，就意味着至少有两个、三个甚至更多架构方案摆在面前，各有利弊，需要高层协助决策。在苏宁时，我还为此建立了一套架构决策流程，决策流程如下：
|
|
|
|
|
|
1. 当事人发起架构决策申请；
|
|
|
2. 由产品负责人判断：该申请是在产研中心部门内协调解决，还是上升至 CTO 办公室解决；
|
|
|
3. 在产研中心部门内，或联合 CTO 办公室，完成架构评审；
|
|
|
4. 将结果发还至当事人征询意见；
|
|
|
5. 由当事人判断是否仍有疑虑，需要进行架构仲裁；
|
|
|
6. 若需要则发起仲裁会，解决分歧；若不需要则结案归档，执行决策。
|
|
|
|
|
|
过程中可能涉及的参与人包括：产品负责人、技术负责人、架构师团队、架构负责人、CTO 办公室负责人等。如果是部门内协调解决，则 CTO 办公室不参与评审；如果评审后仍有分歧，则 CTO 办公室连同其他负责人一起介入架构仲裁，快速解决问题。
|
|
|
|
|
|
你可能会想，设计这么长的流程和表单，难道不是人为地加长决策周期吗？有点不太“敏捷”啊。
|
|
|
|
|
|
没错，只要涉及到新增制度、新增流程，无论考虑得多完善，都会降低团队敏捷度 —— 初创团队几乎总是动作最快的，万人大厂相对来说就要迟缓一些。因此，在管理小团队时，我可能不会推行以上决策流程，因为我的精力足够覆盖团队每一次重要决策；但对于大型企业来说，上述制度就开始变得非常重要。
|
|
|
|
|
|
同时，我们也要认识到，用体系化的解决方案解决组织问题，是正确的认知。但体系化的解决方案一旦在实际工作中开始落地，也非常容易“变形”。**在上述决策流程里，最困难的不是架构评审和架构仲裁，而是向下推进的动作和速度。**
|
|
|
|
|
|
越是高级管理者，日程排得越满，越难约时间开会。决策流程一旦涉及到 CTO 级管理者，推进速度就可能变得非常慢，这在很多企业都是切实存在的现象。
|
|
|
|
|
|
我的解决方法，是回到我们专栏的第二章第二节：《管理者最重要的三个任务（二）：加强组织协同效率》，坚决落地日历协同的文化和工具。当团队做好日历协同时，只要管理者某一时段的日历是空白的，就可以预定会议，对组织全体适用。若有特殊情况，单独沟通。
|
|
|
|
|
|
所以你看，任何策略、体系化的解决方法，都很难脱离企业文化而独立存在。有一句话说得好：文化吞噬策略如早餐。
|
|
|
|
|
|
管理者要优先配合下属做好架构决策，反过来，下属也要进行细致准备，节约时间、提升效率。在架构评审发起前，发起人最重要的工作之一，就是填写和提交一份意见反馈表单，表单内容大致如下图所示：
|
|
|
|
|
|
|
|
|
|
|
|
通常，当你看到这份表格，很可能会最先注意到「业务需求」、「可选方案」、「决策结果」和「决策理由」等关键字。毕竟，这几项直接构成了基本的决策流程，确实非常重要。
|
|
|
|
|
|
但是请注意，当整个决策流程完成时，表格中每一项都应该被填满，没有例外。我们先来看看，表单其他部分的设计目的：
|
|
|
|
|
|
* 从「待决策内容」到「决策申请编号」，这部分内容是为了更好地将决策事件归档，以备以后参考、调研、借鉴；
|
|
|
* 「假设条件」是为了注明可选方案的依赖条件，以免出现建设“空中楼阁”的情况；
|
|
|
* 「重要性」的标注是为了提升决策效率；
|
|
|
* 「因决策而产生的需求」和「其他相关决策」，则是确保决策可以落地。
|
|
|
|
|
|
不过具体到表单的某一项，模板中是没有字数限制的。填写意见反馈表的标准是：逻辑清晰、完整，能让他人能够准确理解。
|
|
|
|
|
|
相比决策流程，这张表单的泛用性可能更高，作用也非常关键，我认为大概有四点：
|
|
|
|
|
|
第一，这套流程和意见反馈模板，可以让当事人及各参与方，做好充分的思考和准备，避免浪费大家的时间；
|
|
|
|
|
|
第二，所有分歧会落实到纸面上，能防止沟通出现歧义，也预防推诿、扯皮的现象发生；
|
|
|
|
|
|
第三，可以培养所有人的大局观和架构决策能力，间接推动人才梯队建设；
|
|
|
|
|
|
最后，用体系化方案解决团队问题，追求的是“一劳永逸”地解决问题。
|
|
|
|
|
|
**更重要的是，无论是流程还是表格，都不仅是一样工具，更是一种思维模式**。越早养成这种思维模式，对个人成长的帮助越大。如果你能在思考、验证后，将其沉淀为文档，相信有一天，你也能起草适合自己公司和业务的架构决策模板。
|
|
|
|
|
|
写到这里，我不得不承认：即便拥有了架构决策流程和模板，要高效率地进行正确的决策，对于管理者而言，依然是个巨大的挑战。各领域、各方向的架构设计往往有其独特的一面。尤其是业务架构的设计，可能还会掺杂一些“历史原因”。如果不是代码维护者，几乎很难讲清楚业务逻辑。
|
|
|
|
|
|
这时，管理者怎么做架构决策呢？
|
|
|
|
|
|
## 技术管理者如何做好架构决策
|
|
|
|
|
|
我认为，要做好架构决策，管理者至少需要具备两项特质。
|
|
|
|
|
|
**第一项特质：要学会站在全局视角看待问题，学会看到技术架构的“外部价值”**。这种“外部价值”包括：公司利润、人效、资源利用率、业务风险，等等。
|
|
|
|
|
|
说到这里，请你暂停并回想一下：在这一讲的开头，我提到了 2012 年在苏宁完成的架构决策：在 ESB 和分布式架构之间，我选择了分布式架构。这个决策具备哪些“外部价值”呢？
|
|
|
|
|
|
这是个有关企业技术平台的架构决策，所以和收入、利润的关联度都很小。但分布式架构确实大大降低了业务风险，也在系统交互层面提高了资源利用率。这些都是非常明显的优势。
|
|
|
|
|
|
但如果只能看清“外部价值”，也不能让技术管理者做好架构决策，否则一个不懂技术的 CEO 才是最好的架构决策者。
|
|
|
|
|
|
这就要求决策者具备**第二项特质：具备相当的技术深度，以及非常好的学习能力和逻辑思维。**
|
|
|
|
|
|
时隔 8 年，今天再谈起在苏宁选择分布式架构的往事，总是有点云淡风轻。但在背后，是一箩筐的技术细节：你要知晓 ESB 和分布式架构支持同构、异构服务时，各自的优劣势；你要知晓两者通过 TCP/IP 和 IP 协议交互所带来的效率区别；你要知晓 ESB 架构中，负载均衡系统和交换机的存在，以及由此而来的资源浪费，等等。
|
|
|
|
|
|
在前面的内容里，我们一直强调做 “T” 型人才，其中一个重要的原因就在此时得到了体现：有一条足够深入的技术栈，是你前进的巨大倚仗。
|
|
|
|
|
|
那么，是不是分布式专家就只能参与分布式架构的决策呢？当然不是，CTO 几乎不可能成为真正意义上的全栈技术和架构专家 —— 在一个梯队建设较为成功的企业里，走技术路线的下属，几乎总是会在某一专业领域胜过你。
|
|
|
|
|
|
这时，管理者的学习能力和逻辑思维就会派上用场。做架构决策时，我们要求写好意见反馈模板，其中一个重要意图是让当事人将架构背后的逻辑讲明白。
|
|
|
|
|
|
而管理者要做的就是：通过下属的表述，快速理解业务和架构逻辑，短时间内成为这一细分问题的专家，然后进行决策。
|
|
|
|
|
|
“只要你能讲清楚，我就一定能掌握”，如果通过坚持不懈的练习，养成了这一专业素质，管理者将在架构决策方面无往而不利。
|
|
|
|
|
|
你可能会说，老乔啊，我们团队的成员，嘴都比较笨，真的是说不明白。没关系，管理者可以多加引导，一个很好用的小技巧是：引导对决策存在分歧的双方，就方案合理性互相“攻击”。
|
|
|
|
|
|
你可以要求当事人 A 首先阐述方案，并进行提问，比如：你凭什么说这个方案就能节省资源？在当事人 A 回答完之后，询问当事人 B ：你对他刚才的阐述难道没有疑问吗？
|
|
|
|
|
|
这样一来二去，方案背后的逻辑就会更加清晰，管理者也就更容易进行决策了。
|
|
|
|
|
|
## 结语
|
|
|
|
|
|
今天，我们聊了聊有关架构决策的认知、体系框架，以及高层管理者需要具备的基本素质。
|
|
|
|
|
|
对于初级管理者来说，要尽早培养自己的架构决策能力，尤其重视思维模式的培养、个人技术栈的深度扩展以及逻辑思维能力的锻炼。
|
|
|
|
|
|
对于高级管理者来说，则要做好认知层面的储备。很多 CTO 面对下属的架构决策求助，回复都是“我忙着呢，过两天吧”、“你自己再想想，晚点再说”。
|
|
|
|
|
|
高级管理者不能总是瞎忙，如果你真的意识到，架构决策是技术管理者最重要的任务之一，就一定会为类似的决策会议腾出时间。
|
|
|
|
|
|
拖延做决策的管理者，要么是不懂，要么是战略懒惰，很少有第三种情况。而所谓“战略懒惰”，常常表现为管理者自己冲到一线“拼杀”，却对团队的方向性问题反应迟钝。
|
|
|
|
|
|
当然，做管理的时间一长，确实也会怀念“带队冲锋”的感觉，我觉得没什么问题。但要注意，“冲锋”这个动作，一定发生在战略决策之后。而善于做决策，又敢于冲锋的管理者，在现代商业环境中，一定大有可为。
|
|
|
|
|
|
好了，关于架构决策，我们就聊这么多。
|
|
|
|
|
|
让我们下一讲再见！
|
|
|
|