## 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 倍。 [图片：节点数与节点关系示意图] 按照这个原理，我们可以对一些常见工作维度的规模复杂度进行比较，具体如下表所示。 [图片：规模复杂度对比表格] 当然，以上对比的前提是，除了规模之外，其他条件都差不多。（对比其他几个复杂度时也是这样）。就像表格中 200 行代码和 2000 行代码对比，前提是代码复杂度是差不多的。因为 200 行核心代码的复杂度，显然比 2000 行拷贝粘贴的代码要高。 ### 2. 时间复杂度 时间复杂度是指和时间跨度有关的复杂度。 时间跨度越长，复杂度越高。原因在于万事万物都处于不断发展变化当中，时间跨度越长，变化的因素和可能方向越多，越难判断准确。 三大维度的时间复杂度的对比举例如下表所示。 [图片：时间复杂度对比表格] ### 3. 环境复杂度 环境复杂度是指和环境不确定性有关的复杂度。 我们很多的判断、决策和行为都依赖于对环境的认知和反应。总的来说，环境不确定性越高，复杂度越高。 环境的不确定性具体分为环境的稳定性、环境的透明性和环境的可预见性 3 个方面： - 环境的稳定性，指环境变化的速度快慢。 - 环境的透明性，指是否能够明确地获取环境相关的信息。 - 环境的可预见性，指是否会发生完全无法预料的黑天鹅事件。 环境的稳定性、透明性和可预见性越低，它的不确定性就越高，复杂度也越高。 下面这个表格从宏观的角度分析了技术、管理和业务三个维度所面临的环境不确定性。 [图片：环境复杂度对比表格] 从表格中可以看出，对于互联网行业的业务来说，环境稳定性、透明性和可预见性都比较低，所以它的环境复杂度是最高的。这也是在互联网大厂，大部分 P9/P10 都需要把很多时间和精力投入到业务上的主要原因。 ### 4. 创新复杂度 创新复杂度是指和创新程度有关的复杂度。 常见的创新包括理论的创新、思想（或者说方法）的创新和技巧的创新。理论创新的复杂度要高于思想创新，而思想创新的复杂度又高于技巧创新。 以高可用技术领域为例： - FLP 原理和 CAP 定理属于**理论创新**。它们奠定了分布式高可用设计的基础和边界，无论是缓存系统、存储系统、批处理系统、流式处理系统还是采用微服务架构的业务系统等，都不能跳出这两个理论的约束和限制。 - 批处理和流处理属于**思想创新**。对于大数据技术来说，一开始 Google 提出的批处理思路开启了大数据时代，而后来 Storm 开启了流处理这个新的技术领域。 - 实现 Exactly Once 特性属于**技巧创新**。开源框架 Flink 使用 Chandy-Lamport 算法，实现了流处理 Exactly Once 的特性，能够实现消息精确投递，避免重复消息导致业务出错。 我们可以看到，创新复杂度越高，影响的范围往往也越大。理论创新会奠定整个行业的基础，而思想创新可能开辟一个新的技术领域。 另外，创新并不意味着一定要全球首创，只要相比团队当前现状来说有改进就行了；创新也不局限于技术领域，管理和业务一样可以创新。所以，下面这些事情都可以算是创新： - 开发 Memcache - 有了 Memcache 后开发 Redis - 引入设计模式优化代码 - 使用微服务来拆分系统 - 优化项目流程 - 提出一种新的业务模式 三个维度的部分典型创新案例如下表所示，你可以参考对照。 [图片：三大维度创新示例表格] 除了刚才说的这 4 种通用的复杂度之外，在每个领域内部，也会有一些工作的复杂度本身就要比另一些工作高。 比方说在软件开发领域，我们一般认为各项工作的复杂度排序是这样的： 从 0 到 1 创造系统 > 架构重构 > 项目方案设计 > 编码实现 不过这些认知是领域经验总结形成的共识，并不能通用。所以在使用 COMD 模型的时候，你还是需要结合领域经验综合判断。