认知 | 从CTO那里学到的成长经验

https://mp.weixin.qq.com/s/vvUEtn1T0KJAfNggvr3ggg

本文为我学习《乔新亮的CTO成长复盘》的学习总结，强烈推荐订阅该专栏学习。

0我被老乔洗脑了

近段时间，我订阅了老乔的《乔新亮的CTO成长复盘》课程，一读起来就一发不可收拾。老乔信奉“沟通创造价值，分享带来快乐”，他把自己的成长经验复盘为三个部分：个人认知复盘、管理工作复盘 以及 专业成长复盘，这些认知经验有的我可以快速地应用到自己的工作中，有的则需要长期消化常读常新。

我不得不说，这是一门目前在某客时间对我的认知提高最大的一门课程，专栏的很多内容都拔高了我的认知高度，引发了我对过往经历的很多思考，自认为它会对我以后的工作和生活产生很多积极的影响。

老乔认为，“认知到位+彪悍执行=成功交付”，那么哪些关键认知需要到位，如何才能彪悍执行呢？我整理了一些我的学习总结（并非全部）分享与你。

1个人认知

对职业生涯的规划

对于大部分IT技术人的职业发展，可以笼统地分为三个阶段：

• 做事（Do）
• 带团队（Manage）
• 业务决策（Lead）

老乔建议：每五年要上一个新台阶！

Why？

因为没有迈上新台阶，往往意味着个人成长的停滞。也不绝对是五年，但如果太慢了，年龄会成为成长的最大障碍。

那么，登上新台阶的时机和方法是什么？

• 时机：当你开始闲下来、成长停滞的时候。
• 方法：多安排时间学习，找到一个好的导师多沟通。

最后，对我们有什么启发？

成长、登上新台阶、再成长，这一循环是我们做许多决策的出发点！

工作和薪资的关系

薪资只是工资的附属，工作的真正报酬是成长。

所谓的涨薪，不代表你的工作岗位更值钱了，而是你的个人能力足以匹配更值钱的岗位。

成功总是存在运气成分，但学习成功的经验则不需要运气。

为了践行正确的认知，我们可以 “无所不用其极”。

看透问题的本质

看透问题本质的关键点：

• 大胆假设，小心求证
• 刻意练习自己的思辨能力
• 相信所有的问题都可以被解决，如果不能解决，那一定是自己认知没到位

看透问题本质的修炼之道：感受、思考、总结、验证、坚持。

最难的是：坚持。

大学毕业要不要留在一线城市？

基本思路：无论在哪，能过得开心真的很重要。

隐藏建议：人一定要在认知上将自己解脱出来。因为，辛苦是相对而言的，身体累不可怕，心累才可怕。

结论启发：如果选择留在一线城市，不要单纯为了钱，而要为了成长。

工作中遇到问题如何有效提问？

基本前提：将时间线拉长，站在整个人生的高度上，用宏观视角看待当下。

结论启发：基础的问题自己解决，有难度的问题思考后解决，用为知识付费的态度来请人吃饭。

选择决定上限，努力决定下限

努力和选择是相辅相成的：

• 选择不只决定了上限，还要拥抱不确定性。
• 努力不但会决定下限，还要负责将”不确定性”变成”确定性”。

“做选择 -> 努力 -> 再做选择”的循环

选择需要勇气，而勇气的来源是努力：

• 做选择的预期是好的，但结果是不确定的。
• 必须努力将这种”不确定性”变成”确定”，别无他法。

2管理工作

管理者最重要的“三板斧_”_

老乔将企业的IT能力体系抽象成了如下图所示的一个飞轮：

遵循“少即是多”的做减法，他将企业IT管理者最重要的任务只保留了三个，它们分别是：

（1）组织调整到位

从传统IT架构的职能型研发组织调整为面向产品型研发组织是当今互联网时代各个企业IT部门的转型趋势，只有构建面向产品的组织架构，才能：

• 各职能人员形成了一个整体，被赋予共同的文化价值观，为共同的目标去奋斗；
• 技术团队应和业务、运营团队紧密合作，为自己的产品负责；
• 管理者可以能够通过一套统一的绩效体系，去考核不同岗位的团队成员。

但是，并非所有企业都要做组织架构的调整，如果技术挑战较大，建议先选择职能型研发组织。而如果技术挑战所剩不多，建议尽快转为产品型研发组织。

（2）加强组织协同效率

首先，什么是协同？

协同，就是让所有人向着同一个目标狂奔，并妥善解决奔跑过程中的合作问题。

其次，如何加强协同？

有两个关键指标，第一个是目标聚焦，第二个是顺畅合作。

那么，什么是目标聚焦？

关于目标聚焦，可以分为 表象、本质 和 实践。

表象在于认知与工具层面，这就需要培养团队具有全局思维的认知，也需要一些具体的协同手段来落地，比如：

• 沟通协同：钉钉、企业微信…
• 日历协同：全员日历、会议公开…
• 文档协同：石墨文档、腾讯文档…
• 目标协同：OKR上下目标对其…

本质在于团队文化层面，这就需要打造一个极度透明 和 互相信任的文化，因为，越透明，团队所有人的思想就越容易对其，协同效率自然也更高。

在实践中则体现为问题必须提前暴露，比如规定问题必须暴露，不许隐瞒，有问题不上报，发现后处罚，又比如允许犯错、试错，不以指标决定绩效评分，最终以复盘情况定绩效，这是管理者的金刚之怒和菩萨慈悲的两面。

（3）激发团队活力

激发团队活力，我们可以做哪些事？

第一件事，寻找同路人。

• 原因：如果找不到，管理者会陷入很多负面的管理细节中。
• 认知：管理是为了不管，管理的目的是为了将不那么能自我驱动的人，变得更主动、更积极，而不是当个监工。
• 实践：先管，向管理要效益；然后慢慢不管，团队自律、自驱，管理逐步达到无为状态。

第二件事，赋予团队使命。

这就需要管理者打开考评与晋升通道。

第三件事，管理游戏化。

这就需要管理者将管理游戏化，给团队频繁的正向激励，发现每个人的优点。

全局思维和持续完善体系

关于全局思维，如何理解？

（1）站在更高的维度，将技术视角和业务视角统一起来。

（2）用业务增长的思维看待技术建设。

那么，如何培养全局思维？

• 首先，在时间维度，遇事不要只看当下得失，要学会站在未来半年、一年甚至三年的维度看得失。
• 其次，在空间维度，不要只站在自己的视角看问题，要时常做好身份转换。

最后，我们也需要持续完善体系。

在全局视角下，用更短的周期、更快的速度持续完善。这时，组织能力也会随着时间，不断登上新的台阶。

3专业成长

架构决策

对于技术人来说，为何要做好架构决策？

• 决策失误 是 “技术债” 的主要来源；俗话说，一将无能，累死三军。
• 选择“不作为”往往更加可怕；这是因为一把手是团队的天花板，并为团队的所有问题负责。

对于技术人来说，又如何才能做好架构决策？

在道的层面，就是思维与特质。

• 学会站在全局视角看待问题，学会看到技术架构的“外部价值”（比如 公司利润、人效、资源利用率等）。
• 具备相当的技术深度，以及非常好的学习能力和逻辑思维（换句话说，只要你能讲清楚，我就一定能掌握）。

在术的层面，就是流程与工具。

对于大公司而言，需要指定一个体系化的解决方案，比如设置架构决策流程 和 决策模板，目的是培养所有人的大局观和决策力。

而对于小公司而言，可能就不需要流程，因为CTO的精力可以cover住。

但是，无论是流程还是表格，都不仅是一样工具，更是一种思维模式。

架构设计（整体认知与功能性架构）

对于架构设计，一个最核心的认知：

好的架构设计，就像优秀的组织协作一样，既能帮助 IT 系统做好各模块的专业分工*，又能体现模块间的协作精神*。

抽象地看，架构是由元素（element）和关系（relationship）组成的：

• 稳定、可复用的部分应该变成组件或应用模块，应对「元素」；
• 不确定性的设计则需要变成协作方式，为可能的扩展做准备，应对「关系」；

对于架构师来说，其最核心的能力应该是：对架构层面的「专业分工」和「**协作精神*」的理解，这包括了：

• 对复杂业务的拆分能力；
• 对可复用部分的抽象能力；
• 对拆分过程的颗粒度把握；
• 对未来变化的考量和设计；

对于架构师来说，复杂的架构设计如何落地？

关键认知在于，整个世界都可以按照确定性内容和不确定性的内容做简单区分。

首先，将架构抽象为元素和关系：

• 元素应对着确定性内容的处理，属于看待世界的稳定视角；
• 关系应对着不确定性内容的处理，属于看待世界的响应视角；

其次，解决两个问题：元素的建设问题 和 关系的建设问题。

针对元素的建设问题：

• 人类的理解能力有限，如果内容的元素过多，则需要进行拆分；
• 将元素归类的时候，也不能贪多，不然也会导致理解困难；

针对关系的建设问题：

• 稳定的关系，用来表达确定性的交互，使用SOA（面向服务）架构；
• 不稳定的关系，用来表达不确定性的交互，使用EDA（事件驱动）架构；

最后，架构师还需要接入产品经理和程序员的沟通中，判断需求是否大幅度增加了某些组件的复杂度，并决定是否调整组件职责，或对现有组件进行拆分。

架构设计（非功能性架构）

所谓非功能性架构设计，一般都是指 高可用、高性能 和 高可扩展性 的设计。

关于高可用设计

真正的高可用，是指实现所有元素、所有连接的高可用。其目的是保证“业务的连续性”，因为在用户眼里业务永远是正常（或基本正常）对外提供服务的。

高可用不等于高可靠，高可用需要有很多trade-off（权衡）。

通用的做法：“冗余设计”，集群 or 分布式 or ……

现实情况下，很多时候对于初创公司是没有足够的钱做100%的高可用设计的，那么此时需要明确一个方针和两个方法。

• 一个方针：优先保证高可用，其次保证高可靠。
• 两个方法：降级服务 与 熔断服务。

关于高性能设计

高性能设计的两大核心步骤：

• 清晰描述、定义性能目标；
• • 系统响应时间（一般指服务 / 交易处理的时间，也包括网络响应时间。）
  • 系统吞吐量（一般指服务 / 交易处理的时间，也包括网络响应时间。）
  • 系统容量（一般指服务 / 交易处理的时间，也包括网络响应时间。）
• 设计并实现这个目标；

高性能设计需要围绕着契约精神：

• 高性能设计非常看重系统响应时间的一致性，尤其是在不同的服务阶段，并发量和吞吐量发生变化的时候；
• 要做高性能设计，一定要明确目标，并交付给用户；

实现高性能设计的关键技术点：

• 为架构做好“保护系统”（为应对容量规划外的过载而设计的，通过流量控制来具体实现）；
• 使架构具有扩容能力（储备额外的计算资源，提升弹性扩容的速度）；
• 提升系统各组件处理能力（识别高并发情境中的资源争抢情况，同时注意保留架构的可扩展性）；

关于高可扩展性设计

扩展性设计是为了支撑业务快速发展而出现的概念，其目的是保证企业在发展的不同时期，业务上线所需的研发时间不会大幅增加。

要做好扩展性设计，需要在四个层面进行设计：

（1）从业务发展出发，保证企业级年度/季度业务发展目标实现聚焦；

（2）从企业产品出发，用业务目标指导产品建设；

（3）企业级应用架构设计层面，做好交易体系、协同体系、监控指挥体系 和 生产体系 四个方面的建设；

（4）企业级技术架构设计层面，对于高度定制化的核心系统进行自研，对非核心系统可以采取购买相应的套件或云服务，不重复造轮子。

一句话总结扩展性设计：真正优秀的扩展性设计，建立在看透业务本质的基础上，面向不确定性，但要从不确定性中寻找确定性。

4总结

对于一个30+的技术人来说，已经是高级或资深研发工程师的我们，持续提升技术固然很重要，但是提升个人认知也很重要。只有关键认知到位，才有可能触碰到目前个人能力的边界，也只有达到边界才有可能突破边界，从而迈上一个新的台阶。很幸运，在这个阶段我能够从老乔这样的CTO身上学到他的关键认知和经验，我觉得这些认知用几十块钱的课程费简直就是赚翻了，因此，我也诚心地把它推荐给各位童鞋，一起提升认知，终身成长！

参考资料

乔新亮，《乔新亮的CTO成长复盘》