岗位能力要求应当从工作配置推导，而非从岗位名称或主观印象出发：先明确岗位要交付的成果，拆出任务、工作对象、判断点与协作接口，再逐项转化为知识、技能、经验与行为条件，形成可分级、可观察、可验证的能力条目，最终沉淀为能力字典与岗位能力卡。本文按这一路径给出五步操作流程、条目字段、角色分工、成稿示例与完成检查，适用于团队建立或修订岗位能力要求的场景；招聘考核、薪酬绩效与团队职责定义不在讨论范围。能力条目与匹配记录需要跨角色查阅和留痕时，可借助 ONES 等协作工具承载。
要点总览（TL;DR）
- 岗位能力要求从工作配置推导：先明确岗位交付成果，拆出任务、工作对象、判断点与协作接口，再转化为能力条目。
- 能力条目固定六个字段——能力名称、所属类别、适用岗位、等级、行为描述、验证方式，并区分知识、技能、经验与行为条件。
- 按五步执行：梳理任务与交付物、提取能力项并归类、定级写行为描述、多方评审修订、发布到能力字典并关联岗位。
- 用人负责人拍板等级，技术骨干把关描述，协作方核对接口，人力角色维护字典与版本记录。
- 能力要求用于人员匹配与复盘校准，可用协作工具承载条目、岗位能力卡与匹配记录。
先定工作配置：能力要求从哪里推导出来
能力要求的推导起点是岗位实际承担的工作配置，即这个岗位在业务流程中接收什么输入、完成哪些任务、向谁交付什么成果。岗位名称只能提供大致方向，真正决定能力要求的是任务本身。一个“后端开发工程师”在不同团队可能分别侧重接口性能优化、数据一致性保障或交付流水线维护，对应的能力条目差异明显。因此第一步要收集岗位近一段时间的真实任务与交付物，而不是先列能力词表。
从任务向下拆解时，重点识别三类信息：工作对象（处理的代码、文档、数据、设备或客户请求）、判断点（需要独立做出取舍或异常处置的环节）、协作接口（与哪些角色交接、以什么形式确认）。这三类信息直接对应能力条目的来源——工作对象决定知识与技能范围，判断点决定经验与行为条件，协作接口决定沟通与协作类行为要求。
完整的推导路径可以概括为四段：
- 工作配置：明确岗位在流程中的位置、输入输出与协作关系。
- 任务清单：列出主要任务及每项任务的交付物、频次与典型难点。
- 能力条目：从任务中提取所需知识、技能、经验与行为条件，去重归类。
- 分级描述：为每条能力写出不同等级下的可观察行为，形成岗位能力卡。
这条路径的价值在于可追溯：每条能力都能回答“它对应哪项任务、哪个判断点”，评审时出现争议可以回到任务清单核对，避免凭印象增删条目。
能力条目的写法：字段、分级与可观察描述
能力条目写不具体，通常是因为缺少统一字段和分级口径。建议每条能力固定包含六个字段，填写时逐项确认，缺项即视为未完成。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 能力名称 | 动宾结构，指向一类可迁移的能力 | 接口性能分析与优化 |
| 所属类别 | 知识、技能、经验或行为条件 | 技能 |
| 适用岗位 | 写明岗位及适用场景 | 后端开发工程师，交易类服务 |
| 等级 | 按团队统一级数标注 | L2 / L3 / L4 |
| 行为描述 | 可观察的动作与产出 | 能定位慢接口并给出优化方案，压测报告显示响应时间下降 |
| 验证方式 | 如何确认达到该等级 | 代码评审记录、压测报告、故障复盘 |
四类内容的区分要清楚：知识指掌握的概念与规范，如协议原理、安全规范；技能指能完成的操作，如编写压测脚本、配置监控；经验指在真实场景中处理过的问题类型与复杂度；行为条件指在协作、带教、决策中的稳定表现。混淆类别会导致定级失真，例如把“了解某框架”写成高等级能力，实际它只是入门知识。
等级划分建议采用三到四级，并为相邻等级写出差异。差异应体现在任务复杂度、独立程度和影响范围上，而不是形容词强弱。例如“接口性能分析与优化”可写为：L2 能在指导下完成单接口压测并记录数据；L3 能独立定位慢查询并完成优化，输出压测对比报告；L4 能主导跨服务性能治理，形成可复用的优化规范并指导他人。三级描述都指向具体动作和产出，评审时容易对齐。
行为描述要避免“熟悉”“精通”“较强”等无法核验的表述，改写为“在什么场景下完成什么动作、产出什么结果、由谁确认”。验证方式与行为描述同步填写，能写不出验证方式的能力条目，通常说明描述还不够具体。
确定岗位能力要求的操作步骤
以下五步按顺序执行，每步给出输入、动作、输出与完成标志。团队首次建立能力要求时建议完整走一遍，后续修订可只执行受影响步骤。
步骤一：梳理岗位任务与交付物
输入：岗位说明书、近半年任务记录、项目交付物清单。动作：访谈用人负责人与在岗人员，按频次和重要性列出主要任务，标注每项任务的交付物、协作方与典型难点。输出：任务清单，含任务描述、交付物、频次、难点。完成标志：任务覆盖岗位主要工作，用人负责人确认无重大遗漏。
步骤二：提取能力项并去重归类
输入：任务清单。动作：逐项任务提取所需知识、技能、经验与行为条件，合并表述相近的条目，按类别归组，剔除与任务无对应关系的条目。输出：能力项清单，每条注明来源任务。完成标志：每条能力可追溯到至少一项任务，无重复条目。
步骤三：定级并写行为描述
输入：能力项清单、团队等级口径。动作：为每条能力确定岗位所需等级，写出该等级及相邻等级的行为描述与验证方式。输出：带分级描述的能力条目。完成标志：相邻等级差异可用具体动作区分，验证方式可执行。
步骤四：多方评审与修订
输入：能力条目初稿。动作：组织用人负责人、技术骨干与协作方评审，逐条确认等级与描述是否符合实际工作要求，记录异议及处理结论。输出：评审记录与修订后的条目。完成标志：主要异议已闭环，评审参与方确认版本。
步骤五：发布到能力字典并关联岗位
输入：评审通过的条目。动作：将条目纳入能力字典，按岗位组装成岗位能力卡，标注版本号与生效日期。输出：能力字典更新记录、岗位能力卡。完成标志：岗位能力卡可被相关角色查阅，版本与变更记录完整。
角色分工与各环节交付物
能力要求由单一角色拍板，容易出现条目脱离实际或等级虚高。建议明确四类角色的职责边界，并在评审环节形成书面意见处理记录。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 用人负责人 | 确认任务范围与岗位目标，对最终等级拍板 | 任务清单确认、岗位能力卡定稿 |
| 技术骨干 | 提供任务难点与判断点的专业判断，撰写行为描述 | 能力条目初稿、分级描述 |
| 协作方 | 从上下游交接角度核对协作类能力要求 | 评审意见 |
| 人力角色 | 维护能力字典结构、版本与变更记录，组织评审 | 能力字典、版本记录、评审纪要 |
评审意见处理采用“记录—回应—确认”的方式：每条异议写明提出人、理由与处理结论，采纳的进入修订，不采纳的说明依据。能力字典由人力角色维护结构与版本，岗位能力卡的内容准确性由用人负责人负责，技术骨干承担描述质量的把关。岗位任务发生调整、组织合并或匹配偏差反复出现时，由用人负责人发起变更，人力角色登记版本并通知相关角色。
示例：一个研发岗位的能力要求如何成稿
以下为演示情景，用于说明从任务到能力卡的迁移方法，不代表特定企业实际标准。
某团队设置“后端开发工程师（交易服务）”岗位，主要任务包括：交易接口开发与维护、线上问题排查、参与需求评审并给出技术方案、与测试和前端协作完成联调。交付物为可上线的接口、故障处理记录、技术方案文档。典型难点是高峰期接口稳定性与数据一致性判断。
由任务提取的能力项包括：接口设计与开发（技能）、数据库与事务知识（知识）、线上故障定位与处置（经验）、技术方案表达与跨角色协作（行为条件）。定级后形成岗位能力卡片段如下：
| 能力名称 | 类别 | 岗位所需等级 | 行为描述 | 验证方式 |
|---|---|---|---|---|
| 交易接口设计与开发 | 技能 | L3 | 能独立完成交易类接口设计与实现，输出接口文档并通过评审 | 代码评审记录、接口文档 |
| 事务与数据一致性 | 知识 | L3 | 能针对典型交易场景选择事务方案，说明隔离级别与补偿策略的取舍 | 技术方案评审记录 |
| 线上故障定位与处置 | 经验 | L3 | 能独立处理交易链路常见故障，输出故障复盘并落实改进项 | 故障复盘文档 |
| 技术方案表达与协作 | 行为条件 | L2 | 能在需求评审中清晰说明方案与风险，与测试、前端确认联调计划 | 评审纪要、联调记录 |
示例中的取舍在于：该岗位不要求主导跨团队性能治理，因此相关能力不列入岗位必需等级；协作类能力定为 L2，因为岗位以执行层协作为主。边界写清楚，后续匹配评估才有稳定依据。
能力要求与人员匹配、复盘的衔接
能力要求确定后，直接用于人员匹配评估：将候选人或在岗人员的实际表现对照岗位能力卡的等级与行为描述，逐条记录证据与差距，形成匹配记录。评估时以行为描述和验证方式为准，避免只凭印象打分。匹配结果可用于工作配置，例如把高等级任务分配给达到对应等级的人员，或为差距项安排带教与练习任务。
能力条目需要持续校准。以下情况应触发修订：岗位任务范围发生实质变化；项目复盘中反复出现同类能力缺口；匹配评估中多条行为描述无法对应实际工作；组织调整导致协作接口变化。修订由用人负责人发起，按评审流程确认后更新版本。
能力字典建议按固定节奏复核，例如每半年结合项目复盘与人员匹配记录集中检查一次，重点核对等级描述是否仍与实际任务匹配、是否有条目长期未被使用。复核结论记入版本变更记录，便于追溯。
承载方式上，可将能力条目、岗位能力卡与匹配记录放入协作工具统一管理，便于跨角色查阅和版本留痕。ONES Plan 提供多项目进度管控和资源管理，其资源报表可实时反馈项目投入情况，并可直接查看 ONES Project 中的登记工时、预估工时与剩余工时数据（需同时使用 ONES Project 并产生工时数据）；ONES Performance 支持从交付效率、交付质量、资源效率、完成情况四个维度进行效能分析，并自动收录系统内流转的研发数据形成指标。这些数据可作为匹配评估与复盘校准的参考输入，具体字段与流程需按团队实际情况配置。
完成检查：能力要求是否可用
本轮能力要求是否达到可用状态，可逐项核对以下清单。任一项不通过即需返工，返工范围限于对应条目或环节。
| 检查项 | 通过标准 | 不通过时的处理 |
|---|---|---|
| 条目可观察、可验证 | 每条行为描述含具体动作与产出，验证方式可执行 | 退回步骤三重写描述 |
| 等级差异说得清 | 相邻等级可用任务复杂度、独立程度或影响范围区分 | 补充相邻等级行为对比 |
| 覆盖岗位主要任务 | 任务清单中主要任务均有对应能力条目 | 回到步骤一补任务或步骤二补条目 |
| 评审与版本记录齐全 | 评审意见有处理记录，版本号与生效日期完整 | 补齐记录后方可发布 |
| 责任人与维护机制明确 | 岗位能力卡有明确维护人，复核节奏已约定 | 指定责任人并登记复核计划 |
阻断项包括：存在无法验证的能力条目、主要任务无对应能力、评审未形成书面结论。出现任一阻断项时，岗位能力卡不进入发布环节。其余问题可作为改进项在下一轮复核中处理，但需登记在案，避免长期悬置。
常见问题
团队第一次建立岗位能力要求，五步流程可以简化吗？
可以按范围裁剪，但推导链条不宜跳过。首次建立时，步骤一（梳理任务与交付物）和步骤四（评审）建议完整执行，这两步决定条目是否贴合实际工作。步骤二、三可以先用一个岗位试点，形成条目模板后再推广到其他岗位。步骤五的发布环节即使条目较少也应保留版本号与生效日期，后续修订才有对照基准。
如果团队规模小、岗位任务相对单一，评审可以合并为一次会议完成，但异议处理仍需留下书面记录。
岗位任务经常变化，能力要求多久修订一次比较合适？
修订节奏取决于任务变化幅度，而非固定日历。出现以下情况时应立即触发修订：岗位任务范围发生实质变化、项目复盘中反复出现同类能力缺口、匹配评估中多条行为描述无法对应实际工作、组织调整导致协作接口变化。
在任务相对稳定的时期，可每半年结合项目复盘与匹配记录集中复核一次，重点检查等级描述是否仍与实际任务匹配、是否有条目长期未被使用。复核结论记入版本变更记录，便于追溯每次调整的依据。
能力条目里的等级，不同岗位之间需要统一口径吗？
需要统一的是等级的定义方式，而非每个岗位的具体等级值。团队应先约定等级划分依据，例如按任务复杂度、独立程度和影响范围区分，再让各岗位在同一口径下定级。这样“L3”在不同岗位之间才具备可比性，人员匹配和跨岗位调配才有共同语言。
如果各岗位各自定义等级，容易出现同类能力等级虚高或标准不一的问题。统一口径后，相邻等级的行为差异仍需逐条写出，评审时才能对齐。
能力要求确定后，如何避免评估时又回到凭印象打分？
关键在于把行为描述和验证方式作为评估依据，逐条记录证据与差距。评估时对照岗位能力卡的等级描述，写明实际表现对应的具体动作或产出，例如代码评审记录、故障复盘文档、评审纪要，形成匹配记录。缺少证据的条目暂不定级，补充观察后再评。
匹配记录积累后，还可以反向检验能力条目本身：如果多条描述在实际工作中找不到对应场景，说明条目需要修订，这正是复盘校准的触发条件之一。
能力条目和岗位能力卡放在哪里管理比较合适？
选择取决于查阅范围和留痕要求。条目需要跨角色查阅、版本需要追溯时，放入协作工具统一管理更便于维护；团队规模很小、变更不频繁时，结构化的共享文档也能满足基本需要。
ONES 提供项目集资源管理与效能度量能力，ONES Plan 的资源报表可实时反馈项目投入情况，并可直接查看 ONES Project 中的登记工时、预估工时与剩余工时数据（需同时使用 ONES Project 并产生工时数据）；ONES Performance 支持从交付效率、交付质量、资源效率、完成情况四个维度进行效能分析。这些数据可作为匹配评估与复盘的参考输入，具体字段与流程需按团队实际情况配置。
