技能需求清单把“这项任务需要什么能力”写成可核对的条目，供排期、匹配和补充人员时使用。本文提供一张可直接复制到表格工具的空白模板，逐字段说明填写口径，标出必填与选填，并用一条完整记录示范从任务拆到技能行的写法，最后说明按团队情况调整与长期维护的方法。
要点总览（TL;DR）
- 技能需求清单采用“主表＋技能明细行”结构：主表一行对应一个任务，技能明细一行写一项技能，两表通过需求编号关联。
- 必填字段为需求编号、任务或工作项、交付物、所需技能、熟练度要求、需求人数、投入时段；来源依据、满足方式、替代技能、培养计划、状态、备注为选填。
- 熟练度要求用可观察的行为或产出描述，例如“能独立编写并调试迁移脚本，处理字段映射异常”，便于匹配时核对。
- 技能拆分粒度以“能否据此筛选人员”为准，拆得太粗无法区分工序，拆得太细会让清单冗长难维护。
- 模板可按团队规模与项目类型增删字段，增删时同步更新字段说明和示例，并保留模板版本与单条需求的变更记录。
可复制空白技能需求清单模板
模板采用“主表＋技能明细行”的组织方式：主表一行对应一个任务或工作项，记录需求编号、任务对象、交付物、投入时段和整体状态；技能明细行挂在需求编号下，一行写一项技能，记录熟练度要求、需求人数和满足方式。这样同一任务需要多项技能时，不必把多个技能挤进一个单元格，后续按技能筛选人员也更方便。
下面的空白表可直接复制到 Excel、在线表格或文档表格中填写。第一张为主表，第二张为技能明细表，两表通过“需求编号”关联。
| 需求编号 | 任务或工作项 | 交付物 | 投入时段 | 需求提出人 | 来源依据 | 整体状态 | 备注 |
|---|---|---|---|---|---|---|---|
| 需求编号 | 所需技能 | 熟练度要求 | 需求人数 | 投入时段 | 替代技能 | 满足方式 | 培养计划 | 状态 |
|---|---|---|---|---|---|---|---|---|
如果团队任务规模较小、一项任务通常只对应一项主要技能，也可以把两张表合并为一张宽表，每行同时写任务信息和一项技能。合并后字段不变，只是同一需求编号会出现多行，筛选时按需求编号归并即可。
每个字段填什么：字段说明与取值口径
字段口径统一，清单才能被提需求的人、排期的人和被匹配的人一致理解。填写时先写清任务交付物，再拆技能，最后标注满足方式，顺序与下表一致。
| 字段 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 需求编号 | 清单内唯一标识，用于关联主表与技能明细 | 团队统一编码规则，如“项目缩写-年份-序号” | CRM-2025-014 |
| 任务或工作项 | 产生技能需求的具体任务 | 写可识别的任务名称，避免只写“项目支持”这类笼统表述 | 客户数据迁移脚本开发 |
| 交付物 | 任务完成时可验收的产出 | 写具体产物或结果，作为判断技能是否够用的依据 | 迁移脚本、迁移验证报告 |
| 所需技能 | 完成交付物必须具备的能力 | 一项技能一行，写到可识别的技能名称，不写“技术能力强”这类笼统描述 | SQL 数据迁移 |
| 熟练度要求 | 该技能需要达到的水平 | 用可观察的行为或产出描述，如“能独立编写并调试迁移脚本，处理字段映射异常” | 能独立完成含异常处理的迁移脚本 |
| 需求人数 | 具备该技能并投入的人数 | 写整数，按实际投入口径统计，兼职投入需在备注说明 | 2 |
| 投入时段 | 该技能被占用的起止时间或工作量 | 写起止日期，或写“人天/人周”工作量，二者选一种口径并全表统一 | 2025-03-03 至 2025-03-14 |
| 来源依据 | 该需求由什么支撑 | 写需求文档、项目计划、评审结论等可追溯出处 | 项目计划 V2 第 3 节 |
| 满足方式 | 计划如何补上这项能力 | 从“内部匹配、临时协作、外部补充、培养后使用”中选择并写明 | 内部匹配 |
| 替代技能 | 可替代所需技能的其他能力 | 写清替代技能及可接受的熟练度，便于匹配时放宽条件 | 具备 ETL 工具使用经验 |
| 培养计划 | 通过培养补足能力的安排 | 写培养方式与预计可用时间 | 结对开发，2 周后可独立承担 |
| 状态 | 该条需求的当前进展 | 用统一状态值，如“待匹配、已匹配、已到位、已关闭” | 待匹配 |
| 备注 | 其他需要说明的条件 | 写兼职比例、地点、工具限制等影响匹配的信息 | 每周投入 3 天 |
熟练度是这份清单里最容易写虚的字段。写“熟练”“精通”这类等级词，不同人理解不一致，匹配时无法判断。改成可观察描述后，判断标准就落在具体行为上：能独立完成哪类交付物、能处理哪类异常、是否需要他人复核。例如“能独立编写并调试迁移脚本，处理字段映射异常”比“SQL 熟练”更容易核对。
来源依据和满足方式分别回答“为什么需要”和“打算怎么解决”。来源依据写可追溯的文档或结论，避免需求口口相传；满足方式在需求提出时就写明倾向，内部匹配、临时协作、外部补充、培养后使用四类路径对应不同的排期动作，提前标注可以减少后续反复确认。
必填与选填：哪些字段不能空
必填字段决定这条需求能否进入匹配和排期。任务对象、所需技能、熟练度要求、需求人数、投入时段五项缺失任何一项，匹配就无法进行：不知道任务就不知道需求背景，不知道技能就无法筛选人员，没有熟练度就无法判断是否够用，没有人数和时段就无法排期。
| 字段 | 必填/选填 | 缺失时的后果 |
|---|---|---|
| 需求编号 | 必填 | 主表与技能明细无法关联，同一任务的多项技能会散落 |
| 任务或工作项 | 必填 | 无法判断需求背景，匹配结果难以复核 |
| 交付物 | 必填 | 熟练度要求失去判断依据，容易写虚 |
| 所需技能 | 必填 | 无法按技能筛选人员，清单失去匹配价值 |
| 熟练度要求 | 必填 | 无法判断候选人是否够用，匹配只能靠印象 |
| 需求人数 | 必填 | 无法计算资源缺口，排期容易低估 |
| 投入时段 | 必填 | 无法与人员现有排期比对，冲突发现滞后 |
| 来源依据 | 选填 | 需求可追溯性下降，变更时难以核对原始结论 |
| 满足方式 | 选填 | 匹配路径不明确，需要额外沟通确认 |
| 替代技能 | 选填 | 匹配范围偏窄，可能错过可替代人选 |
| 培养计划 | 选填 | 培养路径未记录，长期缺口缺少补足安排 |
| 状态 | 选填 | 无法快速识别待处理条目，跟进依赖人工询问 |
| 备注 | 选填 | 兼职比例、地点等约束未体现，匹配后可能返工 |
选填不等于可以随意留空。来源依据和满足方式在需求评审阶段补上，能让清单从“技能罗列”变成可执行的匹配依据；替代技能和培养计划在内部匹配不顺利时价值最大，建议在需求提出时就评估是否需要填写。状态字段建议在清单投入使用后统一维护，否则待匹配条目会越积越多。
填写示例：一条完整技能需求记录
下面用一条客户数据迁移任务示范完整写法。该任务拆出两项技能，分别占一行，主表只出现一次。
| 需求编号 | 任务或工作项 | 交付物 | 投入时段 | 需求提出人 | 来源依据 | 整体状态 | 备注 |
|---|---|---|---|---|---|---|---|
| CRM-2025-014 | 客户数据迁移脚本开发 | 迁移脚本、迁移验证报告 | 2025-03-03 至 2025-03-14 | 项目负责人 | 项目计划 V2 第 3 节 | 待匹配 | 与测试窗口联动 |
| 需求编号 | 所需技能 | 熟练度要求 | 需求人数 | 投入时段 | 替代技能 | 满足方式 | 培养计划 | 状态 |
|---|---|---|---|---|---|---|---|---|
| CRM-2025-014 | SQL 数据迁移 | 能独立编写并调试迁移脚本，处理字段映射异常 | 2 | 2025-03-03 至 2025-03-14 | 具备 ETL 工具使用经验 | 内部匹配 | — | 待匹配 |
| CRM-2025-014 | 数据校验 | 能设计抽样校验规则并输出验证报告 | 1 | 2025-03-10 至 2025-03-14 | — | 临时协作 | — | 待匹配 |
逐项看这条记录：任务对象写的是可识别的任务名称，交付物列出脚本和验证报告，熟练度用“能独立编写并调试”“能设计抽样校验规则”这类行为描述，人数分别为 2 和 1，投入时段按技能分别给出，数据校验晚于脚本开发开始，符合实际工序。满足方式一项写内部匹配，一项写临时协作，替代技能只在第一项填写，因为 ETL 经验可以覆盖部分迁移脚本工作。
技能拆分的粒度以“能否据此筛选人员”为准。拆得太粗，如只写“数据能力”，匹配时无法区分迁移和校验；拆得太细，如把某个函数用法单列一行，清单会变得冗长且难以维护。示例中两项技能分别对应不同工序和不同人员，是较合适的粒度。
模板的调整与维护方法
模板拿到后不必原样照搬。调整的原则是：字段服务于匹配和排期这两个动作，新增字段要能改变某个判断，删除字段要确认没有其他角色依赖它。团队规模较小、任务类型单一时，可以合并主表与技能明细；跨项目共享资源、需要按技能检索时，保留两表结构并统一需求编号规则更合适。
- 按项目类型增字段：涉及外部供应商时增加“协作方”字段；涉及多地办公时增加“地点要求”。
- 按团队规模减字段：需求提出人固定为同一角色时可省略，改在清单说明中注明。
- 增删字段时同步更新字段说明和示例，避免模板与说明脱节。
- 状态值保持有限枚举，新增状态前先确认旧状态能否合并。
| 维护动作 | 时点 | 责任人 | 产出 |
|---|---|---|---|
| 更新需求状态 | 每周固定时间 | 需求提出人或资源协调人 | 最新状态列 |
| 核对投入时段与实际排期 | 排期变更时 | 项目负责人 | 修订后的时段与备注 |
| 清理已关闭条目 | 每月末 | 清单维护人 | 归档记录 |
| 评审字段是否仍适用 | 每季度或项目类型变化时 | 团队负责人 | 新版模板与变更说明 |
版本与历史记录建议保留两类信息：模板本身的版本，以及每条需求的变更痕迹。模板每次调整记录变更日期、调整内容和原因，旧版本存档备查；单条需求的状态变化和时段调整保留修改记录，便于回溯为什么某项技能需求被推迟或取消。清单条目多、多人同时编辑时，用文档工具承载模板和版本记录会更稳妥。
清单落地时，模板和历史版本可以放在 ONES Wiki 的页面模板库中，一键创建制式化文档，页面版本可随时查看与回滚，并按角色配置读写权限；技能条目对应的任务可在 ONES 的项目与任务场景中管理，页面组关联项目后，需求文档与工作项保持对应，减少在表格和任务系统之间重复录入。具体可用范围以团队实际开通的版本与权限为准。
常见问题
技能需求清单和岗位说明书有什么区别，能不能直接复用？
两者用途不同。岗位说明书描述一个岗位长期承担的职责与任职条件，技能需求清单描述某个任务或工作项在特定时段需要的能力、人数和投入时间。同一名员工可能同时出现在多条技能需求里，每条需求的熟练度要求和时段各不相同。
复用岗位说明书里的能力描述可以作为起点，但需要按任务重新拆成技能条目，并补上需求人数和投入时段，否则无法用于排期和匹配。
团队刚开始用这份清单，字段太多填不过来怎么办？
可以先只保留必填字段：需求编号、任务或工作项、交付物、所需技能、熟练度要求、需求人数、投入时段。这七项已经足够支撑一次基本的匹配和排期。来源依据、满足方式、替代技能、培养计划等选填字段，可以在需求评审或第一次匹配不顺利时再补。
字段精简后仍要保证口径统一，尤其是熟练度描述和投入时段的写法，否则后续补字段时会出现前后不一致的记录。
一项任务需要多项技能，需求人数应该按技能分别填还是按人填？
按技能明细行分别填写。需求人数表示具备该项技能并投入的人数，同一项任务拆出的不同技能可以有不同人数。例如迁移脚本开发需要 2 名具备 SQL 数据迁移能力的人，数据校验只需要 1 名具备校验规则设计能力的人。
如果同一个人同时满足多项技能，在各技能行分别计数即可，不必在主表另设总人数，避免两处数字对不上。
投入时段写日期还是写工作量，两种口径能混用吗？
两种口径都可以，但同一张清单内应统一。写起止日期适合排期明确、需要与人员现有安排比对的任务；写人天或人周工作量适合开始时间尚未确定、只需要估算资源缺口的情况。
混用会导致无法直接汇总，例如一部分条目按日期占用、一部分按工作量占用，计算总缺口时口径不一致。确需同时记录时，建议以日期为主字段，把工作量写进备注。
清单里的需求关闭后，记录要删除还是保留？
建议保留并归档，不直接删除。已关闭条目记录了某项技能需求曾经存在、由谁提出、最终如何满足，后续遇到类似任务时可以作为参考，也能解释某段时间的资源占用情况。
归档时可以按项目或季度分组，主清单只保留待匹配和进行中的条目，避免条目越积越多影响查阅。归档记录仍需保留需求编号，保证与历史技能明细可追溯。
