【巨人的肩膀】谈谈技术能力+技术架构的设计方法

谈谈技术能力

版权声明

作者简介：朱春茂（知明），蚂蚁金服国际事业群资深技术专家，全球资金平台技术负责人，负责了蚂蚁全球化进程中底层资金清结算、外汇等平台能力的搭建和迭代演进。版权归原作者所有

技术人成长的悖论

在程序员界有一个悖论持续在困惑着很多技术人：在写代码的人的困惑是一直写代码是不是会丧失竞争力，会不会被后面年轻的更能加班写代码的人汰换。典型代表就是工作 5 年左右的核心技术骨干，此时正处于编码正嗨但也开始着手规划下一个职业发展阶段的时候；没在写代码的人困惑是我长时间不写代码（或者代码量较少）我的技术功底是不是在退化，我在市场上还会有竞争力吗，我的发展空间是不是被限制住了。典型代表就是带业务项目的架构师或者团队 Team Leader，他们更多的精力是在业务需求理解和拆分，团队事务的管理上
这种围城现象非常严重，是技术人在职业发展过程中必定会面临的困境。但要回答清楚这个问题，其根源不在于是写不写代码或者代码量的多少，其本质还是要回到什么叫技术能力以及如何提升技术能力这个根节点上来。我把我的一些观察和思考总结下来，供大家参考

到底什么是技术能力

要解释清楚什么是技术能力还得看透技术能力的本质，从源头上来做剖析。挑选几个程序员日常的工作问题来做个剖析比对，从我们的日常感观中来辨识下哪些是有技术能力的做法，哪些是没啥技术能力的做法

两类日常工作

• 重复琐碎类工作
  有一类工作是专门处理其他组技术同学对组内业务的疑惑进行解答，我们称之为 daily 支持。比如咨询你负责的系统在开发环境有一个报错影响了他们的项目联调是什么原因。这种工作的典型特征就是，随时都可能有人来问你问题，还有可能是同一个问题不同的人来问你很多遍。这类工作称归纳为重复/琐碎类工作。这类工作我们来看看几种做法：
  1. 就事论事，把这个问题回答了结束。到这个程度你只是解决了一个具体的问题。很可惜我们很多技术同学都是处于这个层次
  2. 解答完这个问题后即整理成文档，把排查步骤写清楚，提升自己和同组人的工作效率。到这个程度说明你看到并解决了内部效率问题
  3. 将此排查问题的方法和逻辑固化为小工具给到咨询的同学去用，让他以后可以自助排查解决，这样既解决了别人的问题也彻底释放了自己和同组人的效能。到这个程度说明你重新定义了效能问题并找到更好提效的办法
  4. 将此问题背后根因找到，从业务原理或者产品功能上去找解法。将技术工具抽象为业务功能的完善。到这个程度说明你已经从单纯的技术提效看到了架构合理性问题，并尝试在业务上寻求彻底根治的办法

这四种不同的做法我们可以看出来，即使是这些重复的琐碎类工作，我们也可以从扩大受益面的角度去提炼价值，然后寻求多个层次的解法。在解决问题的过程中自然而然也锻炼了自己多层次的思考和抽象能力

• 抽象复杂类工作
  还有一类工作是相对抽象和复杂的工作，它的典型特质就是需要只能感受到现象，很难找到根因，没有明确目标和固定解法，需要自己做方案定策略。举个实际中遇到的例子，就是在复杂的系统链路中往往会出现联调效率十分低下的问题，每个研发同学都在抱怨各种各样的问题，但就是没法去根治。面对这样的复杂抽象问题，也有好几种做法：

1. 找到抱怨的同学，问一问具体的问题是什么，然后针对性解决
2. 更加广泛收集问题，然后列出来表格，归类分析并安排负责人跟进解决，最后定期跟踪进度
3. 深入分析表格的中的问题并对问题进行抽象，从架构调优和产品功能的角度去寻找原因，并寻找解决这些问题带来的业务价值，并确定目标拆解路径，最后按照任务推进和跟踪进展
4. 从更全局角度去思考此目标与年度目标的关系，与组织发展的关系，思考如何扩大此事的效益，思考如何通过这些事的解决锻炼和培养团队同学

可以看出来这种抽象复杂的工作，其实也有多种做法，看得更加细致是可以看到技术架构的调优，看得有深度可以与目标、组织成长结合在一起。当然也有很一般的做法，那就是纯粹单个问题解决，纯粹是变成项目经理，通过任务列表跟踪进度

技术能力层次模型

通过上面两类日常工作的分析，我们很明显可以看到有技术能力的做法特征是能够通过现象看到本质，并能够通过对问题的抽象归纳进行技术架构层调优以解决同类问题

因此我对技术能力的定义是：技术能力是一种以解决某种问题为目标的思路、方法与执行手段，其本质就是解决问题的能力。在编程领域，就是对遇到的业务问题进行抽象、提炼以及逻辑的构建，通过研发工具以提升解决问题的效能，减低人工低效的重复工作

如果用技术能力这个定义的方法论对 “什么是技术能力” 进行剖析，我提炼了一些模型来表达

这个能力模型按照逐步境界阶段分为了三层：

• 术，硬核技术能力
  术这个层面其实更多是硬核技术能力，基本上就是技术的基础功底（如计算机基础，分布式技术，质量意识等）。虽然这个归为是基础类，但这也是技术人的立身之本。工作 3-5 年的同学基本上都还是处于这个阶段，即需要大量的练习使得自己的技能非常娴熟
  处在这个阶段最重要的就是需要有技术好奇心，要有技术的专研力，通过时间的磨炼持久去学习去练习，使得自己能够成为团队的核心骨干力量

• 法，技术架构能力
  法这个层面其实更多的是技术架构能力，即通过现象看透本质，通过模型、原则来表达本质以解决抽象复杂类问题。这是一种高阶的技术架构思维，基本上 5-10 年的同学会处在这个阶段。这个阶段更多强调问题发现，问题定义，问题分析，问题解决的能力
  处在这个阶段是需要很强大的认知能力提升，这里必备的素质就是皮实和包容，要容得下不同的观点也要禁得起各种挑战。但这个阶段也有很大的误区，即非常容易被简化为就是要学习很多方法论或者套路

• 道，技术领导力
  道这个层面其实更多的是技术领导力，即通过技术影响力去寻找愿景和目标，带领组织拿取结战略结果。在这个阶段我们要基于深厚的技术架构能力和技术硬核能力。通过技术思维去解决超越纯技术领域的问题，一般来说 10+年的同学会遇到这类问题。这个阶段的成长也会更多面临人的底层素质能力升级，需要更多靠领悟而不是纯粹的训练和问题驱动的思考。这个阶段其实也有很大的误区，即很多人只学到了表面功夫而没有深得要领，纯粹就变成是对己就是自我修养的提升，对别人就是 PUA

如何提升技术能力

随着把技术能力层次模型定义出来，其实如何提升也有了一定指南。后续有机会可以分章节来论述这个技术能力的提升过程。但产出详细章节的实践论述前，还有一篇“内功心法”可以分享给大家：

寻找成长的源动力

大家往往对这个问题不以为意，觉得成长是每个人都想要的，但是大家没有仔细琢磨过促进你成长的到底是什么：是你自驱想要享受这个练、思、悟的过程还是因为渴望得到周边人的认可/反馈/评价。这两者在你顺利的时候可能没什么感觉，但当你面对晋升失败，项目不利等挫折的时候就会有非常大的差异
如果你能够找到自己成长的源动力，那么在遇到真正的困难和迷茫时候才能够摆正好自己的心态，寻找突破口，让自己走出困境，得到长足的成长

常态化的总结与反思

不管是编码类的技术基础学习成长，还是相对抽象的问题解决，还是技术领导力成长。只要是成长，只要能够抓住这两个关键就一定能够成功
第一个就是反思，能够敏锐地反思自己的不足，然后不断去修正自己的心态和行为让自己蜕变
第二个就是总结，总结的过程是不断梳理自己的过程，把自己迷迷糊糊，是是而非的东西分类归类，而且总结越多就能够用好时间的复利，就能够越促进成长
找到了源动力就解决了底层动机问题，通过总结和反思是能够利用上时间的复利，通过这两样心法就能够使得自己成为一个能够不断丰富完善自己的人，达到这样的状态必定能够成为技术强人

实用技巧

要做到常态化的总结与反思，最简单的技巧就是写文章，通过文字的整理可以让自己的思考更加成熟，想得更加成熟以后自然而然对外就能够讲得更加清楚，能够对外讲清楚就能够更好分享交流才能够真正去校正自己的想法是不是正确。所以我提了，以写代想，以想促讲，以讲验真的实用技巧

技术架构的设计方法

简介

技术思考本质还是结构化思考，所以常见的结构化思考方法也是适用的。这也是大家会看到很多技术架构师都会用一些方法论去分析问题的原因。但这里我不是重新去论述这些常见的技巧，而是分享从技术实战中得到的一些思考方法，为此我分为了技术架构设计的方法和技术 Leader 的思考方法两类

常用思考方法

技术思考本质还是结构化思考，所以常见的结构化思考方法也是适用的。这也是大家会看到很多技术架构师都会用一些方法论去分析问题的原因。但这里我不是重新去论述这些常见的技巧，而是分享从技术实战中得到的一些思考方法，为此我分为了技术架构设计的方法和技术 Leader 的思考方法两类

技术架构思考方法

0—>1

这个思考方法的含义是：当我们在一堆迷茫和混乱中不知道如何下口时，应该先贴近问题本身，还原客观事实，并快速形成 1 个能够拉起认知并快速讨论迭代优化的版本。大家围绕着这样的一个初始版本去叠加和丰富其他维度的内容，直到方案的共识

我举一个实际的 CASE，大家在谈某平台能力升级的方案时候会经常喜欢用 PPT 画一些模块图，试图通过一些抽象的词汇来厘定清楚边界，核心概念。大家以为是在讲本质讲原则但实际所有人听了都是云里雾里，不知所云。因为通过概念去推导概念是无法真正回答问题的。
而比较好的应对方法我总结为以下三个步骤：

• 用户视角的客观世界还原
  用户故事的串联，基于交互流程和真实的数据来描绘这件事在客观世界中用户视角看来是怎么发生的。这就是我们找准一个大家都能够共识的视角，让所有人快速把客观事实搞清楚画出来这个 1，而这个 1 就是后续讨论的靶子 。这个 1 的表现形式我认为往往都是很简单的，要么是交互时序图，要么是 Excel 表格，而不是复杂的模块概念图

• 客观信息的结构化整合与提炼
  只是树立起来 1 这个初始版本，还远远不够。因为第一个步骤只是将模糊、混乱的东西通过一种方法信息化表达出来，这还远远达不到使用的程度。所以还需要将上述信息进行结构化的整合与提炼，因为信息只有经过结构化才能够变成有意义的知识，才能够与之前的经验形成互动，也才能够进行初版的设计加工。比如对数据流的处理，就会发现有哪些是可以合并的同类项，有哪些平衡校验逻辑等

• 加入多元视角的检验与抽象
  通过第二步的处理把 1 这个版本变得更加丰满，但是要形成完整的可实施方案还远远不够。我们还需要加入更多维度的校验和抽象，比如进一步抽象以看透其本质，比如加入重要异常，ROI，合理性等扩展性等多方的视角去做校验

所以大家以后在遇到很多方案谈不清楚的时候，不要去听别人讲什么原则，概念，价值等等虚头巴脑的东西。把大家拉回来，回到最简单的最朴素的东西来对焦，那就是 一张交互序列图 或者 一张表格。越快速从一堆迷茫中快速提炼出这个 1 ，就越容易快速拿到结果

1—>0

这个思考方法的含义是：当我们在做一个方案时面临无数因素无法抓住关键点时，我们应该考虑删除法（把这个 1 拿掉不要行不行）去寻找决定性因素，以确保我们是真正的抓到了关键点

我举一个实际的 CASE，每年都会做技术规划，相信这是很多架构师/Leader 很痛苦的事。痛苦的根源就是在脑子里面有无数需求，有无数的待优化点，也有无数的想法在萦绕，看到每个点觉得值得在新一年做攻坚。最终多半形成的就是一个表格，把今年要做的事罗列下，最多还排个优先级，好一点的换个形式变成 xmind 或者 PPT，再稍微好一点的可能会搭配上业务的目标和策略打法。但透过这些表面现象，其本质就是一个表格，没有抓住重点的表格。相信大家应该都看得蛮多的了
如何应对这类问题我总结为一下几个技巧：

• 因果判断法
  很多时候我们都在谈，要抓住事情的本质，要具备化繁为简的能力，其实就是在谈通过表面的结果去探究真实的原因。所以在看哪些是决定性因素时，大家不妨用因果法去检验：这个因素到底是深层次原因还是诱导的结果

• 树干树枝法
  有时候各个因素之前并不是单纯的因果关系，而是依附关系，就像是树枝依附在树干上一样。而我们要找到决定性因素，可以尝试这个方法去检验：如果把这个因素去掉会不会影响全局，是不是导致结论不成立。通过这样多轮的分析，是可以绘制出来树干的与树枝的关系，这个树干就是要找的决定性因素

• 支点撬动法
  有时候各个因素之间可能没有直接或者间接关系，或者这个关联关系太弱很难通过以上两个手段去确定关键点。可以尝试支点撬动的办法，即寻找可以激发这一堆要素的关键要素。我之前给团队举一个例子，国家抓经济肯定不可能是米面粮油各种琐碎地抓，肯定是找到几个关键点起到支点撬动的作用，如房地产行业。抓住这个就能够带动上下游产业，进而激发各行各业

以上是目前实践下来的抓取关键点的一些方法。但这里一定也要注意一个粒度问题，千万不要走极端。比如一提关键点，就去思考本质，一提到本质就去找根因，一找根因就挖到人性，然后得出来就是人性的原罪问题。这种都是没有任何营养的做法，也不利于事情的推动解决

1—>2

这个思考方法的含义是：当我们思考一些抽象问题/方案时候，需要对问题进行拆分（一分为二），通过分而治之的方法来确定每个小问题的边界，通过对小问题的解决来降低全局的思考难度，以尽快形成解决方案

这个应该不需要举例子了，大家日常都应该有所接触，这里只是列举几个比较典型的技术架构动作：

• 纵深拆解
  拆解是非常好的一个将问题分而治之的办法，但要注意的是要做有机的拆解而不是物理的分解。比较典型的案例就是关于故障指标这个课题的处理，我是见过有团队层层分解，把故障指标分解到每个同学身上，这是极其错误的做法，也不可能得到想要的结果。我们应该是要做拆解，就是把要守住故障指标这个结果拆解成哪几类关键动作，进而要求团队关键动作做到位，而不是强行分解指标

• 横向解剖
  做过实际研发的同学一定遇到一些业务需求的讨论，很多时候来来回回扯不清楚，而且经常会出现产品说这是技术架构问题，技术架构说这是业务需求问题，业务方说这是产品设计问题的现象。要破解这个僵局就需要把这个问题进行解剖，一层一层解剖清楚，把业务需求问题描述清楚，把产品设计搞清楚，把技术方案搞清楚。每一层都面向上游屏蔽下游的细节，才有可能把问题定义得清楚。一般来说，将这件事参与的角色进行解剖会更容易看得全面，更透彻

以上是我实践对问题拆分的一些方法技巧，凡事多看几层终归是能够更加有结构性地认知事情本事，也越有利于问题的解决

1—>N

这个思考方法的含义是：当我们思考一些技术方案时候，不要仅局限在当时当刻的条件约束，要适当考虑系统的承载从 1 变到 N 的过程中的对系统架构带来的挑战。
做技术架构师的都知道做架构要求有前瞻性，不能被业务拖着走。但很多时候我们其实没有仔细思考如何才能够做到前瞻性，我总结为最关键的考虑的因素就是时间，把时间拉长来考虑关键生产资料可能发生什么变化，通过去架构这种变化所得出来的方案就具备了前瞻性。一般意义上来说，我们平台演进的生产资料抽象地归纳为三类：

1. 业务场景：这是最原始的生存资料，更是平台演进的源动力。典型的如市场份额变化，用户体价值的变化，竞对动态等
2. 团队组织：是人创造了平台，也是主导平台的演进发展，这个生产资料如果不能得到有效利用，充分释放能动性就会出现平台无法支持业务快速发展，同时人也在平台中内卷
3. 技术架构：技术架构其实本身也是非常重要的生产资料，这是很多人会忽略的地方。大家想一个最简单的例子，同一个变量分散在多个地方导致语义不清，维护成本巨大就明白了

针对这几个生产资料我抽取了几个技巧去思考如何从 1 扩张到 N：

• 架构考虑所有可能性但做有限明确实施
  从业务场景的变化情况来看，的确充满很多不确定性。也遇到过一种典型的业务与架构的死循环的情况：前端业务面临太多不确定性需要技术架构给予专业意见和评估，但是技术架构认为业务啥都想不清楚还要我评估这评估那，两边就开始互相死锁
  而比较好的做法就是架构能够基于自己的经验和业务变化的理解，将可能性进行罗列考虑，然后给出来基于 XX 业务假设下，系统架构需要 XX 量级的工作量做 XX 样的能力迭代升级，可以做到 XX 的业务效果和价值，但需要进一步 XX 的业务输入。这就是架构考虑所有的可能性的含义，是需要给予业务的选择
  但技术架构实施却未必是要留有太多的空白，架构要大但是实施要小，对于值得留白的地方做好扩展设计，对于实在看不清楚的地方就要明确拦截（宁愿不做也不错做），将可能性留足但也不瞎埋坑

• 没有靠谱的人只有靠谱的机器
  我常常去听一些故障复盘会议，在谈以后如何改进的时候很多同学都价值观爆棚，说以后XX类变更都加签上我来审核一道，我确认没问题再往后走。虽然这种精神值得鼓励但是这种做法实在是很不值得推荐，这样沉淀出来的平台其实是非常脆弱的，在做技术方案时一定要思考能够交给系统的绝对不能用流程，能够做到领域模型校验的千万不要靠旁路系统的侧面印证（如不必要场景下的核对）

• 提前思考“幸福”的烦恼
  很多技术同学都希望做高并发大流量的系统，但很多时候在写代码的时候身体很诚实，怎么简单怎么来。实际做的时候既不考虑大流量也不考虑高并发，对于资损风险考虑也极其少，而且基本上都很有道理：现在的业务量没到不需要考虑那么多，这种事发生概率极其小一期先这样…要对技术架构做提前思考就必须从每行代码做起，提前考虑高并发大流量和严谨性

通常来说大家其实都比较喜欢从 0 到 1 的过程，按照互联网的迭代式打法，后面的 1 到 N 的过程也会被不断压缩。所以提前在 0 到 1 的过程加入 1 到 N 的架构预判非常重要，因为很多时候结构性的问题在最开始就决定了，而且只有一次机会

-1<—>1

这个思考方法的含义是：当我们思考一些技术方案时候，不要一条道走到黑，要前后、上下、左右、正反多个方面去思考，让技术方案具备更多维的视角

我把常用的技巧总结如下：

• 正反思考法
  日常也 review 了很多同学产出的架构方案和系分以及测分，大家对于正常业务需求功能的论述基本上都没有啥大问题，按部就班去写就可以。但普遍的问题都是对问题的反面论述不多，如支付正常流程浓墨重彩，退款/拒付等逆向流程就没那么细致，业务功能正常流转论述很饱满但是异常场景就寥寥几笔。但正面与反面结合起来才是完整的一体，而且对反面的思考其实是对正面的有益补充。而且通常来说，我们在正面出现的概率大于反面，但是反面出现差错的影响所需要付出的精力却远远大于正面

• 极限思考法
  在 review 技术架构方案风险相关的内容时，我都会特意问一下，如果出现 XX 问题最坏的业务影响是什么。为什么是问最坏的业务影响，是因为如果谈风险那肯定都是有一点点的，不利于大家去深究最关键的问题。通过极限设问，其实是激发大家去做最坏的打算，有了最终极的兜底手段才能够更乐观去做技术变更

• 对称思考法
  在 review 代码或者逻辑结构时，在深挖细节和关键点后，我时常会拔出来看看整体的逻辑结构是不是饱满，是不是对称，是不是美。最简单的例子就是写了 if 我一定要有 else，不然没对称结构就让我很不舒服。因为我相信对称的美就是一种生产力，因为美的东西一定是简洁且直达本质的。而我们写程序要的就是逻辑清晰简单直达业务本质，逻辑结构清晰的基本上没大问题，不清晰（如变量瞎命名，方法无语义）的深挖下去多半都能发现大问题。根源就是逻辑清晰代码才清晰，代码不清晰基本上就是逻辑混乱，逻辑混乱就会产生 BUG

M*N —> M+N

这个思考方法的含义是：当我们思考技术问题时，可以尝试从系统耦合的角度去思考，尝试找一些突破口

我举一个实际的 CASE，高速公路网的连接不是把所有目的地之间都修一条高速公路，而是会选择修建复用的高速公路主干道 + 分支道路的方式来组织这个网络。一条一条串联的方式就是耦合在一起的，这就是 M * N。通过主干道 + 分支道路的方式 就是解耦的，M + N 就能够组建这个高速网络。
在技术架构上如何运用解耦这个技法，我有如下几个提炼:

• 解耦上下游关联性
  在业务和技术架构发展的前期，把很多东西糅杂在一起是最快解决问题的方法。但随着业务和平台架构的进一步演进，势必是要做解耦，目的就是重新去界定各个模块的边界，平衡新的业务发展要求下各方发展快慢的诉求差异，通过解耦互相松绑快速发展
  这种技法在服务化的分布式架构中非常常见，基本上跨域的平台架构升级都有解耦的影子

• 解耦各个角色的依赖
  解耦上下游关联性其实更多是在技术模型的抽象上，但在落入到技术模型范畴之前，还有就是我们在做更加抽象的解决方案探讨时要注意解耦各个角色之间的依赖。上述【架构考虑所有可能性但做有限明确实施】中提及的就是最好的案例。其实这里的本质表达就是，技术架构的设计应该要与商业选择，产品设计等解耦开来
  通过这一层的解耦其实能够多个角色之间基于 SLA 去交互，并且能够基于自身的专业思考给予对方更多的选项和可能性。很多时候的前瞻性和竞争力可能就是比别人多一个选择

解耦思考法其实很有意思，几乎所有的大型平台架构升级都有这个思考法的影子，所以下次没啥思路的时候可以从这个角度做一个审视思考，说不定是有新的收获

技术Leader思考法

向前思考，向后倒推

这个思考方法的含义是：在思考一个命题时可以采取未来视角，先对未来发展做个预判，然后基于你的判断倒推现在应该要做什么，最后制定出关键里程碑和节奏

这个思考模型经常用在技术规划这个场景上，但很遗憾很多团队的技术规划都只是基于当前问题，有多少资源，然后采取量力而行的方法在对事项优先级进行排序。这其实不是真正的规划，最多算是计划（如果做得不好，计划都算不上，只能算是列表整理）

这个思考模型有几个关键的误区：

• 不敢向前思考，担心自己对未来的判断不对
  我相信很多 Leader 都有这样的恐惧，会不会因为自己思考力不够判断失误导致团队拿不到结果。有这样的担心可以理解但是对事项推动无意义，因为：

1. 对上你的信息更细致，对下你的信息更全面，如果你都不能对未来做出好的判断，别人如何能够替代你做出判断。所以要有自信
2. 只要你的判断合理有逻辑，能够与大家达成共识，那至少说明这个判断不会太差，也是当下比较好的思考了，未必要追求绝对的正确，况且是不是真的正确只有变成了历史才知道（有时候往往历史也回答不了这个问题）
3. 团队未必是永远要做最有把握、最正确的事，团队力出一孔比追求哲学上的正确更重要
   所以需要 Leader 信息充分交换分享，有信心地对未来做出合理的判断，并与相关角色达成共识

• 只有向前思考，没有向后倒推
  也见过只有向前思考但没有一点向后倒推的技术规划，这种就是典型的飘在天上，形而上的概念一堆。但实际上这个思考模型的精髓就是在向后推的结合：

1. 向前某种意义上是在回答 to be （要做成什么样子）的问题，但向后推其实是在回答 have （当前有什么）以及 have to do（必须做什么）的问题
2. to be 是在激发大家的想象，让大家去共识心中的理想，这是能够激发团队的
3. have 以及 have to do 其实是在找与 to be 之间的 GAP，寻找 GAP 就是进一步去找到解法，这是进一步的落地
4. 这两者结合起来才是既能够理想主义找到未来，也能够务实地超前进步。我认为这就是对仰望天空，脚踏实地的诠释

目标与路径

这个思考方法的含义是：在思考一个命题要关注什么是目标，什么是路径以及目标与路径的关系。离开路径的目标是空谈，离开目标的路径是瞎干，所以目标与路径是一体两面的，离开任何一个不谈其实都不成立

同样地在技术规划这个场合，大家可以仔细去看看，很多规划都是只有目标的（这点其实已经做得蛮好了，因为大家的意识已经觉醒，没有目标不往下谈，所以不管目标设立好与坏但至少都是有的），但很少有规划是把路径讲清楚

虽然这个思考模型见闻知义很好理解，但同样地这个思考模型也有一些误区：

• 目标一定是要用来完成的
  Leader 都是要背负绩效压力的，所以天然就会有一个误区认为每一个目标都必须一丝不苟去完成。但一个低价值的 100%完成的目标 与 一个高价值的 90%完成的目标，未必一定是 100%完成就能拿高绩效，关键还是要看对组织的价值贡献
  所以 Leader 还是要辩证看这个问题，在设定目标时目标要具备很强的牵引性才行，是让需要团队去跳一跳的才能够达成的，让团队有斗志；自己在完成目标时也要带着团队努力往前冲，朝着高目标去想一切办法拿结果，但也要随时观察团队状态，不能为了达成目标不择手段或者把团队干废了

• 路径执行时被惯性带着走
  在细化目标的执行路径时，我们一般都会得到比较细致的 ACTION，甚至会有专人来管理和跟踪这些 ACTION。但比较容易出现的偏差就在于，我们做着做着就把初心忘了，把目标置于脑后了。典型的就是死命按照既定的路线走，没有重新基于当时的情况再回头看目标，去找是否还有更优的路径选择。所以时刻要反思什么是目的，什么是手段，不能把手段当成目的一味地执行

端到端思考

这个思考方法的含义是：在思考一个命题要尽可能关注到全链路，而不是铁路警察各管一端

这个使用的场景是在于线上的问题治理和优化，尤其是客户体验问题或者是效能提升的课题上。这个思考模式也是非常简单，但是同样误区也蛮多：

• 端到端从哪儿到哪儿没搞清楚
  想到端到端去思考和解决问题是非常好的，而且大家脑补就能理解大致想干什么事情。但这个思考模式最大的误区就在于它只是存在于大家的脑子里面，而不是白纸黑字写下来。最典型的场景就是 B 提出端到端思考解决了自己域的问题，但 A 未加仔细辨别，一听到端到端就想当然以为 B 也解决了 A 的问题。但实际上发现根本不是一码事，A 就开始吐槽 B 承诺没做到，B 就吐槽 A 瞎胡说
  要破解这个误区其实也蛮简单，就是把全流程画出来，大家先基于客观事实把流程达成一致，然后再在这个流程上圈定端到端是具体哪一段到哪一段

• 效果没有说清楚假定条件
  端到端一方面是把问题看全，另外一方面最重要的就是整体交付价值。这个端到端整体交付价值也有一个非常大的误区就是，对于假定条件没有说清楚。以端到端提效为例，那么提效就应该要讲清楚是基于什么业务范围做的端到端提效，以及能够达到什么提效效果。比较好的办法就是，以表格的形式把条件列清楚，然后对外给予端到端提效的明确效能结论。提效这个事其实没有尽头，只要做不到0投入那就一定要给予效能的确定性、相比较而言大家最怕的是效能不确定打乱原有的生产计划，而不是非要死扣几个人日的效能提升

闭环思考

这个思考方法的含义是：这其实是一个很形象的逻辑思考方法，思考一个命题要从初心出发再回到初心，以免出现重大偏差

这个模式理解起来也不复杂，但也有一些误区：

• 形而上的假闭环
  这其实是很多 Leader 非常容易走入的误区，没有实际展开命题的多个环节去做分析和探讨，把这种要求一味传递给团队要求做闭环的思考，即只有管理要求但缺乏技术领导力的洞察。一般来说，解题一个技术命题从开始孕育到落地有如下几步：

1. 觉察/认知（感知到现有平台/系统的问题，感觉需要做架构调优升级）
2. 概念/原理（挖掘到问题背后的本质，从业务原理/技术原理等底层出发抽取概念和本质）
3. 理解/共识（对问题本质做宣讲，达成上下左右的理解与共识）
4. 目标/路径（提出目标，拆解出来可实施的路径）
5. 表格/指标（提出衡量的指标和具体的 ACTION，最好的就是表格来跟进）
6. 小胜即庆 （对于阶段性目标的达成进行庆祝，当然这也是咬合业务价值的关键点）
7. 持续跟进 （小胜即庆还不能放松警惕，还需要持续推进到下一个任务）
8. 灵活应变 （根据实际情况调整优先级，同样是咬合业务价值而不是固守之前的任务表格）
9. 目标完成 （完成标准不是新平台/系统能力建设完成，而是完成模型统一，流量迁移完成，老代码下线等）
10. 下一个觉察 (开启下一个平台/系统的架构调优升级周期）

很多时候我们并没有真正的在闭环思考和跟进问题，如漏掉某些节点，或某些节点退出过早：

1. 比如很多平台建设在第 4)步做完就任其自然发生了，缺乏表格的跟踪机制，最后效果就是拖拖拉拉、磨磨唧唧拿不到结果
2. 比如很多平台建设小胜即庆做完就交接给其他人了，持续跟进出现严重问题，会导致不能灵活调整进而出现严重的建设障碍

• 缺少进阶的下一环
  闭环思维某种意义上应该说环环相扣的螺旋式上升的过程，这样才是能够不断驱动开启下一轮的进化。但很多 Leader 并没有很好意识到这个问题。以上述的闭环 10 个步骤为例，Leader 应该是在小胜即庆时就开始思考下一个觉察，在抛物线的顶点之前开始下一轮的思考继续才能够确保下一个闭环能够及时开启，进入螺旋式的优化进程中

指标量化思考

这个思考方法的含义是：没有量化就谈不上优化，所以在定义和推动解决一个命题时，要尽可能地把遇到的问题用数据指标的方式进行量化思考

同样地这个思考模式也有一些误区：

• 量化的维度缺失导致缺少客观性
  量化的本质其实是逼迫 Leader 更全面，更客观地理解问题。但要是更加客观地通过数据出现一个问题，也还是需要一些技巧，否则就会陷入心中已有答案，只是通过数据去做证明的困境。尤其是大团队越是要注意这个问题，通常来说组织这个群体是有自己的偏好，也是有动力和意愿去促成组织所偏好的事情。比如做技术的就倾向于偏好引导往架构优化上去，做业务的就会倾向于引导往完成 KPI 上去，但事实上更客观的应该是如何高效满足客户价值
  如何突破这个误区，我得到的经验思考就是呈现的数据维度与客观世界的匹配度，越高的就越客观，越客观才越有利于解决问题。只有通过数据量化出来这个问题才有可能找到可能的解法，才有后续方案选择时的取舍，不能本末倒置为因为选定了方案然后通过数据去论证取舍的合理性

• 量化的数据断层解读后的欺骗性
  数据客观反映只是第一步，如何解读才是决定了数据的利用价值。不怕没看到真相，只怕看到真相的一部分，不恰当的解读方法就会让我们看到真相的部分从而得出错误的结论。比如把自己和首富的财富的平均下，给人的感觉就是全民收入都大涨

常见的数据解读方法如下：

1. 高值 VS 低值 VS 平均值 VS 分位数：可以看出来数据的实际分布情况
2. 同比环比：可以看到各个维度的下数据的发展趋势
3. 全局 VS 局部：当全局性指标看完以后，一定要注意去搭配着 按照多个维度的局部数据。比如看完全国的人均收入 还要 看各个省份的数据，甚至还要细分到各个行业去看数据
4. 局部数据的横向比较：可以对比做些归类分析

数据指标量化其实可以用在任何一个场景，但很多人的触发机制不是很敏感，常常忘记这个思考模型。导致很多事情实际上是在靠感觉，靠感觉的东西不长久，有时候对有时候错。越是比较抽象比较虚比较容易讲感觉的恰好就是练习的好时机，当你下次感觉到团队状态不对时，你可以尝试下如何用数据指标化的方法去做个思考，看能够量化出来哪些维度的数据

故事与形象思考

这个思考方法的含义是：技术 Leader 在给大家讲解自己的思考时，要注意通过故事的形象思考，尽可能将问题讲得透，让大家都能够懂

这一点是很多技术人都不是特别重视的地方，他们往往这样想：

• 技术人踏实会干比能说会道重要得到，前者才是真正的硬核技能
  这反映了很多技术人的潜意识想法，尤其是做底层的同学。但我们是忘记人类协作的本质就是基于共同想象，如果我们都不能把自己要做的事讲清楚，如何激发大家一起干事情。作为技术 Leader 一定要摒弃这种想法，技术能力和良好的沟通能力两手都要硬

• 专业的本来就有门槛，为啥要浪费时间和精力去讲给不懂的人听
  持有这样观点的人也不少，认为专业就应该有一定的神秘感，给人一种不明觉厉的感觉。但实际上真正的专业就是大道至简，用大白话去给别人解释清楚复杂的事情。那种不能够大白话讲清楚的多半自己还是半灌水，还不是真正的专业
  而要克服这些问题最好的方法就是讲故事打比方这种形象化的思考模型，其实 PPT 就是用图片这种形象化去表达复杂的思考逻辑。至于如何讲好故事我觉得想想西游记就好了：

1. 确定初心和目标、以及意义。西游记就是要取经普渡天下众生
2. 一路上困难重重，但总能不忘初心克服困难。不管是师徒四人的矛盾，还是降妖除魔都是不断遇到和克服的困难
3. 拜见佛祖取得真经，传播众生。历经劫难取得真经，然后回到东土大唐给天下人讲经

技术 Leader 在领导团队建设平台/系统时候，也可以用这样的故事讲法去激励大家。当然要讲好故事不只有这样一个结构，但本质初心是想技术 Leader 能够加入形象化思维，通过比方，通过故事让大家深刻理解你要做的事，这样才能够更好让大家朝着目标协同

乘数效应

这个思考方法的含义是：技术 Leader 在思考一个技术命题时，要充分考虑这件事的影响力，比如有些决定做下去可能是影响 10 个人，有些决定做下去可能是会间接影响 100 人，这种乘数效应必须是技术 Leader 要慎重考虑的，越大的 Leader 越要注意

乘数效应可以说是双刃剑，好的乘数效应能够让大团队享受到红利，但差的事件也会让所有人都受到波及。因此有如下实践：

• 自上而下的决策要慎审，充分考虑乘数效应
  作为团队 Leader 尤其是二线 TL，在做一些决策时务必要考虑乘数效应带来的威力（有时候二线 Leader 和一线 Leader 的差异就是在管理这个乘数效应），经常有如下两个误区：

1. 执行的难度未充分估计，被乘数效应放大。很多决策看起来都挺对也很有价值，但出发点可能是基于管理需要而不是一线同学工作的必须。这带来的问题就是迟迟无法落地，变成上有政策下有对策
2. 执行结果未 CHECK，实际完全走偏。如果 Leader 太自信，未有上述闭环思考的方法去跟进具体有乘数效应的事项，到最后就会出现进退两难的境地。因为大部分都走偏继续朝前也不可能，但又因为有太多的沉没成本舍不得放弃

• 主动管理自下而上的乘数效应
  为了组织蓬勃发展，我们肯定是鼓励一线同学充分发挥乘数效应，以让大团队都能够享受到红利。但 Leader 一定要去主动识别和管理这些具有乘数效应的事项，要对可能出现的问题进行及时纠正和干预，典型的纠偏就是防止重复建设防止内卷。但对于确实对全局有利的，要做好及时的推广并主动帮忙解决推进过程中的障碍，让大团队尽可能享受到红利。但无论如何，对于这类具有乘数效应的都必须要有管理清单，鼓励好创新但也慎审做决策

小结

技术 Leader 是集架构师，管理者，领导者一身的综合性岗位，多年实践下来也只是窥探到了部分。所以以上只沉淀的点滴思考技巧，当然也不可能解决所有的实际问题。期望这些思考对大家做好技术 Leader 有一些帮助