研发技能矩阵是一张“人员×技能”的二维表：行是团队成员，列是技能项，单元格记录熟练等级与可佐证依据。本文提供可直接复制的空白表、字段说明、必填与选填口径，并用一个五人研发小组的完整示例演示填写方式，适合需要做任务分派、能力盘点或培训规划的研发团队参考。
要点总览（TL;DR）
- 研发技能矩阵是一张“人员×技能”的二维表，行是团队成员，列是技能项，单元格只填0至4的等级整数，证据与备注统一放在右侧列。
- 等级采用0至4五档，从“未接触”到“专家”，每档以可观察的行为描述判定，不按工作年限折算；等级单元格留空表示“尚未评估”，与0级区分。
- 首次填写先保证姓名、技能项、等级、更新日期四列齐全，角色、证据来源、备注可按需补充；等级为3或4时建议补齐证据。
- 维护围绕技能项增删、季度等级复核、人员变动更新和任务分派衔接展开，复核后统一更新日期列。
- 矩阵落地后，可把评估结果与成员实际工时投入放在同一视角对照，ONES Plan 的资源报表支持查看 ONES Project 中的登记工时、预估工时和剩余工时数据，需同时使用 ONES Project 并产生工时数据。
可复制空白研发技能矩阵表
下表是空白模板，复制到表格软件后即可填写。行对应团队成员，列按技能分组排列，每个技能项下留一个等级单元格，右侧统一放证据与备注列。技能分组行用于把同类技能归在一起，填写时按组逐列展开。
| 姓名 | 角色 | 技能组 | 技能项1 | 技能项2 | 技能项3 | 技能项4 | 技能项5 | 技能项6 | 证据来源 | 备注 | 更新日期 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| （示例）张三 | 后端工程师 | 编程语言 | |||||||||
| 框架与中间件 | |||||||||||
| 工程实践 | |||||||||||
| 领域知识 |
使用时有三个位置需要留意。第一，技能项列按团队实际技术栈替换，数量可增减，建议单表控制在15至25列，过多会降低可读性。第二，等级单元格只填0至4的整数，不写文字描述，描述统一放在等级定义表中。第三，证据来源列写可核查的材料名称，例如“订单服务重构PR”“2024年Q2压测报告”，避免只写“熟悉”“精通”这类无法验证的表述。
如果团队人数较多，可以按小组拆成多张表，用同一套技能项和等级口径，汇总时再合并。技能分组行在复制后可以删除或保留，保留的好处是新增技能项时有明确的归类位置。
技能矩阵各字段说明与等级定义
字段说明解决“每一列填什么”，等级定义解决“同一个格子为什么不同人填出来一致”。两者配套使用，才能让矩阵在跨小组比较时仍然可信。
字段说明表
| 字段 | 含义 | 填写要求 |
|---|---|---|
| 姓名 | 矩阵覆盖的团队成员 | 使用真实姓名或工号，与团队花名册一致 |
| 角色 | 当前承担的主要职责，如后端、前端、测试、运维 | 写当前角色，不写职级 |
| 技能组 | 技能项的分类行，如编程语言、框架与中间件、工程实践、领域知识 | 用于分组阅读，不参与等级判定 |
| 技能项 | 团队需要评估的具体能力，如Java、SQL优化、单元测试、支付领域知识 | 一项技能一列，名称具体到可判断 |
| 等级 | 该成员在该技能上的熟练程度，取0至4 | 只填整数，依据等级定义判定 |
| 证据来源 | 支撑该等级的客观材料 | 写材料名称、时间或链接位置，可被他人核查 |
| 备注 | 补充说明，如“正在学习”“仅限内部系统” | 选填，用于解释特殊情况 |
| 更新日期 | 该行最近一次确认的时间 | 写年月，便于识别过期数据 |
等级定义表
等级采用0至4五档，每档给出可观察的行为描述。判定时以“能否独立完成对应行为”为准，不按工作年限折算。
| 等级 | 名称 | 行为描述 | 典型证据 |
|---|---|---|---|
| 0 | 未接触 | 没有相关学习或实践记录 | 无 |
| 1 | 了解 | 读过文档或参加过培训，能在指导下完成简单操作 | 培训记录、学习笔记 |
| 2 | 可独立应用 | 能独立完成常规任务，遇到复杂问题需要求助 | 已合并的常规需求代码、测试用例 |
| 3 | 熟练 | 能独立处理复杂问题，能评审他人产出，能指导新人 | 复杂模块负责人记录、代码评审记录 |
| 4 | 专家 | 能定义团队规范，解决跨团队难题，产出可复用的方法或工具 | 技术方案、规范文档、内部培训材料 |
技能项分类建议按团队技术栈组织，常见分组包括编程语言、框架与中间件、数据与存储、工程实践、领域知识。分组数量控制在4至6组，既能体现结构，又不至于让表格过宽。证据来源类型可分为四类：代码与合并记录、文档与方案、测试与运维记录、培训与分享记录。填写时优先选择可追溯的记录，口头评价只作为备注。
哪些字段必填、哪些可以选填
首次填写时，必填字段保证矩阵可用，选填字段留出补充空间。必填项缺失会让矩阵无法用于分派或盘点，选填项缺失不影响基本判断。
| 字段 | 必填/选填 | 原因与适用场景 |
|---|---|---|
| 姓名 | 必填 | 矩阵的行标识，缺失则无法对应到人 |
| 技能项 | 必填 | 列标识，缺失则无法比较 |
| 等级 | 必填 | 核心数据，缺失单元格视为未评估 |
| 更新日期 | 必填 | 判断数据是否过期，缺失则无法安排复核 |
| 角色 | 选填 | 用于按角色筛选，团队规模较小时可省略 |
| 证据来源 | 选填 | 等级为3或4时建议填写，用于支撑高等级判定 |
| 备注 | 选填 | 解释“正在学习”“仅限内部系统”等特殊情况 |
缺省值处理有两条约定。等级单元格留空表示“尚未评估”，与0级“未接触”区分开，避免把没评估的人误判为不具备该技能。证据来源留空表示暂未收集，不表示该等级无效，但高等级单元格建议在下次复核时补齐。
填写不完整时，先保证姓名、技能项、等级、更新日期四列齐全，再逐步补充证据。对于新入职成员，可以只填已确认的技能项，其余留空并在备注写“入职首月评估”。矩阵允许部分完成，关键是空白与0级的口径在全表统一。
填写示例：一个五人研发小组的矩阵
以下为演示情景：一个五人研发小组，负责订单相关服务，技能项选取六项，覆盖编程语言、数据存储、工程实践和领域知识。示例中的姓名与证据均为示意，实际使用时替换为团队真实信息。
| 姓名 | 角色 | Java | SQL优化 | 单元测试 | 订单领域知识 | 消息队列 | 前端开发 | 证据来源 | 备注 | 更新日期 |
|---|---|---|---|---|---|---|---|---|---|---|
| 李工 | 后端工程师 | 4 | 3 | 3 | 3 | 3 | 1 | 订单服务重构方案、代码评审记录 | 2025-03 | |
| 王工 | 后端工程师 | 3 | 2 | 2 | 2 | 2 | 0 | 支付回调模块合并记录 | 2025-03 | |
| 赵工 | 测试工程师 | 1 | 2 | 4 | 3 | 1 | 1 | 自动化测试规范、Q2回归报告 | 2025-03 | |
| 陈工 | 前端工程师 | 1 | 1 | 2 | 2 | 0 | 4 | 订单管理前端组件库 | 2025-03 | |
| 周工 | 运维工程师 | 2 | 3 | 1 | 1 | 3 | 0 | 消息队列运维手册、故障复盘 | 正在学习订单领域知识 | 2025-03 |
等级判定依据示例中的几处关键判断。李工的Java定为4级，因为其产出了团队编码规范并承担新人培训，符合“定义规范、产出可复用方法”的行为描述。赵工的单元测试定为4级，依据是自动化测试规范和回归报告，属于可复用的方法产出。周工的消息队列定为3级，因为其编写了运维手册并处理过故障，能独立处理复杂问题，但尚未形成跨团队规范，因此不升到4级。
证据列写法遵循“材料名称＋可定位信息”的格式。例如“订单服务重构方案”可以定位到具体文档，“Q2回归报告”可以定位到时间范围。避免写“表现优秀”“大家认可”这类无法核查的描述。备注列只写影响判定的特殊情况，例如周工的“正在学习订单领域知识”，说明其1级是当前状态而非最终结论。
矩阵的调整与维护方法
技能矩阵的价值在于持续可用，一次性填完就搁置会迅速失真。维护围绕技能项增删、等级复核、人员变动和任务分派衔接四件事展开。
技能项增删规则
- 新增技能项的条件：团队引入新技术栈、新业务领域，或连续两个季度出现因该技能缺失导致的分派困难。
- 删除技能项的条件：该技能已不再用于当前项目，且团队内无人承担相关工作。删除前先归档旧表，保留历史记录。
- 每次增删控制在3项以内，避免整表重填；增删后在备注列标注变更原因和生效时间。
等级复核周期
建议每季度复核一次，重点复核3级和4级单元格，因为高等级直接影响任务分派和带人安排。复核方式是由成员提交新的证据材料，由技术负责人确认等级是否调整。0级和1级可以每半年复核一次，减少维护成本。复核完成后统一更新“更新日期”列。
人员变动时的更新动作
- 新成员入职：首月内完成首次评估，未确认的技能项留空并备注“待评估”。
- 成员转岗：保留原行，在备注写明转岗时间，新增角色对应的技能项评估。
- 成员离职：将该行移入归档表，不直接从主表删除，便于追溯历史分派依据。
矩阵与任务分派的衔接方式
分派任务时，先按任务所需技能筛选等级达到2级及以上的人员，再结合当前负载确定人选。等级为3或4的成员适合承担复杂模块或评审职责，等级为2的成员适合独立完成常规任务并在评审中成长。矩阵提供的是能力参考，最终分派仍需结合成员意愿和项目排期。
矩阵落地后，能力记录与任务分派往往分散在不同表格和系统中，维护成本会上升。ONES Plan 提供多项目进度管控和资源管理，其资源报表可实时反馈项目投入情况，并支持查看 ONES Project 中的登记工时、预估工时和剩余工时数据，团队可以把技能矩阵的评估结果与成员实际投入放在同一视角下对照，减少分派时反复核对表格的动作。使用该能力需要同时使用 ONES Project 并产生工时数据；技能维度的成员能力记录仍需以本文模板或团队自建表维护。
维护节奏建议固化为三个动作：季度复核等级、变更时同步更新日期、分派前查看最新矩阵。把这三个动作写进团队例会议程，矩阵才能长期作为分派和盘点的依据，而不是一份填完就过期的文档。
常见问题
技能矩阵里的等级单元格留空和填0有什么区别？
留空表示“尚未评估”，填0表示“未接触”，即已确认没有相关学习或实践记录。两者混用会让盘点结果失真：把没评估的人当成不具备该技能，可能漏掉可用人选。建议在全表统一口径，新入职成员未确认的技能项留空，并在备注写明“待评估”。
团队人数较多时，技能矩阵应该拆成多张表还是合成一张？
可以按小组拆成多张表，但技能项和等级定义要使用同一套口径，汇总时再合并。单表技能项建议控制在15至25列，列数过多会降低可读性。拆分后需要指定一人负责汇总，避免各组自行修改等级定义导致结果无法比较。
技能等级评定时，成员自评和技术负责人评定不一致怎么办？
以证据为准，不以职级或资历裁定。可以让成员先提交支撑材料，例如已合并的代码记录、技术方案、评审记录，再由技术负责人对照等级定义中的行为描述确认。分歧集中在3级和4级时，重点看是否有复杂问题处理记录、评审他人产出的记录或可复用的方法产出。仍无法达成一致时，先按较低等级记录，并在备注写明待补充的证据类型。
技能矩阵和任务分派之间怎么衔接，避免矩阵填完用不上？
分派时先按任务所需技能筛选等级达到2级及以上的人员，再结合当前负载确定人选。等级为3或4的成员适合承担复杂模块或评审职责，等级为2的成员适合独立完成常规任务。矩阵提供的是能力参考，最终分派仍需结合成员意愿和项目排期。把“分派前查看最新矩阵”写进团队例会议程，矩阵才会真正进入日常流程。
技能矩阵的评估结果能否和成员的实际工时投入放在一起看？
可以借助项目管理系统对照。ONES Plan 提供多种资源报表，实时反馈项目投入情况，其资源管理可直接查看 ONES Project 中的登记工时、预估工时、剩余工时数据，团队能把技能矩阵的评估结果与成员实际投入放在同一视角下核对。使用该能力需要同时使用 ONES Project 并产生工时数据；技能维度的成员能力记录仍需以本文模板或团队自建表维护。
