mirror of
https://github.com/cheetahlou/CategoryResourceRepost.git
synced 2025-10-15 06:23:44 +08:00
182 lines
14 KiB
Markdown
182 lines
14 KiB
Markdown
<audio id="audio" title="05 | COMD能力模型：怎么把抽象的能力要求具体化？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/f1/41/f179b946d3e4fc9fcdef35a7ea0eeb41.mp3"></audio>
|
||
|
||
你好，我是华仔。
|
||
|
||
上一讲我分享了两条晋升逻辑和一套通用的晋升步骤。现在你已经知道，要先把当前级别要求的能力提升到精通程度，然后尝试做下一级别的事情。
|
||
|
||
不过在这个过程中，你还会遇到另一个麻烦，那就是不确定下一级别的能力要求到底是怎样的，所以你也不知道究竟要准备到什么程度。
|
||
|
||
举个最常见的例子，不同级别有不同的Title（头衔），比如“工程师”“高级工程师”和“专家工程师”等。但是，这样的 Title 对我们理解不同级别的能力要求，是完全没有什么用处的。“高级工程师”到底“高级”在哪，可能每个人的理解都不一样。
|
||
|
||
## 公司统一的能力描述：抽象
|
||
|
||
为了指导员工晋升，公司一般都会对各个级别的能力要求给出描述。但是因为细分的领域实在太多了，所以公司只能进行非常抽象的描述。
|
||
|
||
比如，P7的要求是“具备系统思考的能力，能够全面掌握某个技术领域”，而P8的要求是“具备前瞻判断的能力，能够规划技术领域的发展方向”。
|
||
|
||
从实际的效果来看，这样的描述**基本没什么效果**，绝大部分人看完还是一头雾水。在实际工作中，团队成员经常跟我反馈这样的困惑：
|
||
|
||
- 什么是**系统思考**能力？P7才要求系统思考，可是我P6的时候参与项目开发，就需要考虑需求的合理性、索引设计高性能、接口的兼容性和易用性、上线的灰度方案这么多事情，这些难道不是系统思考吗？
|
||
- 什么是**前瞻判断**能力？P6要预测需求变化，P7要规划团队技术发展，这些也是前瞻判断呀，为什么P8要特别强调前瞻判断？
|
||
|
||
可以说，晋升疑惑千千万，能力要求占一半。这一讲我要介绍的就是把抽象要求具体化的方法。
|
||
|
||
## 领域定制的能力解读：比较具体
|
||
|
||
因为公司的抽象描述很难指导实际工作，所以有些领域会独立定制自己的职级能力解读，一般是由P8或P9级别的员工以工作组的方式讨论得出来的。
|
||
|
||
比如“Java业务开发”这个领域，P6和P7级别的能力解读长什么样呢？你可以参考下面的表格。
|
||
|
||
（注：这张表格仅供参考。它不是完整的解读，不代表所有公司的实际要求。你也不需要看懂里面的所有内容，只要了解这个形式就可以了。）
|
||
|
||
<img src="https://static001.geekbang.org/resource/image/06/b7/0653e9a2yy8b3660d402fd70031190b7.jpg" alt="">
|
||
|
||
我们可以看到，这份标准跟公司的描述相比，已经具体很多了。如果按照这个思路，完整地把各个级别要求的能力一一列出来，不但可以作为晋升的标准，也可以作为学习的参考。
|
||
|
||
其实这种做法对员工是有利的，因为标准越明确，就越容易“照本宣科”地去做。但是从公司的角度来看，这种做法存在成本太高（有几十上百个专业领域要制定详细标准，每年都要更新）、限制创新（大家都只管对照公司标准来做事，其它一概不管）等问题，所以很少有公司会这么做。
|
||
|
||
## COMD能力模型：4种复杂度+3个维度
|
||
|
||
为了彻底解决要求不明确的问题，让你更好地理解不同职级的能力差异，我根据自己的思考和担任晋升评委的经验，提炼出了一套兼容性很强又容易理解的能力模型：**面向复杂度的多维度能力模型**（Complexity-Oriented & Multi-Dimension Capability Model），简称**COMD能力模型**。
|
||
|
||
COMD的CO是指Complexity-Oriented，意思是“面向复杂度”（灵感来源于“面向对象”）；MD是指Multi-dimension，意思是“多维度”，也就是技术、业务和管理3个维度。
|
||
|
||
COMD的核心指导思想是，**通过事情的复杂度来判断能力的高低**，级别越高，所做的事情复杂度也越高。
|
||
|
||
当然，如果只是单纯地用复杂度来判断能力高低，那么它本质上和其他方法也没什么不同，看不懂的地方还是看不懂，不同的人理解还是不同。
|
||
|
||
所以，为了清晰地描述不同能力层级的差异，COMD能力模型还进一步地明确了复杂度，具体包括规模复杂度、时间复杂度、环境复杂度和创新复杂度4种类型。
|
||
|
||
### 1. 规模复杂度
|
||
|
||
规模复杂度是指和规模大小有关的复杂度。
|
||
|
||
规模越大，复杂度越高。原因在于规模越大，节点越多，节点间的关系越复杂，而且节点间的关系复杂度是指数增长的。就像下面的图片所展示的：当节点数只有3个时，节点间的关系也只有3个；而节点数达到6个时，节点间的关系就变成了15个，复杂度提升了5倍。
|
||
|
||
<img src="https://static001.geekbang.org/resource/image/ea/59/eayyd87a3cf233299b58bb632e68a959.jpg" alt="">
|
||
|
||
按照这个原理，我们可以对一些常见工作维度的规模复杂度进行比较，具体如下表所示。
|
||
|
||
<img src="https://static001.geekbang.org/resource/image/a3/0c/a3d429b12fb94f239f6fac84376cb10c.jpg" alt="">
|
||
|
||
当然，以上对比的前提是，除了规模之外，其他条件都差不多。（对比其他几个复杂度时也是这样）。就像表格中200行代码和2000行代码对比，前提是代码复杂度是差不多的。因为200行核心代码的复杂度，显然比2000行拷贝粘贴的代码要高。
|
||
|
||
### 2. 时间复杂度
|
||
|
||
时间复杂度是指和时间跨度有关的复杂度。
|
||
|
||
时间跨度越长，复杂度越高。原因在于万事万物都处于不断发展变化当中，时间跨度越长，变化的因素和可能方向越多，越难判断准确。
|
||
|
||
三大维度的时间复杂度的对比举例如下表所示。
|
||
|
||
<img src="https://static001.geekbang.org/resource/image/c7/95/c742fb1d759eccccf5d2489f7be5bf95.jpg" alt="">
|
||
|
||
### 3. 环境复杂度
|
||
|
||
环境复杂度是指和环境不确定性有关的复杂度。
|
||
|
||
我们很多的判断、决策和行为都依赖于对环境的认知和反应。总的来说，环境不确定性越高，复杂度越高。
|
||
|
||
环境的不确定性具体分为环境的稳定性、环境的透明性和环境的可预见性3个方面：
|
||
|
||
- 环境的稳定性，指环境变化的速度快慢。
|
||
- 环境的透明性，指是否能够明确地获取环境相关的信息。
|
||
- 环境的可预见性，指是否会发生完全无法预料的黑天鹅事件。
|
||
|
||
环境的稳定性、透明性和可预见性越低，它的不确定性就越高，复杂度也越高。
|
||
|
||
下面这个表格从宏观的角度分析了技术、管理和业务三个维度所面临的环境不确定性。
|
||
|
||
<img src="https://static001.geekbang.org/resource/image/b5/9e/b501ac73ffe078e0674d72f17d85b49e.jpg" alt="">
|
||
|
||
从表格中可以看出，对于互联网行业的业务来说，环境稳定性、透明性和可预见性都比较低，所以它的环境复杂度是最高的。这也是在互联网大厂，大部分P9/P10都需要把很多时间和精力投入到业务上的主要原因。
|
||
|
||
### 4. 创新复杂度
|
||
|
||
创新复杂度是指和创新程度有关的复杂度。
|
||
|
||
常见的创新包括理论的创新、思想（或者说方法）的创新和技巧的创新。理论创新的复杂度要高于思想创新，而思想创新的复杂度又高于技巧创新。
|
||
|
||
以高可用技术领域为例：
|
||
|
||
- FLP原理和CAP定理属于**理论创新**。它们奠定了分布式高可用设计的基础和边界，无论是缓存系统、存储系统、批处理系统、流式处理系统还是采用微服务架构的业务系统等，都不能跳出这两个理论的约束和限制。
|
||
- 批处理和流处理属于**思想创新**。对于大数据技术来说，一开始Google提出的批处理思路开启了大数据时代，而后来Storm开启了流处理这个新的技术领域。
|
||
- 实现Exactly Once特性属于**技巧创新**。开源框架Flink使用Chandy-Lamport 算法，实现了流处理Exactly Once的特性，能够实现消息精确投递，避免重复消息导致业务出错。
|
||
|
||
我们可以看到，创新复杂度越高，影响的范围往往也越大。理论创新会奠定整个行业的基础，而思想创新可能开辟一个新的技术领域。
|
||
|
||
另外，创新并不意味着一定要全球首创，只要相比团队当前现状来说有改进就行了；创新也不局限于技术领域，管理和业务一样可以创新。所以，下面这些事情都可以算是创新：
|
||
|
||
1. 开发Memcache
|
||
1. 有了Memcache后开发Redis
|
||
1. 引入设计模式优化代码
|
||
1. 使用微服务来拆分系统
|
||
1. 优化项目流程
|
||
1. 提出一种新的业务模式
|
||
|
||
各领域的部分典型创新案例如下表所示，你可以参考对照。
|
||
|
||
<img src="https://static001.geekbang.org/resource/image/5c/68/5cae1a8ed6d5ba85179d313a583de368.jpg" alt="">
|
||
|
||
除了刚才说的这4种通用的复杂度之外，在每个领域内部，也会有一些工作的复杂度本身就要比另一些工作高。
|
||
|
||
比方说在软件开发领域，我们一般认为各项工作的复杂度排序是这样的：
|
||
|
||
$$从0到1创造系统 > 架构重构 > 项目方案设计 > 编码实现$$
|
||
|
||
不过这些认知是领域经验总结形成的共识，并不能通用。所以在使用COMD模型的时候，你还是需要结合领域经验综合判断。
|
||
|
||
## COMD与抽象描述的对比
|
||
|
||
我想，你现在应该知道为什么公司写的那些抽象描述让人看不懂了。跟COMD能力模型的具体拆解比起来，它们只是脱离实际的文字游戏罢了。我就拿这一讲开头提出的“系统思考”和“前瞻判断”来说好了。
|
||
|
||
### 系统思考
|
||
|
||
比如在某些大厂，“系统思考”的确是写在P7级别的能力描述里，但它不是P7级别才有的能力特征。实际上，P6以上的级别都要求“系统思考”，区别只是**思考的范围**不同，也就是**规模复杂度**不同而已。
|
||
|
||
以B2C电商业务开发为例，在某些大厂，不同级别“系统思考”的范围如下图所示：
|
||
|
||
<img src="https://static001.geekbang.org/resource/image/25/76/256f46afaff6edb59ba7b1bf4ee47f76.jpg" alt="">
|
||
|
||
- 对于P6来说，系统思考的范围是某个**需求**，需要考虑需求的合理性、设计的可扩展性和上线后的稳定性等问题。
|
||
- 对于P7来说，系统思考的范围是单个**系统**，需要考虑的是单个系统的架构设计、架构重构和技术选型等问题。
|
||
- 对于P8来说，系统思考的范围是某个**领域**，需要考虑的是领域的发展趋势、架构演进、团队组织结构等问题。
|
||
- 对于P9来说，系统思考的范围是多个关联的业务域组成的**业务线**，需要考虑业务发展趋势、架构演进、团队组织结构等问题。
|
||
|
||
### 前瞻判断
|
||
|
||
同样地，在某些大厂，“前瞻判断”虽然写在了P8的能力描述里，但其实P6以上都有前瞻性的要求，区别只是在于前瞻范围、时间跨度和面临的环境不同而已。这些因素就分别对应了规模复杂度、时间复杂度和环境复杂度。
|
||
|
||
同样以B2C电商业务开发为例，某些大厂P6～P9级别的前瞻性要求如下表所示：
|
||
|
||
<img src="https://static001.geekbang.org/resource/image/79/a7/7901c8dc04db3d0edef3003eba2e06a7.jpg" alt="">
|
||
|
||
所以说，如果你还在绞尽脑汁地钻研“为什么P7才提出系统思考”以及“P8要求的前瞻判断有什么深意”这样的问题，那就掉到文字陷阱的坑里去了，白白浪费脑细胞。至于怎么从坑里走出来呢？这就需要灵活应用COMD能力模型了。
|
||
|
||
## 如何应用COMD
|
||
|
||
当你想要了解某个级别的能力要求的时候，不要再对着那些抽象和模糊的词语，不着边际地猜测和想象了。你应该静下心，坐下来填一个“能力矩阵”的表格，把每一项的要求都完整且具体地列出来。比如下面这个“能力矩阵”表格就摘录了P6级别的部分要求，可以作为参考。
|
||
|
||
<img src="https://static001.geekbang.org/resource/image/b1/72/b10dcec32eb291c464da50636c2c3572.jpg" alt="">
|
||
|
||
如果表格里有些内容你填不出来，说明你对这个级别的理解还不到位。不过没有关系，我会在课程的第二部分，也就是职级详解中给出每个级别通用的衡量标准。
|
||
|
||
在这个基础上，你可以请教你的主管、HR和同事等人，来完善和细化表格内容。当你详细地填完了这个表格，你也就对这个级别了解得很清楚了。接下来，你就可以对照表格，针对性地提升自己的能力。
|
||
|
||
## 小结
|
||
|
||
现在，我们回顾一下这一讲的主要内容。
|
||
|
||
1. 公司会对各个级别的能力要求给出一个抽象的描述，比如“系统思考”和“前瞻判断”等，但实际指导意义不大。
|
||
1. 有些领域可能会独立定制相关技术方向的能力解读。虽然这种解读比公司的抽象描述稍微具体一些，但因为投入成本太大和限制创新等原因，很难大范围推广。
|
||
1. 我总结的COMD能力模型，把能力分成技术、管理和业务三个维度，并通过规模、时间、环境和创新四个复杂度来判断能力的高低。
|
||
1. 如果你想了解某个级别的能力要求，为晋升做准备，可以把这个级别的能力模型表格列出来，然后针对表格内容做针对性的提升。
|
||
|
||
## 思考题
|
||
|
||
这就是今天的全部内容，最后留一道课后思考题给你吧。记得有一次，团队成员跟我探讨职级的时候，问了我一个问题：“为什么说P6是独当一面，难道P7、P8和P9没有独当一面的要求吗？”学了COMD能力模型之后，你会怎么回答这个问题呢？
|
||
|
||
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。
|
||
|
||
<img src="https://static001.geekbang.org/resource/image/83/96/83211d404c6701c8791c59df4170bb96.jpeg" alt="">
|