要先把当前级别要求的能力提升到精通，然后尝试做下一级别的事情。

但可能不确定高一级的能力要求究竟怎样，不同Title，如“工程师”“高级工程师”和“资深工程师”等。但这样 Title 对我们理解不同级别的能力要求，完全无用。“高级工程师”到底“高级”在哪？

1 公司统一的能力描述：抽象

为指导员工晋升，公司会对各级能力要求给出描述。但因细分的领域太多，公司只能进行抽象描述。如：

  • P7要求，“具备系统思考能力，能全面掌握某技术领域”
  • P8要求，“具备前瞻判断的能力，能够规划技术领域的发展方向”

从实际效果看，这样的描述无效，还是不懂在说啥。我们经常困惑：

  • 什么是系统思考能力？P7才要求系统思考，可我P6时参与项目开发，就要考虑需求合理性、索引设计高性能、接口兼容性和易用性、上线的灰度方案这么多事情，这些难道不是系统思考？
  • 什么是前瞻判断能力？P6要预测需求变化，P7要规划团队技术发展，这些也是前瞻判断呀，为何P8强调前瞻判断？

晋升疑惑千千万，能力要求占一半。

2 领域定制的能力解读：比较具体

因为公司的抽象描述很难指导实际工作，有些领域会独立定制自己的职级能力解读，一般由P8或P9级以工作组的方式讨论得出。

如“Java业务开发”领域，P6、P7能力解读参考：

跟公司的描述相比，具体很多。按此思路，完整把各级要求能力列出，不但可作为晋升标准，也可作为学习参考。

这种做法对员工有利，标准越明确，越容易“照本宣科”去做。但公司角度，这成本太高（有几十上百个专业领域要制定详细标准，每年都要更新）、限制创新（大家就只管对照公司标准来做事，其它一概不管）等问题，所以没有公司这么做。

3 COMD能力模型

为彻底解决要求不明确，更好理解不同职级能力差异，整理一套兼容性强、易理解的能力模型：面向复杂度的多维度能力模型（Complexity-Oriented & Multi-Dimension Capability Model），COMD能力模型。

核心指导思想是，通过事情的复杂度来判断能力的高低，级别越高，所做的事复杂度越高。

只是单纯用复杂度判断能力高低，那它本质和其他方法没啥不同，看不懂的地方还是看不懂，不同的人理解还是不同。所以，为清晰描述不同能力层级的差异，COMD能力模型还进一步明确复杂度，包括规模复杂度、时间复杂度、环境复杂度和创新复杂度。

3.1 规模复杂度

规模越大，节点越多，节点间的关系越复杂，而且节点间的关系复杂度是指数增长的。

就可对一些常见工作维度的规模复杂度进行比较：

以上对比前提是，除了规模，其他条件差不多。200行代码和2000行代码对比，前提是代码复杂度差不多。因为200行核心代码的复杂度，显然比2000行拷贝粘贴的代码高。

3.2 时间复杂度

时间跨度越长，复杂度越高。原因在于万事万物都处于不断发展变化当中，时间跨度越长，变化的因素和可能方向越多，越难判断准确。

三大维度的时间复杂度的对比：

3.3 环境复杂度

和环境不确定性有关的复杂度。

我们很多的判断、决策和行为都依赖于对环境的认知和反应。总的来说，环境不确定性越高，复杂度越高。

环境的不确定性具体分为环境的稳定性、环境的透明性和环境的可预见性3个方面：

  • 环境的稳定性，指环境变化的速度快慢。
  • 环境的透明性，指是否能够明确地获取环境相关的信息。
  • 环境的可预见性，指是否会发生完全无法预料的黑天鹅事件。

环境的稳定性、透明性和可预见性越低，它的不确定性就越高，复杂度也越高。

宏观分析技术、管理和业务三个维度所面临的环境不确定性：

对互联网行业业务，环境稳定性、透明性和可预见性都较低，所以环境复杂度最高。这也是在互联网大厂，大部分P9/P10都需要把很多时间和精力投入到业务上的主要原因。

3.4 创新复杂度

常见创新包括理论创新、思想（或方法）创新和技巧创新。

理论创新复杂度>思想创新复杂度>技巧创新复杂度。

高可用技术领域

  • FLP原理、CAP定理是理论创新。它们奠定分布式高可用设计的基础和边界，无论是缓存系统、存储系统、批处理系统、流式处理系统还是采用微服务架构的业务系统等，都不能跳出这两个理论的约束和限制
  • 批处理和流处理属于思想创新。对于大数据技术来说，一开始Google提出的批处理思路开启了大数据时代，而后来Storm开启了流处理这个新的技术领域
  • 实现Exactly Once特性属于技巧创新。开源框架Flink使用Chandy-Lamport 算法，实现了流处理Exactly Once的特性，能够实现消息精确投递，避免重复消息导致业务出错

创新复杂度越高，影响的范围往往也越大。理论创新会奠定整个行业的基础，而思想创新可能开辟一个新技术领域。

创新并不意味着一定要全球首创，只要相比团队当前现状来说有改进就行了；创新也不局限于技术领域，管理和业务一样可以创新。所以，下面这些事情都可以算是创新：

  1. 开发Memcache
  2. 有Memcache后，开发Redis
  3. 引入设计模式，优化代码
  4. 使用微服务拆分系统
  5. 优化项目流程
  6. 提出新业务模式

各领域的部分典型创新案例：

除了刚才说的这4种通用的复杂度之外，在每个领域内部，也会有一些工作的复杂度本身就要比另一些工作高。

比方说在软件开发领域，我们一般认为各项工作的复杂度排序是这样的：

从0到1创造系统>架构重构>项目方案设计>编码实现从0到1创造系统 > 架构重构 > 项目方案设计 > 编码实现 从0到1创造系统>架构重构>项目方案设计>编码实现

不过这些认知是领域经验总结形成的共识，并不能通用。所以在使用COMD模型的时候，你还是需要结合领域经验综合判断。

4 COMD与抽象描述的对比

公司写的那些抽象描述跟COMD能力模型的具体拆解比起来，只是脱离实际的文字游戏。

4.1 系统思考

某大厂，“系统思考”的确写在P7级能力描述，但它不是P7才有的能力特征。P6以上都要求“系统思考”，只是思考范围不同，即规模复杂度不同。

以B2C电商业务开发为例，在某些大厂，不同级别“系统思考”范围：

  • P6，系统思考范围是某个需求，考虑需求合理性、设计可扩展性和上线后的稳定性
  • P7，范围是单个系统，考虑单个系统的架构设计、架构重构和技术选型
  • P8，范围是某领域，考虑领域的发展趋势、架构演进、团队组织结构
  • P9，系统思考的范围是多个关联的业务域组成的业务线，考虑业务发展趋势、架构演进、团队组织结构

4.2 前瞻判断

某些大厂，“前瞻判断”虽写在P8描述，但P6以上都有前瞻性要求，只是前瞻范围、时间跨度和面临的环境不同，分别对应规模复杂度、时间复杂度和环境复杂度。

B2C电商为例，某些大厂P6～P9前瞻性要求：

若你还苦逼钻研“为何P7才提出系统思考”、“P8要求的前瞻判断有啥深意”，就会掉入文字陷阱，白费脑细胞。从坑里走出，要灵活应用COMD能力模型。

5 应用COMD

当你想要了解某个级别的能力要求，不要再对那些抽象和模糊的词语，不着边际猜测和想象。

静下心，坐下来填“能力矩阵”表格，把每项要求完整且具体列出。如下摘录P6部分要求，可参考：

若表格有些内容填不出来，说明你对这级别理解不到位。

在这基础上，可请教你的主管、HR和同事等人，完善、细化表格。详细填完表格，就对级别很清楚了，后续针对性提升能力。

6 总结

  1. 公司会对各个级别的能力要求给出一个抽象的描述，比如“系统思考”和“前瞻判断”等，但实际指导意义不大。
  2. 有些领域可能会独立定制相关技术方向的能力解读。虽然这种解读比公司的抽象描述稍微具体一些，但因为投入成本太大和限制创新等原因，很难大范围推广。
  3. 我总结的COMD能力模型，把能力分成技术、管理和业务三个维度，并通过规模、时间、环境和创新四个复杂度来判断能力的高低。
  4. 如果你想了解某个级别的能力要求，为晋升做准备，可以把这个级别的能力模型表格列出来，然后针对表格内容做针对性的提升。

FAQ

“为什么说P6是独当一面，难道P7、P8和P9没有独当一面的要求吗？”

独当一面的“面积”不一样，P6的面积是15寸笔记本屏幕大小，P7的面积是32寸液晶显示器大小，P8的面积是65寸高清显示器大小，P9的面积是公司门口的大号液晶显示屏。

单维度内：把基本的事情做对，把难的事情做对
多维度内：把基本的事情做对，把难的事情做对
多维度间：把基本的事情做顺，把难的事情做顺
新维度时：把基本的事情理清，把难的事情理清

为清晰地描述不同能力层级的差异，COMD 能力模型还进一步地明确了复杂度，具体包括规模复杂度、时间复杂度、环境复杂度和创新复杂度 4 种类型。怎么想到按这几个维度来拆分的。很多时候对一件事情的理解无法深入就是不知道该怎么继续往下拆分，老师的能力模型一下子把模糊的评级能力要求拆解的特别清晰。特别想提升这方面的能力，可通过哪些方式锻炼？

如何衡量和考察技术人员的能力，对于一个复杂模糊问题，一下子看不到答案，可尝试拆分，按逻辑维度、流程维度、分类维度，COMD模型的3个维度其实就是分类拆分的，4个复杂度就是按逻辑来拆分。

如何提升这种能力，可能跟我看书多有关，例如人文社科心理学经济学管理学等，看多会潜移默化，无意学习一些方法。

中途转的JAVA，目前作为一个小组长，技术不行，管理上也在摸索，这种情况下，是偏向技术还是偏向管理比较好？P9以前都是专业为核心，管理是附加分。

直面自己和直属领导的差距！除了直面，更要学习别人的长处和厉害的地方。