|下篇：技术 Leader 的思考方式( 二 )

端到端思考这个思考方法的含义是：
在思考一个命题要尽可能关注到全链路，而不是铁路警察各管一端。
【|下篇：技术 Leader 的思考方式】这个使用的场景是在于线上的问题治理和优化，尤其是客户体验问题或者是效能提升的课题上。这个思考模式也是非常简单，但是同样误区也蛮多：
端到端从哪儿到哪儿没搞清楚
想到端到端去思考和解决问题是非常好的，而且大家脑补就能理解大致想干什么事情。但这个思考模式最大的误区就在于它只是存在于大家的脑子里面，而不是白纸黑字写下来。最典型的场景就是 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 上去，但事实上更客观的应该是如何高效满足客户价值。