研发技能矩阵的设计从工作配置问题出发：先明确矩阵要回答哪些排班与分派问题，再按研发环节拆出可观察的能力项，定义可判定的熟练度等级与证据，最后把矩阵接入任务分派和资源协调。本文按用途、能力项、等级、表格、维护机制、示例和验收七个环节展开，范围限定在工作配置所需的能力信息，招聘考核、薪酬绩效与团队职责定义不在本文讨论。
要点总览（TL;DR）
- 先写一页用途说明，列出3–5个要回答的配置问题（如模块备份人选、借调评估），据此确定项目级、团队级或能力域级粒度。
- 能力项从需求分析、方案设计、编码实现、测试验证、发布运维等环节的关键活动转写，每条要能被他人判断是否具备，10人团队通常控制在20–40条。
- 等级采用三到四级并配行为描述与判定证据，自评加复核定级，同时写明哪类任务要求哪一级，矩阵才能直接用于排班。
- 矩阵以人员为行、能力项为列，单元格填等级与证据链接；先在一个5–10人团队试点两周，修订后再推广。
- 更新由触发点驱动（新成员加入、项目结束、技术栈变化、等级变化），每季度复核一次，并把矩阵接入项目启动分派、借调评估和交接确认。
先定用途：矩阵要回答哪些配置问题
技能矩阵的第一份产物应当是一页用途说明，列出3–5个具体的配置问题。矩阵的价值体现在它被用来做判断，表格填得再整齐，如果没人拿它做分派依据，就只是一次性归档资料。设计前先和项目负责人、技术负责人确认：过去一个季度里，哪些人员安排是靠口头印象拍板的？这些问题就是矩阵要服务的对象。
典型问题包括：新项目启动时由谁承接某个模块；某个核心模块目前只有一人熟悉，备份人选是谁；跨团队借调时，对方成员能否独立承担某类开发任务；版本发布前，值班与应急支持如何排人。每个问题写清使用场景和决策人，例如“模块备份人选”由技术负责人在项目启动会上使用。
用途决定粒度。项目级矩阵只覆盖当前项目涉及的能力项，适合短期交付团队；团队级矩阵覆盖团队全部研发环节，适合稳定建制的研发组；能力域级矩阵按前端、后端、数据、测试等领域分别建表，适合人员规模较大、跨项目借调频繁的组织。粒度越细维护成本越高，建议从团队级起步。
同时写明不纳入范围的内容：招聘选拔标准、薪酬绩效评估、团队职责与角色定义。这些事项有各自的制度依据，混入技能矩阵会让填写者顾虑评价后果，导致等级虚高。矩阵只回答“谁能做什么、做到什么程度”，不回答“谁更优秀”。
拆能力项：从研发环节导出可观察条目
能力项从研发流程的实际活动导出，不从素质词出发。按需求分析、方案设计、编码实现、测试验证、发布运维等环节逐段列出关键活动，再把活动转写成可观察的能力描述。判断标准是：换一个人来看，能否根据描述判断某人是否具备该能力。
转写时把泛化表述换成具体对象。例如“沟通能力强”无法判定，改为“能独立主持需求评审并输出评审结论”；“熟悉后端开发”改为“能独立完成某类业务接口的设计、实现与代码评审”；“了解数据库”改为“能独立完成慢查询分析与索引优化”。每条能力项注明所属环节、适用角色和技术栈或业务领域，便于后续按项目筛选。
条目数量需要控制。一个10人左右的研发团队，能力项通常落在20–40条之间；超过这个范围，填写和复核成本会明显上升，且大量条目长期无人引用。合并同义项时保留使用频率高的表述，剔除无法找到判定证据的描述，例如“有较强的学习能力”“具备架构思维”这类没有交付物支撑的条目。
能力项与岗位、技术栈、业务领域的对应关系建议单独列一列。同一能力项在不同技术栈下可能需要拆分，例如“接口设计”在Java服务和前端组件场景下的判定证据不同；业务领域维度则用于判断某人是否熟悉特定业务模块，这在跨项目借调时是重要参考。
定等级与证据：让熟练度可判定
等级划分建议采用三到四级，级别过多会增加判定分歧。一个可用的划分是：L1入门，能在指导下完成；L2可独立，能独立承担常规任务；L3可指导，能处理复杂情况并指导他人；L4可定义，能制定该领域的方法或标准。级别名称可以按团队习惯调整，关键是每一级都配行为描述，描述指向可观察的工作表现。
每级对应判定证据。证据类型包括：参与过的任务类型与数量、代码或设计评审记录、交付物（设计文档、测试方案、上线记录）、他人复核意见。证据要能指向具体工作项或文档，而不是“做过几年”这类时间口径。下表给出一个等级定义表的填写结构。
| 等级 | 行为描述 | 判定证据 | 可承担任务类型 |
|---|---|---|---|
| L1 入门 | 在他人指导下完成常规任务，能理解并遵循既有规范 | 参与过至少2个相关任务，有带教记录 | 辅助性开发、测试执行、文档整理 |
| L2 可独立 | 独立完成常规任务，输出通过评审 | 独立交付的任务清单、评审通过记录 | 常规模块开发、独立测试设计、日常运维 |
| L3 可指导 | 处理复杂或异常情况，能带教他人并输出可复用方法 | 复杂问题处理记录、带教对象成长记录、技术方案文档 | 核心模块负责人、方案评审人、新人带教 |
| L4 可定义 | 制定领域规范或技术标准，影响跨团队实践 | 规范文档、跨团队推广记录、评审意见被采纳记录 | 架构设计、标准制定、跨团队技术决策 |
填写方式采用自评加复核。成员先按证据自评等级并附上证据链接，再由直属负责人或能力项负责人复核，双方不一致时以证据为准讨论定级。复核人需要看过证据材料，不能只凭印象调整。等级与任务分派直接挂钩：例如核心模块的负责人要求L3以上，独立承担版本发布值班要求L2以上，带教新人要求L3。把这条关系写进等级定义表，矩阵才能直接用于排班判断。
建表与填写：矩阵的结构和字段
矩阵主体是“人员×能力项”的二维表：行是人员，列是能力项，单元格填等级和证据链接。人员较多或能力项较多时，可以按能力域拆成多张表，避免单表过宽难以阅读。必备字段包括：人员、角色、能力项、等级、证据、评估日期、评估人。角色字段用于区分前端、后端、测试等，便于按角色筛选。
填写按批次推进。先选一个5–10人的团队试点，用两周左右完成自评、复核和表格整理，观察填写耗时、争议点和证据可得性，再修订能力项和等级描述，然后推广到其他团队。试点阶段重点验证两件事：能力项描述是否足够清楚，证据是否容易找到。如果大量条目找不到证据，说明描述需要改写或该条目应当删除。
数据存放位置要满足两个条件：团队成员能方便查看，编辑权限受控。常见做法是放在团队共享的文档或表格工具中，设置查看权限全员开放、编辑权限限定给矩阵维护人和能力项负责人。证据链接指向任务、评审记录或交付文档，避免把证据正文直接贴进单元格导致表格臃肿。
矩阵维护与任务分派衔接时，可以把能力信息与工作项管理放在同一协作环境中。ONES 的工作项与成员信息管理可以承载任务分派和工时记录，ONES Resource 通过甘特视图完成项目资源规划与进度跟踪，并支持按工作数量和工时规模了解成员排期、筛选分组查看成员在不同项目中的投入比重，还能实时查看成员每日投入饱和明细并导出工时日志。技能矩阵提供“谁能做”的判断，资源视图提供“当前是否有空”的判断，两者结合才能完成一次完整的排班决策。需要说明的是，现有资料未提及 ONES 提供专门的技能等级或能力档案功能，矩阵表本身仍需按上述结构单独维护。
角色分工与更新机制
矩阵需要三类角色。能力项负责人通常由该领域的技术骨干担任，负责维护能力项描述和等级标准，判定争议时给出意见；人员直属负责人负责组织自评、复核等级、确认证据；矩阵维护人负责表格结构、权限、批次安排和变更记录，通常由团队负责人或项目管理角色兼任。职责写进一张简表，避免出现“大家都觉得该更新、没人实际动手”的情况。
更新由触发点驱动，而不是只靠固定周期。触发点包括：新成员加入时完成首次填写；项目结束时复核参与成员在项目中使用到的能力项；技术栈或业务方向变化时增删能力项；成员等级变化时由直属负责人发起变更并附新证据。固定复核建议每季度一次，重点检查长期未更新的条目和证据是否仍然有效。
变更记录保留在表格中，记录变更日期、变更人、变更前后等级和依据。这样在出现分派争议时可以回溯判断依据。矩阵与任务分派流程的衔接动作要写清楚：项目启动时，负责人按矩阵筛选满足等级要求的人选，再结合资源视图确认可用性；人员借调时，接收方查看矩阵中相关能力项的等级和证据，判断上手成本；交接时，交接双方对照矩阵确认接收人是否达到所需等级。
示例：一个后端团队的矩阵片段
以下为演示情景，用于说明填写方式，不代表真实团队数据。某后端团队负责订单与支付两个业务模块，选取的能力项包括：订单接口设计与评审、支付对账逻辑开发、慢查询分析与索引优化、线上故障定位、新人带教。三名成员的填写片段如下。
| 成员 | 角色 | 订单接口设计与评审 | 支付对账逻辑开发 | 慢查询分析与索引优化 | 线上故障定位 |
|---|---|---|---|---|---|
| 成员A | 后端 | L3，证据：订单服务接口规范文档、近两次评审记录 | L2，证据：对账任务交付记录 | L2，证据：两次慢查询优化工单 | L3，证据：三次线上故障处理记录 |
| 成员B | 后端 | L2，证据：独立交付的订单查询接口 | L3，证据：对账方案设计文档、带教记录 | L1，证据：在指导下完成一次索引调整 | L2，证据：值班期间故障处理记录 |
| 成员C | 后端 | L1，证据：参与订单模块开发任务 | L1，证据：参与对账测试 | L2，证据：独立完成两次查询优化 | L1，证据：跟随处理故障两次 |
从这张片段可以读出配置结论：支付对账逻辑目前只有成员B达到L3，属于单点依赖，需要安排成员A或成员C在下一个迭代参与对账任务以形成备份；订单接口评审有成员A和成员B两人达到L2以上，可以轮换承担评审；慢查询优化方面成员C已达L2，可以在成员A指导下承接部分优化工单，缓解A的排期压力。这些结论直接对应S1中列出的配置问题。
示例体现的取舍是：能力项只保留与当前业务模块和排班决策相关的条目，证据指向具体交付物而非主观评价，等级分布允许出现L1，不追求人人高分。这套做法可以迁移到前端、测试等团队，替换能力项和证据类型即可。
完成检查：矩阵是否真的能用
矩阵设计完成后，用一份检查清单逐项核对。以下条目全部通过，才说明矩阵具备实际使用条件。
- 每个能力项都能对应到具体研发环节和可观察的工作表现，抽查3条，请一位未参与设计的负责人判断某人是否具备，判断结果一致。
- 每个等级都有证据支撑，随机抽取5个单元格，证据链接可打开且与等级描述匹配。
- 能力项覆盖当前团队的主要研发环节，空缺集中在低频环节而非核心环节；核心模块至少有两名成员达到可独立等级。
- 更新责任人和触发点已写入职责表，最近一次更新有记录，变更记录可查。
- 能用矩阵回答S1列出的3–5个配置问题，每个问题都能在表中找到判断依据。
- 矩阵已接入至少一个实际流程，例如项目启动分派、借调评估或交接确认，并有使用记录。
常见失效信号需要提前识别：表格超过一个季度没有更新；等级集中在最高两档，缺少入门和独立层级的分布；填写证据栏大量为空或只写“熟悉”“了解”；项目分派时无人打开矩阵，仍按印象安排人员。出现其中任一信号，应回到能力项描述和复核机制检查，而不是简单要求大家重新填一遍。矩阵的可用性取决于它是否被真实引用，维护机制和流程衔接比表格本身更重要。
常见问题
团队规模不大，还需要建完整的技能矩阵吗？
小团队可以只保留与当前排班决策直接相关的能力项，不必覆盖全部研发环节。例如5人左右的后端组，先选10–15条核心能力项，重点标注核心模块的备份人选和值班资格。矩阵的用途说明仍然要写，哪怕只列两三个配置问题。规模扩大或跨项目借调增多时，再按能力域拆表补充。
成员自评等级普遍偏高，复核时怎么处理？
先检查等级描述是否指向可观察行为，再检查证据要求是否明确。复核时以证据为准：证据链接打不开、证据与等级描述不匹配的，降级或暂不定级。另一个有效做法是让复核人先独立看证据给出等级，再与自评结果对照，减少先看自评结果带来的锚定影响。如果某一等级长期集中出现，说明该级行为描述区分度不够，需要修订描述而不是反复要求重填。
技能矩阵和资源排期是什么关系，需要放在同一个工具里吗？
两者回答不同问题：矩阵回答“谁能做、做到什么程度”，资源视图回答“当前是否有空、投入多少”。一次完整的排班决策需要两个判断结合。放在同一协作环境中可以减少切换成本，例如 ONES Resource 支持通过甘特视图进行项目资源规划与进度跟踪，支持按工作数量和工时规模了解成员排期、筛选分组查看成员在不同项目中的投入比重，并可实时查看成员每日投入饱和明细、导出工时日志。矩阵表本身仍需按人员×能力项的结构单独维护，现有资料未提及 ONES 提供专门的技能等级或能力档案功能。
能力项多久需要增删一次？
能力项随技术栈和业务方向变化调整，不设固定周期。触发点包括：引入新技术栈或框架、业务模块上线或下线、团队职责范围变化。每次调整保留变更记录，注明新增或删除的原因和生效日期。已经删除的能力项对应的历史等级数据建议归档保留，便于回溯过去的排班依据。
矩阵建好后没人用，怎么判断问题出在哪？
先看矩阵能否回答最初列出的配置问题。如果问题本身模糊，或者矩阵中找不到对应判断依据，说明用途说明和能力项设计脱节。再看流程衔接：项目启动分派、借调评估、交接确认这些动作里，是否有一步明确要求查看矩阵。如果流程里没有这个动作，矩阵自然被跳过。最后检查更新状态，超过一个季度未更新、证据大量为空，会让人失去信任。按这个顺序排查，通常能定位到具体环节。
