从零搭建研发技能分类体系，核心是先确定它要服务哪些实际动作，再据此选择分类维度和层级粒度。本文面向首次建立或重构体系的研发团队，给出维度反推方法、两级与三级的判断标准、命名规范、维护流程，以及一份可参照的落地样例和上线检查清单。技能条目与人员能力关联后的排期与投入管理，可以借助ONES的资源视图承接。
要点总览（TL;DR）
- 先列出排任务、配人、找替补、能力盘点等实际动作，每个动作需要区分的差异对应一个维度，维度数量取能支撑这些动作的最小集合。
- 维度之间保持正交，同一技能只在一个主维度下出现；技术栈信息可作为技能项属性字段，不必单独升为维度。
- 层级粒度以“同层条目能被同一个人用同一标准判断”为基准，通常采用两级，中间层会被实际引用时才加第三级。
- 熟练程度作为独立维度而非层级，避免条目成倍增加和水平口径调整牵动结构。
- 命名统一采用“领域+对象+动作或产出”结构，维护流程区分新增、合并、停用三类变更，明确评审人与生效时点。
先明确技能分类体系要支撑哪些动作
技能分类体系的价值来自使用。设计前先把团队真实会做的动作列出来，每个动作写清需要从分类中读到什么信息，这份清单就是后续所有设计决策的依据。动作清单不必求全，覆盖未来半年内确实会发生的场景即可。
| 使用动作 | 需要从分类中读到的信息 | 对体系的要求 |
|---|---|---|
| 排任务 | 某项任务需要哪类技能、哪个具体技能项 | 技能项要能对应到任务类型，粒度接近任务拆解层级 |
| 配人 | 成员具备哪些技能项、处于什么水平 | 技能项与人员记录可关联，水平有统一口径 |
| 找替补 | 同一技能项下还有谁可以接手 | 技能项命名唯一，避免同义条目分散候选人 |
| 能力盘点 | 团队在某领域的能力分布与缺口 | 领域层稳定，便于跨时间对比 |
| 培养规划 | 成员当前技能与目标岗位所需技能的差距 | 技能项可对应到学习路径或实践机会 |
清单完成后做一次收敛：如果某个动作半年内不会发生，或它需要的信息与其他动作完全重合，就从范围中删去。最终保留的动作集合决定了体系必须覆盖的最小范围，也决定了后面维度数量的上限。范围定得过大，体系会变成一份没人维护的技能词典；范围定得过小，排任务和找替补时仍然要靠个人记忆。
分类维度怎么选：从使用动作反推维度
维度选择的方法是逐条回看动作清单：每个动作需要区分的差异，对应一个维度。排任务需要区分“做什么类型的活”，对应技能领域维度；配人需要区分“具体会什么”，对应技能项维度；找替补需要区分“会到什么程度”，对应熟练程度维度。动作清单里没有提出的区分需求，不新增维度。
| 常见维度 | 回答的问题 | 典型取值示例 | 适用动作 |
|---|---|---|---|
| 技能领域 | 属于哪一类研发工作 | 后端开发、前端开发、测试、运维、数据 | 能力盘点、培养规划 |
| 技术栈或工具 | 使用什么技术或平台完成 | Java、Go、React、Kubernetes | 排任务、配人 |
| 技能项 | 具体能完成什么工作 | 接口设计与实现、性能压测、容器编排 | 排任务、找替补 |
| 熟练程度 | 能独立做到什么水平 | 了解、可独立完成、可指导他人 | 配人、找替补、培养规划 |
维度数量取能支撑动作清单的最小集合。多数研发团队用“技能领域+技能项+熟练程度”三个维度即可覆盖排任务、配人、找替补和盘点；技术栈信息可以作为技能项的属性字段，不必单独升为维度，否则同一技能会在“领域”和“技术栈”两处重复出现。
维度之间要保持正交：同一技能只在一个主维度下出现。例如“数据库性能调优”归入“数据”领域下的技能项，就不再在“后端开发”领域下重复建一条。出现交叉时，处理方式是确定唯一归属，另一处只做引用或标签，不做独立条目。判断是否正交可以用一个简单测试：任取两个条目，能否说清它们为什么不同；说不清，说明维度设计存在重叠。
层级粒度怎么定：两级还是三级
粒度是否合适，用一个标准判断：同一层级内的任意两个条目，能被同一个人用同一标准区分开。做不到，说明这一层过细或定义不清；如果一层里大量条目在实际使用中从不被单独引用，说明这一层过粗或多余。
两级结构适用于团队规模较小、技能面相对集中的情况：一级为技能领域，二级为具体技能项。它的维护成本低，条目总数可控，排任务和配人时直接落到技能项。三级结构适用于技能项内部还需要区分细分方向的情况，例如“测试”领域下分“自动化测试”“性能测试”，再往下才是具体技能项。三级只在中间层能被稳定引用时才成立，如果中间层只是分类习惯、日常没人按它检索，就合并回两级。
| 结构 | 适用情形 | 主要风险 |
|---|---|---|
| 两级 | 团队规模中等、技能面集中、维护人力有限 | 技能项数量膨胀后难以浏览 |
| 三级 | 技能项多且存在稳定的细分方向，中间层会被实际引用 | 中间层定义模糊时，条目归属争议多、维护成本上升 |
过细的代价是维护成本：每新增一个条目都要评审、定义、通知，条目越多，同义和上下位混排的概率越高。过粗的代价是匹配失效：技能项写成“后端开发”这种领域级名称，排任务时无法判断谁能做具体工作。取舍原则是优先保证匹配可用，再控制条目数量；宁可两级加字段，不轻易加第三级。
熟练程度建议作为独立维度，不并入层级。把它做成层级会导致“Java-初级、Java-中级、Java-高级”这类条目成倍增加，且每次水平口径调整都要改动结构。作为独立维度时，技能项保持稳定，水平取值单独维护，配人和找替补时按“技能项+水平”组合检索即可。
命名规则与条目编写规范
命名统一采用“领域+对象+动作或产出”的结构，让条目名本身说明它覆盖的工作。例如“后端-订单服务-接口设计与实现”“测试-支付链路-性能压测”。名称中不出现“等”“相关”“综合”这类无法判断边界的词。
每个条目按固定字段编写，字段模板如下：
- 名称：按上述结构命名，全体系唯一。
- 定义：一两句话说明该技能项覆盖的工作范围，写清包含什么、不包含什么。
- 判断依据：列出可观察的行为或成果，用于判断成员是否具备该技能项，例如“独立完成过一次线上接口的性能压测并输出报告”。
- 典型产出：该技能项对应的交付物，如设计文档、测试报告、部署脚本。
- 所属领域：唯一归属的一级领域。
- 状态与维护人：生效、待评审或停用，以及负责该条目的维护人。
避免同义条目和上下位混排的做法是：新增前先按名称和定义做一次检索，已有条目能覆盖就不新建；发现两个条目实际指同一件事，走合并流程而不是并存；上下位关系只允许出现在相邻层级之间，同一层内不出现“包含”关系。内部黑话如果只在个别小组通行，写入定义时补充通用表述，名称仍使用团队多数人能理解的说法。
角色分工与维护流程
技能分类体系需要三类角色：提出人、评审人、维护人。提出人通常是使用体系的一线负责人或技术骨干，负责说明新增或调整的理由及使用场景；评审人由各技能领域的负责人组成，负责判断条目是否重复、定义是否可判断；维护人负责条目库的日常更新、版本记录和变更通知，通常由研发管理或技术运营角色承担。
| 变更类型 | 触发情形 | 处理路径 | 生效时点 |
|---|---|---|---|
| 新增 | 出现现有条目无法覆盖的工作 | 提出人提交名称、定义、判断依据→领域评审人确认不重复→维护人录入并标记生效 | 评审通过后的下一个盘点周期 |
| 合并 | 两个条目实际指同一技能，或存在上下位混排 | 提出人说明合并理由→涉及领域的评审人共同确认→维护人保留主条目、停用被合并条目并记录映射 | 合并确认后立即生效，历史记录保留映射关系 |
| 停用 | 技能项已不再使用，或被新技术替代 | 维护人发起→领域评审人确认无在用的匹配依赖→标记停用，不删除 | 确认无依赖后生效 |
评审周期建议与能力盘点节奏对齐，例如每季度集中评审一次，紧急新增可走临时评审。生效时点要明确到具体日期，避免出现“已评审但未生效”的中间状态被不同团队各自解读。停用条目保留而不删除，是为了让历史盘点数据仍可追溯。
需要划清的边界是：技能分类体系描述“工作需要什么能力”，团队角色职责定义描述“某个角色承担什么责任”，两者可以互相引用，但不互相替代。招聘考核标准、薪酬绩效制度同样不写入技能条目，条目只保留与工作配置相关的信息。
示例：一个研发技能分类体系的落地样例
以下为一个约二十人研发团队的示例，采用两级结构加熟练程度维度，供参照调整。
一级领域包括：后端开发、前端开发、测试、运维、数据。以“后端开发”为例，二级技能项包括“订单服务-接口设计与实现”“支付服务-幂等与对账处理”“公共组件-接口鉴权设计”。熟练程度取值为“了解、可独立完成、可指导他人”，作为独立维度记录在人员能力信息中。
条目字段填写示例：名称为“后端-支付服务-幂等与对账处理”；定义为“覆盖支付回调的幂等控制、日终对账差异定位与处理，不包含支付渠道接入谈判”；判断依据为“独立处理过一次对账差异并输出定位结论”“在代码评审中指出过幂等缺陷”；典型产出为“对账差异分析记录、幂等方案设计说明”；所属领域为“后端开发”；维护人为后端领域负责人。
一次新增变更的走查：团队引入消息队列后，现有条目无法覆盖“消息积压排查”。后端负责人在季度评审前提交新增申请，名称为“后端-消息队列-积压排查与消费优化”，附定义、判断依据和典型产出。后端领域评审人检索后确认与“运维-中间件-容量评估”不重复，前者聚焦消费逻辑与积压定位，后者聚焦容量规划，予以通过。维护人录入条目、标记生效日期，并在变更记录中登记。若评审中发现两个条目实际重叠，则转入合并流程，保留使用频率更高的名称，另一条停用并记录映射。
体系落地后，技能项与人员能力的关联数据需要进入日常排期才能持续产生价值。ONES Resource 支持通过甘特视图进行项目资源规划与进度跟踪，并可按工作数量和工时规模了解成员排期、通过筛选与分组掌握成员在不同项目的投入比重；ONES Plan 的资源管理可查看 ONES Project 中的登记工时、预估工时与剩余工时。技能维度本身仍需团队自行维护条目，工具承接的是条目关联之后的人员投入与排期管理。
完成检查：体系可用性的验证清单
上线前用以下清单逐项验证，每项给出通过标准，未通过则回到对应章节调整。
- 实际任务试跑：取近期五个真实任务，按体系找到对应技能项并匹配到人。通过标准：五个任务都能落到具体技能项，且每个任务至少能匹配到两名候选人，或能明确说明只有一人具备是真实情况而非条目过细。
- 重复与歧义检查：随机抽取二十个条目，请两位未参与编写的领域负责人独立判断成员是否具备。通过标准：两人判断一致率不低于八成；不一致的条目补充判断依据或合并。
- 维护责任到位：每个一级领域都有明确的评审人和维护人，变更流程有书面记录。通过标准：能当场指出任一新增申请应提交给谁、由谁评审、何时生效。
- 边界检查：抽查条目定义与字段，确认未混入招聘考核标准、薪酬绩效等级或岗位职责描述。通过标准：条目只描述工作所需能力与判断依据，涉及考核与薪酬的内容已移出体系。
- 层级合理性检查：统计各层级条目数量与被引用频率。通过标准：不存在长期零引用的中间层；技能项数量在团队可浏览的范围内，超出时优先合并而非加层。
清单全部通过后即可发布首个版本，并把评审周期、变更入口和维护人名单随体系一并公布。体系上线后的前两个盘点周期是观察期，重点看新增与合并申请是否集中在少数领域，集中出现往往说明该领域的粒度需要整体调整，而不是逐条修补。
常见问题
团队规模不大，技能分类体系只做一级领域可以吗？
一级领域只能回答“属于哪类研发工作”，排任务和找替补时仍无法判断具体谁能做。如果团队确实很小、成员技能高度重合，可以先用“领域+技能项”两级起步，把熟练程度作为人员记录中的独立字段。等到技能项数量增长、浏览困难时，再考虑在领域与技能项之间加一层细分方向，前提是这一层会被日常检索实际引用。
同一个技能项既属于后端又涉及数据，应该归到哪里？
按唯一归属处理：选择日常使用频率更高的主维度作为归属，另一处只做引用或标签，不建独立条目。判断时可以看这个技能项在排任务时通常由哪个领域的负责人评审、由哪类任务触发。归属确定后写入条目定义，后续新增条目时按同一规则处理，避免同一技能在两个领域下各有一份定义。
技能条目建好之后，和人员能力数据怎么衔接？
条目本身解决“工作需要什么能力”，人员能力数据解决“谁会什么、到什么程度”。衔接方式是在人员记录中按“技能项+熟练程度”登记，排任务时按技能项检索候选人。条目库与人员记录的关联数据进入日常排期后，可以借助 ONES Resource 的甘特视图和筛选分组查看成员在不同项目的投入比重，ONES Plan 的资源管理可查看 ONES Project 中的登记工时、预估工时与剩余工时。技能条目本身仍需团队自行维护。
评审周期定多长合适，紧急新增怎么处理？
评审周期建议与能力盘点节奏对齐，例如每季度集中评审一次，这样条目变更和盘点结果能同步更新。紧急新增可走临时评审，由对应领域评审人确认不重复后先行生效，再在下次集中评审时补记。无论哪种路径，生效时点都要写到具体日期，避免“已评审未生效”的状态被不同团队各自解读。
体系上线后，怎么判断是整体粒度有问题还是个别条目要调整？
看变更申请的分布。如果新增与合并申请集中在少数领域，往往说明该领域的层级或粒度需要整体调整，逐条修补会反复出现同类问题；如果申请分散在各领域且数量平稳，说明结构基本可用，按常规流程处理即可。上线后的前两个盘点周期是观察窗口，把申请记录按领域归类统计，再决定是否调整结构。
