,技术常用思考方法,这个思考方法的含义是：,在思考一个命题时可以采取未来视角，先对未来发展做个预判，然后基于你的判断倒推现在应该要做什么，最后制定出关键里程碑和节奏。,这个思考模型经常用在技术规划这个场景上，但很遗憾很多团队的技术规划都只是基于当前问题，有多少资源，然后采取量力而行的方法在对事项优先级进行排序。这其实不是真正的规划，最多算是计划（如果做得不好，计划都算不上，只能算是列表整理）。,这个思考模型有几个关键的误区：,我相信很多 Leader 都有这样的恐惧，会不会因为自己思考力不够判断失误导致团队拿不到结果。有这样的担心可以理解但是对事项推动无意义，因为：,对上你的信息更细致，对下你的信息更全面，如果你都不能对未来做出好的判断，别人如何能够替代你做出判断。所以要有自信。,只要你的判断合理有逻辑，能够与大家达成共识，那至少说明这个判断不会太差，也是当下比较好的思考了，未必要追求绝对的正确，况且是不是真的正确只有变成了历史才知道（有时候往往历史也回答不了这个问题）。,团队未必是永远要做最有把握、最正确的事，团队力出一孔比追求哲学上的正确更重要。,所以需要 Leader 信息充分交换分享，有信心地对未来做出合理的判断，并与相关角色达成共识。,也见过只有向前思考但没有一点向后倒推的技术规划，这种就是典型的飘在天上，形而上的概念一堆。但实际上这个思考模型的精髓就是在向后推的结合：,这个思考方法的含义是：,在思考一个命题要关注什么是目标，什么是路径以及目标与路径的关系。离开路径的目标是空谈，离开目标的路径是瞎干，所以目标与路径是一体两面的，离开任何一个不谈其实都不成立。,同样地在技术规划这个场合，大家可以仔细去看看，很多规划都是只有目标的（这点其实已经做得蛮好了，因为大家的意识已经觉醒，没有目标不往下谈，所以不管目标设立好与坏但至少都是有的），但很少有规划是把路径讲清楚。,虽然这个思考模型见闻知义很好理解，但同样地这个思考模型也有一些误区：,Leader 都是要背负绩效压力的，所以天然就会有一个误区认为每一个目标都必须一丝不苟去完成。但一个低价值的 100%完成的目标 与 一个高价值的 90%完成的目标，未必一定是 100%完成就能拿高绩效，关键还是要看对组织的价值贡献。,所以 Leader 还是要辩证看这个问题，在设定目标时目标要具备很强的牵引性才行，是让需要团队去跳一跳的才能够达成的，让团队有斗志；自己在完成目标时也要带着团队努力往前冲，朝着高目标去想一切办法拿结果，但也要随时观察团队状态，不能为了达成目标不择手段或者把团队干废了。,在细化目标的执行路径时，我们一般都会得到比较细致的 ACTION，甚至会有专人来管理和跟踪这些 ACTION。但比较容易出现的偏差就在于，我们做着做着就把初心忘了，把目标置于脑后了。典型的就是死命按照既定的路线走，没有重新基于当时的情况再回头看目标，去找是否还有更优的路径选择。所以时刻要反思什么是目的，什么是手段，不能把手段当成目的一味地执行。,这个思考方法的含义是：,在思考一个命题要尽可能关注到全链路，而不是铁路警察各管一端。,这个使用的场景是在于线上的问题治理和优化，尤其是客户体验问题或者是效能提升的课题上。这个思考模式也是非常简单，但是同样误区也蛮多：,想到端到端去思考和解决问题是非常好的，而且大家脑补就能理解大致想干什么事情。但这个思考模式最大的误区就在于它只是存在于大家的脑子里面，而不是白纸黑字写下来。最典型的场景就是 B 提出端到端思考解决了自己域的问题，但 A 未加仔细辨别，一听到端到端就想当然以为 B 也解决了 A 的问题。但实际上发现根本不是一码事，A 就开始吐槽 B 承诺没做到，B 就吐槽 A 瞎胡说。,要破解这个误区其实也蛮简单，就是把全流程画出来，大家先基于客观事实把流程达成一致，然后再在这个流程上圈定端到端是具体哪一段到哪一段。,端到端一方面是把问题看全，另外一方面最重要的就是整体交付价值。这个端到端整体交付价值也有一个非常大的误区就是，对于假定条件没有说清楚。以端到端提效为例，那么提效就应该要讲清楚是基于什么业务范围做的端到端提效，以及能够达到什么提效效果。比较好的办法就是，以表格的形式把条件列清楚，然后对外给予端到端提效的明确效能结论。提效这个事其实没有尽头，只要做不到0投入那就一定要给予效能的确定性、相比较而言大家最怕的是效能不确定打乱原有的生产计划，而不是非要死扣几个人日的效能提升。,这个思考方法的含义是：,这其实是一个很形象的逻辑思考方法，思考一个命题要从初心出发再回到初心，以免出现重大偏差。这个模式理解起来也不复杂，但也有一些误区：,这其实是很多 Leader 非常容易走入的误区，没有实际展开命题的多个环节去做分析和探讨，把这种要求一味传递给团队要求做闭环的思考，即只有管理要求但缺乏技术领导力的洞察。一般来说，解题一个技术命题从开始孕育到落地有如下几步：,很多时候我们并没有真正的在闭环思考和跟进问题，如漏掉某些节点，或某些节点退出过早：,闭环思维某种意义上应该说环环相扣的螺旋式上升的过程，这样才是能够不断驱动开启下一轮的进化。但很多 Leader 并没有很好意识到这个问题。以上述的闭环 10 个步骤为例，Leader 应该是在小胜即庆时就开始思考下一个觉察，在抛物线的顶点之前开始下一轮的思考继续才能够确保下一个闭环能够及时开启，进入螺旋式的优化进程中。,这个思考方法的含义是：,没有量化就谈不上优化，所以在定义和推动解决一个命题时，要尽可能地把遇到的问题用数据指标的方式进行量化思考。同样的这个思考模式也有一些误区：,量化的本质其实是逼迫 Leader 更全面，更客观地理解问题。但要是更加客观地通过数据出现一个问题，也还是需要一些技巧，否则就会陷入心中已有答案，只是通过数据去做证明的困境。尤其是大团队越是要注意这个问题，通常来说组织这个群体是有自己的偏好，也是有动力和意愿去促成组织所偏好的事情。比如做技术的就倾向于偏好引导往架构优化上去，做业务的就会倾向于引导往完成 KPI 上去，但事实上更客观的应该是如何高效满足客户价值。,如何突破这个误区，我得到的经验思考就是呈现的数据维度与客观世界的匹配度，越高的就越客观，越客观才越有利于解决问题。只有通过数据量化出来这个问题才有可能找到可能的解法，才有后续方案选择时的取舍，不能本末倒置为因为选定了方案然后通过数据去论证取舍的合理性。,数据客观反映只是第一步，如何解读才是决定了数据的利用价值。不怕没看到真相，只怕看到真相的一部分，不恰当的解读方法就会让我们看到真相的部分从而得出错误的结论。比如把自己和首富的财富的平均下，给人的感觉就是全民收入都大涨。,常见的数据解读方法如下：,数据指标量化其实可以用在任何一个场景，但很多人的触发机制不是很敏感，常常忘记这个思考模型。导致很多事情实际上是在靠感觉，靠感觉的东西不长久，有时候对有时候错。越是比较抽象比较虚比较容易讲感觉的恰好就是练习的好时机，当你下次感觉到团队状态不对时，你可以尝试下如何用数据指标化的方法去做个思考，看能够量化出来哪些维度的数据。,这个思考方法的含义是：,技术 Leader 在给大家讲解自己的思考时，要注意通过故事的形象思考，尽可能将问题讲得透，让大家都能够懂。这一点是很多技术人都不是特别重视的地方，他们往往这样想：,这反映了很多技术人的潜意识想法，尤其是做底层的同学。但我们是忘记人类协作的本质就是基于共同想象，如果我们都不能把自己要做的事讲清楚，如何激发大家一起干事情。作为技术 Leader 一定要摒弃这种想法，技术能力和良好的沟通能力两手都要硬。,持有这样观点的人也不少，认为专业就应该有一定的神秘感，给人一种不明觉厉的感觉。但实际上真正的专业就是大道至简，用大白话去给别人解释清楚复杂的事情。那种不能够大白话讲清楚的多半自己还是半灌水，还不是真正的专业。,而要克服这些问题最好的方法就是讲故事打比方这种形象化的思考模型，其实 PPT 就是用图片这种形象化去表达复杂的思考逻辑。至于如何讲好故事我觉得想想西游记就好了：,技术 Leader 在领导团队建设平台/系统时候，也可以用这样的故事讲法去激励大家。当然要讲好故事不只有这样一个结构，但本质初心是想技术 Leader 能够加入形象化思维，通过比方，通过故事让大家深刻理解你要做的事，这样才能够更好让大家朝着目标协同。,这个思考方法的含义是：,技术 Leader 在思考一个技术命题时，要充分考虑这件事的影响力，比如有些决定做下去可能是影响 10 个人，有些决定做下去可能是会间接影响 100 人，这种乘数效应必须是技术 Leader 要慎重考虑的，越大的 Leader 越要注意。,乘数效应可以说是双刃剑，好的乘数效应能够让大团队享受到红利，但差的事件也会让所有人都受到波及。因此有如下实践：,作为团队 Leader 尤其是二线 TL，在做一些决策时务必要考虑乘数效应带来的威力（有时候二线 Leader 和一线 Leader 的差异就是在管理这个乘数效应），经常有如下两个误区：,为了组织蓬勃发展，我们肯定是鼓励一线同学充分发挥乘数效应，以让大团队都能够享受到红利。但 Leader 一定要去主动识别和管理这些具有乘数效应的事项，要对可能出现的问题进行及时纠正和干预，典型的纠偏就是防止重复建设防止内卷。但对于确实对全局有利的，要做好及时的推广并主动帮忙解决推进过程中的障碍，让大团队尽可能享受到红利。但无论如何，对于这类具有乘数效应的都必须要有管理清单，鼓励好创新但也慎重做决策。,技术 Leader 是集架构师，管理者，领导者一身的综合性岗位，多年实践下来也只是窥探到了部分。所以以上只沉淀的点滴思考技巧，当然也不可能解决所有的实际问题。期望这些思考对大家做好技术 Leader 有一些帮助。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
