技能分类体系是一套把组织所需能力逐层拆开的分类结构：先划分技能域，再落到具体技能项，并为每项设定等级与判定标准。它回答“我们用什么口径描述能力”。技能矩阵是这套结构在“人—技能”上的填表结果，用来查看谁具备哪项技能、到什么程度；岗位能力模型是这套结构在“岗—要求”上的映射结果，说明某个岗位需要哪些技能项、达到什么等级。三者共用同一套技能项与等级口径，分别承担定义、盘点和要求三种角色。
要点总览（TL;DR）
- 技能分类体系是把组织所需能力逐层拆开的分类结构，通常按技能域、技能项、等级三层组织，每档等级配可观察的判定标准。
- 技能矩阵是分类体系在“人—技能”上的填表结果，回答谁会什么、到什么程度；岗位能力模型是分类体系在“岗—要求”上的映射结果，回答岗位要什么、到什么等级。
- 三者共用同一套技能项与等级口径，才能直接比对出能力缺口；口径不一致会在人岗匹配和培养计划阶段集中暴露。
- 技能分类体系只覆盖工作配置所需能力，招聘考核、薪酬绩效制度与团队职责定义属于其他体系。
- 常见误解包括把技能矩阵当成分类体系、把岗位能力模型当成人员评估结果，以及认为等级档位越多越精细。
技能分类体系是什么：从技能域到技能项再到等级
技能分类体系是对组织工作所需能力进行结构化描述的分类框架。它的作用是把“能力”这个笼统说法拆成可以命名、可以对照、可以记录的具体条目，让不同团队在讨论人员能力时有共同语言。一套可用的分类体系通常包含三个层级，自上而下逐层细化。
第一层：技能域
技能域是对能力范围的粗分，划分依据通常是工作性质或专业方向。例如研发组织可以划分为后端开发、前端开发、测试、运维、数据、产品设计等域；制造企业可以划分为工艺、设备、质量、生产管理等域。技能域的数量不宜过多，一般控制在组织主要职能方向的数量级，目的是让人能快速定位“这项能力大概属于哪一类”。划分依据要稳定，避免同一能力在不同域之间反复出现。
第二层：技能项
技能项是技能域下的具体能力条目，是整套体系真正被引用的最小单位。例如“后端开发”域下可以列出 Java 服务开发、数据库设计与优化、接口设计与联调、性能调优等技能项。技能项的命名要求具体、可观察，避免使用“沟通能力强”“学习能力好”这类无法对应具体工作行为的表述。每个技能项应有明确的定义说明，写清它覆盖的工作内容和不覆盖的边界，减少不同人理解不一致。
第三层：等级与判定标准
等级描述某项技能从入门到精通的递进程度。常见做法是设三到五档，档位数量取决于组织对区分度的实际需要。每一档都要配判定标准，说明达到该档的人能独立完成什么、在什么条件下完成、需要多少指导。判定标准应写行为与结果，例如“能独立完成常规模块开发并通过评审”“能主导复杂模块设计并指导他人”，避免只写“熟练”“精通”这类主观形容词。等级描述是后续填写技能矩阵和岗位能力模型时保持口径一致的关键。
一个分层示例如下：技能域为“后端开发”，其下技能项包括“服务开发”“数据库设计”“接口联调”；以“服务开发”为例，等级可设为 L1 能在指导下完成简单接口、L2 能独立完成常规服务模块、L3 能主导复杂服务设计与技术方案评审。这套结构一旦确定，就成为组织内描述能力的公共字典。
边界：技能分类体系包括什么、不包括什么
技能分类体系的范围限定在工作配置所需的能力项与等级。它服务于“把合适的人放到合适的工作上”这一目的，因此只覆盖与工作任务直接相关的能力描述。超出这个范围的内容，即使与人员管理有关，也属于其他体系，不应塞进技能分类体系里。
| 范围 | 内容 | 说明 |
|---|---|---|
| 纳入 | 技能域、技能项、等级与判定标准 | 用于描述工作所需能力，是矩阵与岗位模型的共同口径 |
| 纳入 | 技能项的定义与适用范围说明 | 保证不同填写者对同一技能项理解一致 |
| 不纳入 | 招聘考核与面试评价标准 | 属于招聘选拔体系，技能项可作为参考输入，但考核方式、评分规则不在分类体系内 |
| 不纳入 | 薪酬与绩效制度 | 等级可作为薪酬带宽或绩效讨论的输入之一，但薪酬结构、绩效指标与评定流程属于独立制度 |
| 不纳入 | 团队职责与角色分工定义 | 归团队角色与职责分工主题，回答“谁负责什么”，与“谁会什么”是两个问题 |
还需要区分技能分类体系与任职资格、职级体系。任职资格通常描述某一职类在知识、技能、经验、成果等方面的综合要求，并常与职级晋升挂钩；职级体系则规定组织内的层级序列与晋升规则。技能分类体系只负责把能力拆成可引用的条目并设定等级，它不规定晋升条件，也不替代任职资格标准。把三者混在一起，容易导致技能项被写成晋升条款，失去作为能力字典的简洁性。
三者如何衔接：分类体系、技能矩阵与岗位能力模型的组成关系
三者的关系可以概括为：技能分类体系是底座，技能矩阵是人员侧视图，岗位能力模型是岗位侧视图。底座提供技能项和等级这两套公共口径，两个视图分别从“人”和“岗”两个方向引用同一套口径，从而可以相互对照。
技能矩阵的构成
技能矩阵以人员为行、技能项为列，单元格填写该人员在该技能项上的等级。它回答“谁会什么、到什么程度”，是盘点现状的工具。矩阵的列直接取自分类体系的技能项，单元格取值直接取自分类体系的等级，因此矩阵本身不产生新口径，只是把分类体系填上人员数据。
岗位能力模型的构成
岗位能力模型以岗位为对象，列出该岗位需要的技能项及要求等级。它回答“这个岗位要什么”，是定义要求的工具。模型中的技能项同样取自分类体系，要求等级同样使用分类体系的档位，因此岗位模型也不产生新口径，只是把分类体系映射到岗位上。
共用口径时的对齐方式
当矩阵和岗位模型引用同一技能项、同一等级档位时，两者可以直接比对：某员工在某技能项上的现有等级，与目标岗位在该技能项上的要求等级之间的差距，就是能力缺口。这个比对之所以成立，前提是技能项名称、定义和等级判定标准完全一致。对齐工作通常在分类体系维护阶段完成，矩阵和岗位模型只做引用，不做本地改写。
口径不一致会出现的问题
如果矩阵和岗位模型各自定义技能项或等级，会出现几类具体问题：同一名称的技能项在两边含义不同，比对结果失真；等级档位数量或判定标准不同，出现“矩阵里的 L3 相当于模型里的 L2”这类无法直接比较的情况；技能项粒度不同，一边按“数据库设计”记录，另一边按“MySQL 调优”要求，缺口计算无法落到同一行。这些问题不会在填写时暴露，往往在做人岗匹配或培养计划时才显现，返工成本较高。
在实际管理中，分类体系的维护、矩阵的更新和岗位模型的修订往往分散在不同文档和表格里，版本容易脱节。ONES 可以通过项目与工作项承载技能项的维护任务，用文档沉淀技能项定义与等级判定标准，并把人员技能记录与岗位要求放在同一套工作空间中引用，减少多处维护带来的口径漂移；具体承载方式需结合团队现有的项目结构设计。
与相邻概念的区别：技能矩阵、岗位能力模型、能力素质模型
这几个概念经常被并列提及，但它们回答的问题不同，使用场景也不同。区分的关键是看每个概念的主语和输出：主语是人还是岗，输出是现状还是要求。
| 概念 | 回答的问题 | 主语 | 输出性质 | 典型使用场景 |
|---|---|---|---|---|
| 技能分类体系 | 我们用什么口径描述能力 | 组织 | 定义 | 建立能力字典，统一各团队表述 |
| 技能矩阵 | 谁会什么、到什么程度 | 人员 | 现状盘点 | 排班派工、组建项目组、识别能力缺口 |
| 岗位能力模型 | 这个岗位要什么、到什么等级 | 岗位 | 要求定义 | 岗位说明书、人岗匹配、培养目标设定 |
| 能力素质模型 | 什么样的人能在这个组织持续产生高绩效 | 组织或人群 | 素质特征描述 | 人才盘点、领导力发展、文化导向 |
| 任职资格标准 | 达到某个职级需要满足哪些综合条件 | 职级 | 晋升条件 | 职级评定、晋升评审 |
能力素质模型与技能分类体系的差别主要在内容性质：能力素质模型常包含动机、特质、价值观等较难直接观察和分级的要素，用于解释绩效差异；技能分类体系聚焦可描述、可分级的工作能力，用于工作配置。任职资格标准与岗位能力模型的差别在用途：岗位能力模型描述岗位需要什么，任职资格标准描述人达到某个职级需要满足什么，后者通常综合知识、经验、成果等多类条件，并与晋升流程绑定。
具体例子与常见误解
以下为一个研发团队的演示情景，用于说明三者的取值差异，不指向任何真实团队或真实数据。
一个分层技能示例
某研发团队建立技能分类体系，设“后端开发”技能域，其下技能项包括“服务开发”“数据库设计”“接口联调”，每项设 L1 至 L3 三档并写明判定标准。技能矩阵记录：工程师甲在“服务开发”为 L2、在“数据库设计”为 L1；工程师乙在“服务开发”为 L3、在“接口联调”为 L2。岗位能力模型记录：“后端开发工程师”岗位要求“服务开发”L2、“数据库设计”L2、“接口联调”L2；“高级后端开发工程师”岗位要求“服务开发”L3、“数据库设计”L3、“接口联调”L2。
同一技能项在两个视图中取值不同：工程师甲在“服务开发”的矩阵取值是 L2，这是现状；岗位模型对“后端开发工程师”的要求也是 L2，这是要求。两者相等说明当前匹配；若甲的目标是“高级后端开发工程师”，则“服务开发”存在 L2 到 L3 的差距，“数据库设计”存在 L1 到 L3 的差距。矩阵和模型各自只提供一个方向的数值，差距来自两者比对，任何一方单独都不构成评估结论。
常见误解澄清
- 把技能矩阵当成分类体系。矩阵是填了人员数据的表格，分类体系是表格背后的技能项与等级定义。矩阵的列可以增删，但增删的依据应回到分类体系，否则不同团队的矩阵无法合并比较。
- 把岗位能力模型当成人员评估结果。岗位模型描述岗位要求，与具体人员无关。把岗位要求等级直接当作某员工的评估结论，会混淆“岗要什么”和“人会什么”，也无法反映人员之间的差异。
- 认为等级越多越精细。档位数量增加会提高区分度，同时提高判定难度和填写成本。档位过多时，相邻档位的行为差异难以写清，填写者容易凭印象打分，反而降低数据可信度。档位数量应以判定标准能否清晰区分为准，常见做法是三到五档。
- 把技能项写得越细越好。粒度过细会导致技能项数量膨胀，矩阵难以维护，岗位模型也难以稳定引用。技能项应细到能对应一类工作任务、能写出可观察的判定标准即可。
回到最初的问题：技能分类体系定义口径，技能矩阵用这套口径盘点人员现状，岗位能力模型用这套口径定义岗位要求。三者共用技能项与等级，才能让人岗比对、缺口识别和培养计划落在同一套语言上。
常见问题
技能分类体系应该由谁维护，多久更新一次？
维护责任通常落在对能力口径有全局视角的角色上，例如研发负责人、技术委员会或人力资源中的能力发展职能，具体归属取决于组织规模。更新频率没有统一标准，可以按两种触发条件安排：一是业务方向变化导致技能域或技能项需要增删，二是填写过程中发现某技能项定义含糊、等级判定标准无法区分。日常维护以技能项定义和等级描述为主，矩阵与岗位模型只做引用，避免各自改写造成口径漂移。
技能项和岗位能力模型里的要求等级，可以按团队分别定义吗？
可以按团队补充，但需要保留一套组织级的公共技能项与等级档位作为基准。如果各团队完全独立定义，跨团队比对时同一名称的技能项可能含义不同，等级档位也可能无法对应，人岗匹配和资源调配就失去共同语言。较稳妥的做法是公共层定义技能项名称、定义和等级判定标准，团队层只在公共技能项上标注本团队岗位的要求等级，新增技能项走统一的评审入口。
技能等级设几档比较合适，三档和五档怎么选？
档位数量取决于组织对区分度的实际需要和判定标准的可写程度。三档适合技能项数量多、填写频率高的场景，相邻档位的行为差异容易写清；五档适合对能力梯度要求更细的岗位序列，但每一档都需要能写出可观察的行为与结果，否则填写者容易凭印象打分。判断标准可以简单化为：如果相邻两档的判定标准写出来读者无法区分，就说明档位过密。常见做法是三到五档，具体以能否清晰判定为准。
已经有任职资格标准，还需要单独建岗位能力模型吗？
两者用途不同，可以并存。任职资格标准描述人达到某个职级需要满足的综合条件，通常包含知识、经验、成果等多类要素，并与晋升流程绑定；岗位能力模型描述某个岗位需要哪些技能项、达到什么等级，用于人岗匹配和培养目标设定。如果任职资格标准里已经按技能项和等级写清了岗位要求，可以复用其中的技能部分作为岗位能力模型，但需要确认它引用的是同一套技能分类口径，避免出现两套等级描述。
技能矩阵填完之后，怎么和岗位能力模型比对出缺口？
比对的前提是矩阵的列与岗位模型的技能项一一对应，单元格等级与要求等级使用同一套档位。满足这个前提后，按人员所在或目标岗位逐项对照：矩阵取值低于模型要求等级的即为缺口，等于或高于则为满足。实际操作中建议先固定比对范围，例如只比对目标岗位的核心技能项，避免技能项过多导致结果难以解读。比对结果用于制定培养计划时，还应结合工作任务的实际分配情况判断优先级。
