岗位能力要求示例的价值，在于把“这个人能不能承担这类任务”从印象判断变成可对照的清单。本文给出一份虚构的“项目型产品经理”岗位能力要求填写示例，按能力维度列出行为描述、熟练等级、核验方式和对应工作项，并逐项说明写法依据、可迁移到其他岗位的改写步骤，以及这份示例不适合直接照搬的场景。
要点总览（TL;DR）
- 岗位能力要求示例按“能力维度—能力项—行为描述—熟练等级—核验方式—对应工作项”六列组织，可直接对照填写。
- 行为描述写可观察的动作和产出物，熟练等级按独立承担、指导下完成、可指导他人三层划分，等级与核验证据成对出现。
- 换成其他岗位时，先列关键任务再倒推能力项，单个岗位能力项控制在十项左右，维度保持三到五个。
- 这份示例用于工作配置与任务匹配，不用于招聘筛选、绩效考核，也不替代团队职责分工文档。
- 能力项与工作项的对应关系可在项目管理工具中落地，ONES Resource 和 ONES Plan 的工时与投入数据可作为分派参考。
这份示例要解决什么问题
这份示例面向工作配置场景：团队在分派任务、组建项目组或评估某位成员能否接手一类工作时，需要一份能对照的能力清单。它回答的问题具体到“谁能做需求评审”“谁能独立推进跨团队方案对齐”，而非笼统的“这个人能力如何”。填写目标有三条：能力项可观察，即描述的是看得见的动作和产出；可核验，即每项能力都能找到对应的证据；可用于任务分派，即能力项能和工作项建立对应关系，分派时直接比对。
需要说明的是，本文的岗位、人员、项目背景均为虚构情景，不对应任何真实企业或员工，其中的等级划分和核验方式仅作示范。拿到示例后，建议按以下方式使用：先通读表格理解字段结构，再对照本岗位的实际任务替换能力项内容，最后结合本组织的项目节奏调整熟练等级和核验证据。示例提供的是填写框架和判断逻辑，具体内容需要按岗位重新拆解。
完整示例：项目型产品经理岗位能力要求
下表是一份填写完成的岗位能力要求示例，能力维度覆盖业务理解、需求分析、方案表达、协作推进、工具使用五个方面。每个能力项都包含能力名称、行为描述、熟练等级、核验方式和对应工作项，可直接作为对照填写的模板。
| 能力维度 | 能力项 | 行为描述 | 熟练等级 | 核验方式 | 对应工作项 |
|---|---|---|---|---|---|
| 业务理解 | 业务背景梳理 | 能独立访谈业务方，输出包含目标用户、核心流程、关键约束的业务背景说明，并标注待确认问题 | 独立承担 | 业务背景说明文档；访谈记录 | 项目立项背景调研 |
| 业务理解 | 行业与竞品分析 | 能在指导下完成指定方向的竞品功能对比，形成对比表并给出差异结论 | 指导下完成 | 竞品对比表；评审意见 | 版本规划前的竞品调研 |
| 需求分析 | 需求拆解 | 能将业务目标拆成可交付的需求条目，每条需求写明使用场景、验收要点和优先级依据 | 独立承担 | 需求清单；需求评审记录 | 需求池梳理与排期 |
| 需求分析 | 需求优先级判断 | 能组织需求评审会，按价值和成本给出排序建议，并记录分歧点与最终结论 | 可指导他人 | 评审会议记录；排期结果 | 迭代范围确定 |
| 方案表达 | 方案文档撰写 | 能输出包含流程说明、界面示意、异常分支处理的方案文档，评审前完成自检清单 | 独立承担 | 方案文档；评审通过记录 | 功能方案设计 |
| 方案表达 | 方案讲解 | 能向研发、设计、测试讲清方案目标与边界，回答评审中的疑问并当场记录待办 | 独立承担 | 评审记录；待办清单 | 方案评审会 |
| 协作推进 | 跨团队对齐 | 能识别依赖方，主动发起对齐会议，输出含责任人和时间点的对齐结论 | 指导下完成 | 对齐会议纪要；依赖清单 | 跨团队联调协调 |
| 协作推进 | 进度跟踪与风险上报 | 能按周更新任务状态，对延期任务说明原因、影响和应对方案 | 独立承担 | 周报；风险记录 | 迭代进度跟踪 |
| 工具使用 | 需求与任务管理工具 | 能在项目管理工具中维护需求状态、拆分任务、关联文档，保持状态与实际一致 | 独立承担 | 工具中的需求与任务记录 | 需求流转与任务分派 |
| 工具使用 | 数据与报表查看 | 能查看项目投入与工时数据，识别成员负载异常并向负责人反馈 | 指导下完成 | 资源报表；反馈记录 | 迭代资源盘点 |
这张表的关键在于每一行都能落到具体证据上：行为描述写的是动作和产出物，熟练等级说明承担方式，核验方式指向可以调取的文档或记录，对应工作项则把能力与项目中的实际任务挂钩。分派任务时，负责人可以按工作项反查所需能力项，再对照成员的能力记录判断匹配度。
逐项解释：每条能力要求为什么这样写
表格看起来整齐，填写时的判断才是难点。以下按字段拆解示例中的关键选择，并给出常见失效写法作对照。
行为描述：写动作和产出，不写形容词
“沟通能力强”“有责任心”这类表述无法观察，也无法核验，不同人对同一个词的理解差异很大。示例中的写法是把能力落到动作和产出物上，例如“能组织需求评审会，按价值和成本给出排序建议，并记录分歧点与最终结论”。这句话包含三个可检查的点：是否组织了评审、是否给出排序建议、是否留下记录。反例是“具备优秀的沟通协调能力”，评审组织得好不好、结论有没有落地，都无从判断。
熟练等级：按承担方式分三层
示例把熟练等级分为独立承担、指导下完成、可指导他人三层。这个划分的依据是任务承担方式，而非主观评分。“独立承担”意味着不需要他人把关即可交付；“指导下完成”意味着需要有人给出方向或复核；“可指导他人”意味着能带别人做同类任务，并能处理其中的争议。三层之间是递进关系，填写时要问自己：这项任务交给此人，需要别人投入多少复核精力。等级写虚了，分派时就会高估或低估成员。
核验方式：每项能力都要有证据来源
核验方式回答“凭什么说这项能力达标”。示例中的证据类型包括产出文档、评审记录、会议纪要、任务结果和工具中的状态记录。填写时要注意证据与能力项的对应关系：需求拆解对应需求清单和评审记录，进度跟踪对应周报和风险记录。如果一项能力找不到任何可调取的证据，说明行为描述写得还不够具体，需要回到上一步修改。
对应工作项：让能力清单进入分派流程
能力项如果只停留在文档里，分派任务时仍然靠印象。示例为每个能力项标注了对应工作项，例如“需求优先级判断”对应“迭代范围确定”。这样在组建迭代团队时，可以先列出本迭代的关键工作项，再反查所需能力项，形成一张匹配对照。能力项与工作项的对应关系可以在项目管理工具中落地：把工作项维护在项目里，把成员的能力记录作为分派参考，任务状态和工时数据则作为能力表现的补充信息。ONES Resource 支持通过工作数量和工时规模了解成员排期，并可按筛选与分组查看成员在不同项目的投入比重，这类数据能在分派时提供参考；ONES Plan 可查看 ONES Project 中的登记工时、预估工时和剩余工时数据，需与 ONES Project 配合使用。工具数据反映的是投入情况，能力判断仍以能力清单和核验证据为准。
可迁移规律：换一个岗位怎么改
示例针对的是项目型产品经理，换成测试、设计、运营或研发岗位时，框架不变，内容需要重新拆解。以下步骤可以直接套用。
- 先列岗位关键任务。收集该岗位近一个项目周期内实际承担的任务，按发生频率和影响范围排序，选出五到八项关键任务。任务描述用动宾结构，例如“编写测试用例”“组织版本发布”。
- 从任务倒推能力项。对每项关键任务问三个问题：完成它需要哪些判断、需要产出什么、需要和谁配合。答案分别对应能力项中的行为描述、核验方式和工作项关联。
- 控制能力项数量。单个岗位的能力项建议控制在十项左右，维度三到五个。清单过长会导致维护成本上升、填写流于形式；可以合并相近能力项，把低频任务放到岗位说明中另行描述。
- 等级与核验成对填写。每写一个熟练等级，紧接着写对应的核验证据，两者缺一不可。等级没有证据支撑，分派时就无法使用；证据没有等级对应，也无法判断承担方式。
- 按任务变化定期更新。项目类型、协作方式或工具发生变化时，回看能力项是否仍然对应实际任务。建议在每个项目周期结束时做一次小范围修订，删去不再出现的工作项，补充新增任务对应的能力项。
改写时还要注意维度命名的稳定性。业务理解、需求分析、方案表达、协作推进、工具使用这五个维度对多数项目型岗位都适用，换岗位时优先替换维度下的能力项，保持维度结构一致，便于跨岗位对照和团队层面的能力盘点。
适用边界：这份示例不适合直接照搬的地方
这份示例服务于工作配置与任务匹配，用途边界需要说清楚。它不用于招聘筛选或面试评估：招聘关注的是候选人潜力和岗位适配，评估口径、面试问题和录用标准属于另一套方法，直接拿能力清单当面试评分表，容易把可观察的行为描述变成主观打分。它也不用于绩效考核：绩效涉及目标达成、贡献评价和激励分配，能力等级只是其中一类参考信息，不能替代绩效制度。
团队角色与职责分工定义同样不在本示例范围内。职责分工文档回答“谁负责什么”，通常按团队或职能划分；能力要求回答“谁能承担什么任务”，按能力项组织。两类文档可以互相引用，但结构和用途不同，混在一起会让分派和职责界定都变得模糊。
不同行业与岗位的任务差异需要重新拆解能力项。示例中的“竞品对比表”“方案评审会”等项目型产品经理的典型产出，换到制造、销售或职能岗位未必成立，行为描述和核验方式都要按实际任务重写。示例中的熟练等级划分和核验证据类型也需要结合本组织的项目节奏、文档习惯和评审机制调整：评审流程较少的团队，可以把核验方式换成任务结果或交付物验收记录。调整时保持“行为描述可观察、等级有证据、能力项对应工作项”这三条不变，清单就能在实际分派中发挥作用。
常见问题
能力项写多少条比较合适，维度怎么定？
单个岗位的能力项建议控制在十项左右，维度三到五个。判断依据是这份清单能否被持续维护：条目过多，填写和更新会流于形式；条目过少，又无法覆盖关键任务。维度命名尽量保持稳定，例如业务理解、需求分析、方案表达、协作推进、工具使用，换岗位时优先替换维度下的能力项，便于跨岗位对照。
熟练等级只有三层，遇到介于两层之间的成员怎么填？
三层划分的依据是任务承担方式，而非主观评分。遇到拿不准的情况，可以问一个具体问题：这项任务交给此人，需要别人投入多少复核精力。需要方向指导或成果复核的，填“指导下完成”；不需要他人把关即可交付的，填“独立承担”。如果同一能力项下不同任务的承担方式差异较大，可以拆成两个能力项分别填写，避免用一个等级笼统覆盖。
核验方式找不到现成证据怎么办？
先回到行为描述检查是否写得足够具体。证据找不到，通常说明描述还停留在形容词层面。把行为描述改成包含动作和产出物的表述，例如从“具备方案表达能力”改为“能输出含流程说明和异常分支处理的方案文档”，对应的证据自然就出现了，比如方案文档和评审通过记录。若任务本身很少留下文档，可以用任务结果、交付物验收记录或工具中的状态记录作为证据来源。
能力清单和团队职责分工文档有什么区别，需要合并吗？
两类文档回答的问题不同：职责分工回答“谁负责什么”，通常按团队或职能划分；能力要求回答“谁能承担什么任务”，按能力项组织。它们可以互相引用，但结构和用途不同。合并在一起会让任务分派和职责界定都变得模糊，建议分开维护，在分派任务时同时参考。
能力清单多久更新一次，由谁维护？
建议在每个项目周期结束时做一次小范围修订，删去不再出现的工作项，补充新增任务对应的能力项。触发更新的信号包括项目类型变化、协作方式调整、工具更换。维护责任可以放在直接分派任务的负责人身上，因为其最清楚任务与能力的对应关系是否仍然成立。修订时保持“行为描述可观察、等级有证据、能力项对应工作项”这三条不变。
