一、常用思考法

架构设计思考法可以参考：技术人员成长之路-架构设计方法

二、不同的思考法叙述

2.1 向前思考，向后倒推

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

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

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

不敢向前思考，担心自己的对未来的判断不对。

我相信很多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、这两者结合起来才是既能够理想主义找到未来，也能够务实地超前进步。我认为这就是对仰望天空，脚踏实地的诠释。

2.2 目标与路径

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

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

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

目标一定是要用来完成的

Leader都是要背负绩效压力的，所以天然就会有一个误区认为每一个目标都必须一丝不苟去完成。但一个低价值的100%完成的目标与一个高价值的90%完成的目标，未必一定是100%完成就能拿高绩效，关键还是要看对组织的价值贡献。

所以Leader还是要辩证看这个问题，在设定目标时目标要具备很强的牵引性才行，是让需要团队去跳一跳的才能够达成的，让团队有斗志；自己在完成目标时也要带着团队努力往前冲，朝着高目标去想一切办法拿结果，但也要随时观察团队状态，不能为了达成目标不择手段或者把团队干废了。

路径执行时被惯性带着走

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

2.3 端到端思考

在思考一个命题要尽可能关注到全链路，而不是铁路警察各管一段。这个使用的场景是在于线上的问题治理和优化，尤其是客户体验问题或者是效能提升的课题上。

这个思考模式也是非常简单，但是同样误区也蛮多：

端到端从哪儿到哪儿没搞清楚

想到端到端去思考和解决问题是非常好的，而且大家脑补就能理解大致想干什么事情。但这个思考模式最大的误区就在于它只是存在于大家的脑子里面，而不是白纸黑字写下来。最典型的场景就是B提出端到端思考解决了自己域的问题，但A未加仔细辨别，一听到端到端就想当然以为B也解决了A的问题。但实际上发现根本不是一码事，A就开始吐槽B承诺没做到，B就吐槽A瞎胡说。

要破解这个误区其实也蛮简单，就是把全流程画出来，大家先基于客观事实把流程达成一致，然后再在这个流程上圈定端到端是具体哪一段到哪一段。

效果没有说清楚假定条件

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

2.4 闭环思考

思考一个命题要从初心出发再回到初心，以免出现重大偏差。

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

形而上的假闭环

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

-->1) 觉察/认知（感知到现有平台/系统的问题，感觉需要做架构调优升级）

-->2) 概念/原理（挖掘到问题背后的本质，从业务原理/技术原理等底层出发抽取概念和本质）

-->3) 理解/共识（对问题本质做宣讲，达成上下左右的理解与共识）

-->4) 目标/路径（提出目标，拆解出来可实施的路径）

-->5) 表格/指标（提出衡量的指标和具体的ACTION，最好的就是表格来跟进）

-->6) 小胜即庆（对于阶段性目标的达成进行庆祝，当然这也是咬合业务价值的关键点）

-->7) 持续跟进（小胜即庆还不能放松警惕，还需要持续推进到下一个任务）

-->8) 灵活应变（根据实际情况调整优先级，同样是咬合业务价值而不是固守之前的任务表格）

-->9) 目标完成（完成标准不是新平台/系统能力建设完成，而是完成模型统一，流量迁移完成，老代码下线等）

-->10) 下一个觉察 (开启下一个平台/系统的架构调优升级周期）

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

1、比如很多平台建设在第4)步做完就任其自然发生了，缺乏表格的跟踪机制，最后效果就是拖拖拉拉、磨磨唧唧拿不到结果。

2、比如很多平台建设小胜即庆做完就交接给其他人了，持续跟进出现严重问题，会导致不能灵活调整进而出现严重的建设障碍。

缺少进阶的下一环

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

2.5 指标量化思考

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

量化的维度缺失导致缺少客观性

量化的本质其实是逼迫Leader更全面，更客观地理解问题。但要是更加客观地通过数据出现一个问题，也还是需要一些技巧，否则就会陷入心中已有答案，只是通过数据去做证明的困境。尤其是大团队越是要注意这个问题，通常来说组织这个群体是有自己的偏好，也是有动力和意愿去促成组织所偏好的事情。比如做技术的就倾向于偏好引导往架构优化上去，做业务的就会倾向于引导往完成KPI上去，但事实上更客观的应该是如何高效满足客户价值。

如何突破这个误区，我得到的经验思考就是呈现的数据维度与客观世界的匹配度，越高的就越客观，越客观才越有利于解决问题。只有通过数据量化出来这个问题才有可能找到可能的解法，才有后续方案选择时的取舍，不能本末倒置为因为选定了方案然后通过数据去论证取舍的合理性。

量化的数据断层解读后的欺骗性

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

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

1、高值 VS 低值 VS 平均值 VS 分位数：可以看出来数据的实际分布情况。

2、同比环比：可以看到各个维度的下数据的发展趋势。

3、全局 VS 局部：当全局性指标看完以后，一定要注意去搭配着按照多个维度的局部数据。比如看完全国的人均收入还要看各个省份的数据，甚至还要细分到各个行业去看数据。

4、局部数据的横向比较：可以对比做些归类分析。

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

2.6 故事与形象思考

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

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

技术人踏实会干比能说会道重要得多，前者才是真正的硬核技能。

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

专业的本来就有门槛，为啥要浪费时间和精力去讲给不懂的人听。

持有这样观点的人也不少，认为专业就应该有一定的神秘感，给人一种不明觉厉的感觉。但实际上真正的专业就是大道至简，用大白话去给别人解释清楚复杂的事情。那种不能够大白话讲清楚的多半自己还是半灌水，还不是真正的专业。

而要克服这些问题最好的方法就是讲故事打比方这种形象化的思考模型，其实PPT就是用图片这种形象化去表达复杂的思考逻辑。至于如何讲好故事我觉得想想西游记就好了：

1、确定初心和目标、以及意义。西游记就是要取经普渡天下众生。

2、一路上困难重重，但总能不忘初心克服困难。不管是师徒四人的矛盾，还是降妖除魔都是不断遇到和克服的困难。

3、拜见佛祖取得真经，传播众生。历经劫难取得真经，然后回到东土大唐给天下人讲经。

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

2.7 乘数效应

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

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

自上而下的决策要慎审，充分考虑乘数效应

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

1、执行的难度未充分估计，被乘数效应放大。很多决策看起来都挺对也很有价值，但出发点可能是基于管理需要而不是一线同学工作的必须。这带来的问题就是迟迟无法落地，变成上有政策下有对策。

2、执行结果未CHECK，实际完全走偏。如果Leader太自信，未有上述闭环思考的方法去跟进具有乘数效应的事项，到最后就会出现进退两难的境地。因为大部分都走偏继续朝前也不可能，但又因为有太多的沉没成本舍不得放弃。

主动管理自下而上的乘数效应

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

参考资料：

1.微信公众号（阿里技术）-《团队管理｜如何提高技术Leader的思考技巧？》

技术Leader的思考技巧相关推荐

知明：技术 Leader 的思考法
技术 Leader 是一个对综合素质要求非常高的岗位,不仅要有解具体技术问题的架构能力,还要具备团队管理的能力,更需要引领方向带领团队/平台穿越迷茫进阶到下一个境界的能力.所以通常来说技术 Leade ...
作为一个技术Leader，要如何去提升团队的技术氛围
一个技术团队,不管大小,如果没有"技术味道",那么技术Leader负有很大的责任."技术味道"的缺失,是目前技术团队存在的最大问题.特别是做业务开发的技术团队, ...
从工程师到技术leader的思维升级
从技术新人到一个成熟的技术leader,需要经历几个身份迭代?每一次身份的转换都需要怎样的思维升级?本文将从技术新人.潜力干将.架构师.技术leader四种身份的思维升级依次展开. 作者:君山阿里业 ...
程序员，这是你想要的技术leader吗？
作者|周明耀编辑|小智技术团队的领导总是在发愁怎样带团队,团队的程序员总是会抵触各种团队"文化".规章制度.两者都有各自的角度和出发点,很难分出真正的对错.这篇文章里的技术le ...
优秀技术Leader应具备的六项能力！
技术Leader是互联网公司中,战斗在一线的技术领导者,技术Leader们能力的强弱,决定着公司整个技术团队的战斗力,结合我之前管理上百人技术团队的经验,谈谈我心目中优秀技术Leader五个方 ...
CTO丢给我《技术Leader的30条军规》：照着做，做不好滚回去写代码！
作者| Mr.K 来源| 技术领导力(ID:jishulingdaoli) 老K之前在电商独角兽公司担任过技术VP,带过几百人的技术团队,这几年下来,从我手下出去的Leader,有10几人都已经是各大 ...
前facebook产品技术leader徐玮：如何建立用户增长机制
嘉宾介绍徐玮,facebook用户增长产品 Core growth product 用户增长产品 Video ads direct response ads product leader 商业化产品 ...
技术 Leader 怎样带跨一个团队？
网上很多分析大公司,小公司的文章,都会提到在大公司工作就是螺丝钉,岗位分的非常细,每个人把自己的专职工作做好就行:而在小公司需要每个人都是多面手,一岗多职. 这种观点我同意一半,在小公司中,某些阶段人 ...
instagram技术_Instagram9位科技女孩进行技术采访的主要技巧
instagram技术 by Rachel 通过瑞秋 Instagram9位科技女孩进行技术采访的主要技巧 (Top tips for technical interviews from nine o ...

技术Leader的思考技巧