138 lines
13 KiB
Markdown
138 lines
13 KiB
Markdown
# 11 | 全局思维和持续完善体系的建立，让团队持续成长
|
||
|
||
你好，我是乔新亮，很高兴又与你见面了。
|
||
|
||
在技术管理领域，有一个很古怪的现象，不知道你是否有注意到：很多管理者，在面对团队成员的争吵时，会选择冷处理、和稀泥，也有人干脆沉默以对，直接忽略这个状况。
|
||
|
||
但你肯定知道，理论上，管理者是应该介入争吵，及时调停的 —— 不然团队士气和协作就会受损。
|
||
|
||
那为什么会有这样的情况出现呢？原因可能是多种多样的，但一个主要的原因，可能是缺乏全局思维。注意，这个评价不单针对发生争吵的双方，也针对不作为的管理者。
|
||
|
||
只要是争吵，情况一般都比较类似：双方各有各的道理，互不退让。作为管理者，也不想影响任何一个人的积极性，所以两头为难，干脆不管。
|
||
|
||
其实，如果缺乏全局思维，就会经常面临这样的决策难题。有个成语叫作“盲人摸象”，意思是说，几个盲人要通过触摸大象，来描绘大象的形象。于是，摸了象牙的人说，大象像一根长棍；摸了象腿的人说，大象像一棵大树；摸到大象肚子的人说，大象像一堵墙……
|
||
|
||
他们说错了吗？**站在个人的角度，没错；但站在全局的角度，****可能每个人都****错了**。很多管理层面的问题，其实都可以用“盲人摸象”来形容，道理极其相似。吵架，只是缺乏全局思维造成的众多问题之一。
|
||
|
||
2019 年在环球易购时，我就经历过这样一件事。
|
||
|
||
## 高可用设计或许是个“伪命题”
|
||
|
||
在环球易购，我们主要做的是跨境电子商务，服务遍布很多国家和地区，其中有一条线路，是通过光缆连接美国达拉斯到深圳的机房。
|
||
|
||
我去了没多久，在检查基础设施的高可用建设时，发现线路居然只有一条 —— 很明显不符合高可用设计的思想。因为光缆是有可能被挖断的，底层基础传输网络的抗风险能力太差。
|
||
|
||
作为技术管理者，看到了风险，当然要想办法解决了。
|
||
|
||
但着手解决时，相关业务部门却不愿意为新增加的光缆付费，说目前部门的压力大，不愿意承担这个费用。听到这种说法，我带领的团队对此很是不屑一顾 ——什么压力大，简直就是不懂啥叫高可用。
|
||
|
||
你看，一个典型的问题场景出现了，技术人员在想：明明有问题，不想着去补救，出问题的时候可别找我；业务部门想的是：我这业务压力这么大，你还要纠结什么架构设计，啥也不懂。
|
||
|
||
站在各自的角度，他们说的都对，根源在于看问题的视角不够高，缺乏全局思维。
|
||
|
||
我和我的团队说，首先，我们要学着去理解业务部门；然后，我们来分析下，对于企业而言，这种设计到底有什么样的风险。
|
||
|
||
其实，这条光缆的问题不会对 C 端业务造成影响，只会影响后台的统计分析。接着，我们向上看，根据过往经验分析：如果光缆被挖断，相关业务会中断多久、影响范围有多大？
|
||
|
||
最后，技术团队将相关调研整理、总结，和业务部门坐下来相互对齐，得出结论：业务影响处于可以接受的范围，结合公司情况，暂不增加备用光缆。
|
||
|
||
到我离开环球易购时，其实这条线路仍然只有一根光缆。光缆也被挖断过，但无论是 IT 部门还是业务部门，都能接受这个结果，没有争执和推诿。因为这是站在全局视角，大家研讨得出的结论，虽然有利也有弊，但都在预估范围内。
|
||
|
||
你看，当我们去各类技术会议学习分享时，大家经常探讨高可用、高并发的架构设计。但在实际的工作中，这类设计不一定能实现，甚至也不一定在当下对于公司是最合理的。
|
||
|
||
类似的问题还常见于中台建设。
|
||
|
||
这两年中台特别火。很多技术 leader 好不容易把中台研究明白了，觉得这个设计思想好啊，回去就要搞，结果业务部门不愿意，说：
|
||
|
||
“你说做中台、做中台，说了半天就是架构更好了。我们这个月的 KPI 都要完不成了，还要支持你做个半年不见效的中台？”
|
||
|
||
于是，技术 leader 把自己气得够呛，觉得这哪叫“技术驱动型科技公司”，没有一点长远眼光，自己留在公司就是浪费青春。
|
||
|
||
那么这又是一个有关全局思维的问题，我们要回答的，其实不是中台在架构方面的优劣势，而是在半年以上的时间维度里，中台对于整个企业，在营收增加、业务增长方面的优劣势。
|
||
|
||
如果说得清楚，其实业务部门也有不小的接受可能，因为大家不但需要考虑短期增长，也会追求长期增长；如果说不清楚，其实中台做了也是白做，属于管理者自己没想明白。
|
||
|
||
所以，在前面的章节里，为什么我总是强调：研发团队要有业务思维，业务团队也要接受技术指标考核呢？一个重要原因，就是要赋予双方更高维度的视角，让大家在工作中有全局思维。
|
||
|
||
## 全局思维与向上管理
|
||
|
||
当然，以上我们说的全局思维，都是站在更高的维度，将技术视角和业务视角统一起来，学会用业务增长的思维看待技术建设。
|
||
|
||
但全局思维又不仅仅局限于此。很多人觉得老板的问题很难回答，因此比较怕和老板对话，为什么呢？因为和老板相比，你缺乏全局思维，格局不够高，因此面对老板的提问，常常感觉出乎意料、难以回答。
|
||
|
||
而这一点，在每一个职级都会有所体现。一般情况，在同一家企业内，CTO 的全局思维通常强于技术总监，技术总监的全局思维通常强于技术经理，而技术经理又强于普通程序员。
|
||
|
||
会出现这种差异，当然有信息不对称方面的原因，但同时也有思维格局上的高下之分。比如，很多企业都在推行“公开透明”的企业文化，但基层员工仍然和高层管理者在思维层次上有极大偏差。为何？因为从上到下，没有培养全局思维的意识。
|
||
|
||
每次周会，都会有许多下属讲自己的工作情况，我的回应经常是：“**你说的都对，但这个有什么用？产品是什么，用户是谁？对用户有什么好处，对公司有什么益处？**”
|
||
|
||
请注意，我不是在质疑或者否定下属，而是在强迫下属站在全局的视角去思考。
|
||
|
||
刚才我们讲的是自上而下的思考模式。这段时间，也有很多同学留言说，乔老师，能不能讲讲向上管理？其实向上管理，就恰恰相反，属于自下而上的思考模式。
|
||
|
||
很多 CEO 其实很讨厌“向上管理”这个词，一是听起来确实让人不大舒服，像是在沟通中，掺杂了很多心机和花样；二是在很多 CEO 眼里，“向上管理”属于伪命题：是 CEO 真的需要被管理，还是下属自以为比 CEO 更明智？
|
||
|
||
听起来，是不是有点耳熟？对，这其实和下属吵架有一个共同的逻辑：双方都没说错，只是视角局限在自己这一侧。
|
||
|
||
所以，所谓的向上管理，其实不像很多新媒体文章说的一样：说话先赞同再反对、和老板培养感情，等等。
|
||
|
||
这些当然可以做，但都只是锦上添花，属于沟通技巧，不算向上管理。**真正的向上管理，是培养全局思维，把自己的思维拔高，和老板站在同一个维度看待问题，同时保持密切、顺畅的沟通**。
|
||
|
||
不然的话，你的所思所想跟老板压根不在一个频道上，怎么“向上管理”？时间长了，老板只会觉得你自以为是、恃才傲物。
|
||
|
||
那么如何培养全局思维呢？
|
||
|
||
说起来倒也不难，主要是**从两个维度去尝试重新思考问题：一是时间维度，二是空间维度**。
|
||
|
||
所谓时间维度，是指遇事不要只看当下得失，要学会站在未来六个月、一年甚至三年的维度看得失。很多让人难以决断的问题，只要站在更长的时间维度去看，就会豁然开朗。
|
||
|
||
空间维度，则是指，不要只站在自己的视角看待问题，要时常做好身份转换。比如技术人员要考虑，站在业务部门的角度，会如何考虑这个问题？站在财务部门的角度，会如何考虑这个问题？站在 CEO 的角度，会如何考虑这个问题？这是个人所处空间上的变换。
|
||
|
||
你可能会想，听起来很简单，就是挺累啊，一个问题要在不同的角度思考这么多遍，烦死了……
|
||
|
||
其实，这就是思维和认知能力养成的特点：说起来都不复杂，但做起来需要绝大的毅力和耐心。在我们专栏的第一章，大部分认知能力都存在这样的学习特点。但与第一章的许多认知不同，那些属于个人成长相关的认知，而全局思维属于团队管理方面的认知：管理者不但自己要具备全局思维，还要让团队也拥有全局思维。
|
||
|
||
这么难养成的认知，怎么传递给团队呢？这时就需要建立持续完善体系，让团队持续成长。可以说，如果没有持续完善体系，团队根本就不可能具备全局思维。
|
||
|
||
## CTO 也可能犯错
|
||
|
||
在向团队灌输全局思维时，你可能会很头疼。因为有时团队就是不理解、就是不接受，甚至会表现得很偏执，让人只想在心里骂娘。
|
||
|
||
这时，你要提醒自己：**既然大家都通过了公司面试，就说明基础能力还是有的，没人真的是傻瓜。团队是能进步的，要给团队进步的时间**。
|
||
|
||
其实我们专栏从上架到现在，我一直在重复这句话。很多管理者，表面上支持“试错容错”的文化，但骨子里就没期望过大家会成长。
|
||
|
||
哪怕是 CTO，都会犯错，何况是普通员工呢？不给大家留出成长的时间和空间，怎么带领团队打胜仗呢？
|
||
|
||
2015 年年底到 2016 年年初，我在苏宁工作，曾带着团队做关于容器编排的技术选型。当时，针对容器编排管理工具，有两个选择：一个是 Swarm，另一个是 Kubernetes。
|
||
|
||
当时我们确实是努力站在全局视角去思考的：
|
||
|
||
在当时，Swarm 的架构简单，是 Docker 内嵌模块，部署运维成本低，在业务角度有利于降本提效；Swarm 是 Docker 的原生编排工具，支持度好，容器的启动速度高……
|
||
|
||
相比之下，Kubernetes 当时的情况就有些不尽如人意，所以我们最终选择了 Docker + Swarm 来做容器化改造。
|
||
|
||
结果，还不到一年，我就知道自己做了错误的决策。你可能也看到了，Kubernetes 后续的成长速度非常惊人。于是，我召集团队，承认了自己的失误，立刻做了调整。
|
||
|
||
后来复盘这件事时，我发现，在做技术选型时，我们少考虑了一个关键因素：大厂的支持能力。如果再有类似的选型工作，我一定会将大厂的支持能力作为重要的选择条件。
|
||
|
||
但回到全局思维这件事上，犯错实属正常，哪怕是 CTO 也一样。就像我们常做的 A/B Test，这本就是体系建立工作的一部分。
|
||
|
||
所以，当你实践这一讲所收获的认知时，如果有不耐烦、不如意的时刻，一定要提醒自己：不要急，这很正常，这些都只是成长的浩瀚大海中的一朵小浪花，都是建立持续完善体系所需的正常工作。
|
||
|
||
## 结语
|
||
|
||
这一讲，我们重点聊了聊管理维度的全局思维和持续完善体系的建立，这是一个不断迭代的过程。
|
||
|
||
一个组织就如同一个人，如何让这个组织有格局，并且能快速学习、持续迭代，是管理者一个重要的能力。迭代，就意味着前面有不完美的地方，在全局视角下具备纠错能力，用更短的周期、更快的速度持续完善，这样组织能力也会随着时间，不断登上新的台阶。
|
||
|
||
最近，我和一些 CEO 聊天，问他们过去在管理上最大的失误是什么，有好几位都是想了半天也说不上来。为什么？不是因为没犯过错，而是因为对于他们来说，试错、迭代都是正常流程，被正常迭代掉的问题能叫失误吗？当然不能，那本来就是规划之内的情况。你想想，自己和这些 CEO 是否有这种认知上的差距？你能否以同样的心态，看待自己的成长？
|
||
|
||
**我相信，你一定能做到快速成长。或许现在，也可能是未来的某一天，你也会是那个“没犯过错”的 CEO。**
|
||
|
||
今天的内容到这里就结束了。下一讲，我们会重点谈一谈，在具备了全局思维后，如何在战略上做聚焦、做取舍，真正做到 CEO/CTO 级别的认知协同，为跨上新的台阶做好准备。
|
||
|
||
我们所讲的管理者“三板斧”、管理哲学、全局思维、战略聚焦等内容，都是关联在一起的，你在看的时候，要注意前后对照，串联起来。这样的成长才成体系，才不会有失偏颇。
|
||
|
||
如果有问题，欢迎随时向我提问。我们下一讲再见！
|
||
|