产品能力地图的设计核心，是把产品集合按能力域、能力项和成熟度分层表达，再绑定到具体产品与版本上，形成一张可持续更新的结构化视图。落地时先确定分层口径和填写字段，再明确产品经理、技术负责人、业务代表的角色分工，用一份空白模板试填一条产品线，最后设定评审节奏与变更触发条件。本文按这条路径展开，覆盖分层、字段、角色、操作步骤、填写示例与维护检查；地图信息后续可在文档与工作项中持续维护，ONES 可作为承载工具之一。
要点总览（TL;DR）
- 能力地图按能力域、能力项、成熟度三层组织：能力域按业务对象或用户任务划分，能力项是能判定有无的最小能力单元，成熟度用可观察证据分级。
- 字段设计区分必填与选填，必填覆盖能力域、能力项、能力描述、承载产品、目标版本、成熟度、负责人和更新时间，选填记录判定依据与关联文档。
- 角色分工上产品经理识别能力项并初判成熟度，技术负责人核对实现归属，业务代表确认场景与证据，评审人与地图维护人职责分离。
- 首版从一条产品线起步，按圈定范围、梳理能力项、标注产品版本与成熟度、组织评审、发布并登记责任人五步推进，每步有完成标志。
- 维护靠变更触发与定期评审：新产品上线、能力下线、版本调整时更新，按季度全量核对，并用字段完整、成熟度有依据、负责人明确、版本可追溯检查验收。
能力地图先定分层口径：能力域、能力项与成熟度
能力地图的结构骨架由三层构成：能力域、能力项、成熟度。三层口径一旦确定，后续字段设计和填写才有统一基准。分层不是把现有功能清单换个名字，而是建立一套能跨产品、跨版本比较的表达方式。
能力域：按业务对象或用户任务划分
能力域是最高层分类，回答“这类能力服务于什么业务对象或用户任务”。例如订单处理、客户档案、结算对账，都是围绕业务对象或任务形成的域。划分时应避免直接照搬组织部门，因为部门会调整，能力域需要保持相对稳定；按部门划分还会导致同一能力被拆到多个域，汇总时重复计数。一个能力域通常包含若干能力项，域的数量控制在便于浏览的范围内，过多会失去分类意义。
能力项：可被产品承载的最小能力单元
能力项是地图的基本记录单位，判定标准是“可判定有无”：对某个产品，能明确回答具备或不具备。能力项描述的是稳定能力，例如“批量导入客户资料”“按账期生成对账单”，而不是某个具体需求或某次迭代任务。与需求列表的区别在于，需求会关闭、会变更，能力项长期存在；与功能清单的区别在于，功能清单按界面模块罗列，能力项按业务价值组织，一个能力项可能由多个功能共同支撑。
成熟度：用可观察的标准分级
成熟度分级建议采用三到四档，每档给出可观察的判定依据，避免凭感觉标注。常用口径如下：
| 成熟度档位 | 判定标准 | 常见误判 |
|---|---|---|
| 规划中 | 已列入产品规划，有明确的目标版本，尚无可用实现 | 把讨论中的想法标为规划中 |
| 已上线 | 目标版本已发布，能力可被用户使用 | 把内部测试通过标为已上线 |
| 已规模化 | 在多个客户或业务场景中稳定使用，有使用数据或反馈支撑 | 把单个客户试用标为已规模化 |
| 已下线 | 能力停止维护或从产品中移除，保留记录用于追溯 | 直接删除记录导致历史不可查 |
档位数量可按团队管理粒度增减，关键是每档都有可核验的证据来源，例如发布记录、使用数据或客户反馈。成熟度判定标准应写入口径说明文档，作为评审时的共同依据。
填写字段设计：一张能力地图要记录哪些信息
字段设计决定地图能否被汇总和比较。字段过少，地图退化为能力清单；字段过多，填写负担重、维护难持续。建议按“基础字段＋关联字段”组织，并明确必填与选填。
| 字段名 | 含义 | 必填性 | 取值示例 |
|---|---|---|---|
| 能力域 | 能力所属的最高层分类 | 必填 | 订单处理 |
| 能力项 | 最小能力单元名称，动词开头、可判定有无 | 必填 | 批量导入订单 |
| 能力描述 | 一句话说明能力覆盖的业务场景与边界 | 必填 | 支持从模板文件批量导入订单并校验必填字段 |
| 承载产品 | 提供该能力的产品名称 | 必填 | 订单中心 |
| 目标版本 | 能力首次可用或最近变更的版本号 | 必填 | V3.2 |
| 成熟度 | 按统一档位标注当前状态 | 必填 | 已上线 |
| 负责人 | 对该能力项信息准确性负责的人 | 必填 | 产品经理张某 |
| 更新时间 | 最近一次确认或修改的日期 | 必填 | 2025-03-14 |
| 判定依据 | 成熟度判定的证据来源 | 选填 | V3.2 发布说明、客户使用反馈 |
| 关联需求或文档 | 指向需求单、设计文档的引用 | 选填 | 需求编号、文档链接 |
字段命名与取值需要统一规范：能力域使用固定枚举值，不允许各产品线自行新增同义名称；成熟度只取口径说明中定义的档位；版本号遵循团队既有命名规则。规范的作用是保证跨产品线汇总时同一维度可对齐，否则地图只能单线阅读，无法回答“整个产品集合在哪些能力上薄弱”这类问题。
角色分工与交付物：谁填、谁审、谁用
能力地图的建设与维护涉及四类角色，职责分离可以避免“自己填、自己审”导致的信息失真。评审人与地图维护人应分开：评审人判断内容是否成立，维护人负责版本发布与变更登记。
| 角色 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 产品经理 | 产品规划、版本发布记录、需求池 | 识别能力项，初判成熟度，填写基础字段 | 能力项初稿 | 所负责产品的能力项无遗漏、字段完整 |
| 技术或架构负责人 | 系统设计文档、版本实现情况 | 核对能力项与产品实现的对应关系，确认承载产品与版本 | 核对意见 | 每条能力项的实现归属有明确结论 |
| 业务代表 | 真实使用场景、客户反馈 | 确认能力描述符合实际使用，校验成熟度证据 | 场景确认意见 | 能力描述与业务用语一致，规模化判定有依据 |
| 评审人 | 能力项初稿、核对意见 | 组织评审会，裁定争议项 | 评审结论 | 争议项全部有结论并记录 |
| 地图维护人 | 评审结论 | 发布版本、登记变更、跟踪更新责任人 | 已发布的能力地图 | 版本号与更新时间登记完整 |
角色可以由同一人兼任，但评审与维护两项职责建议分开，尤其在多产品线并行时。业务代表的参与常被忽略，缺少这一环，能力描述容易写成技术语言，地图对业务侧的可读性下降。
操作步骤：从空白模板到首版能力地图
首版建设建议从一条产品线或一组产品起步，范围过大容易在评审阶段反复。以下五步每步都有明确输入、动作与完成标志。
第一步：圈定范围
输入是产品清单与产品线划分。动作是选定一条产品线或一组关联产品，明确本次不纳入的产品并记录原因。完成标志是范围清单经产品负责人确认，参与填写的人员名单确定。
第二步：梳理能力域与能力项
输入是产品规划、现有功能清单、用户任务描述。动作是先按业务对象或用户任务列出能力域，再在每个域下拆出可判定有无的能力项，形成初稿。完成标志是初稿覆盖范围内产品的主要能力，能力项命名符合“动词开头、可判定有无”的规则。
第三步：逐项标注承载产品、版本与成熟度
输入是版本发布记录与实现文档。动作是对每条能力项标注承载产品、目标版本、成熟度和负责人，成熟度需附判定依据。完成标志是必填字段无空缺，成熟度标注均有证据来源。
第四步：组织评审并修订
输入是填写完成的初稿。动作是评审人组织产品、技术、业务三方逐域过审，记录争议项与结论，填写人按结论修订。完成标志是争议项全部关闭，修订后的版本经评审人确认。
第五步：发布首版并登记更新责任人
输入是评审通过的地图。动作是地图维护人发布首版，标注版本号与发布日期，为每个能力域登记更新责任人。完成标志是首版可被目标读者查阅，责任人名单与维护节奏同步公布。
填写示例：一条产品线的能力地图片段
以下为演示情景，用于说明字段填写与成熟度判定，不代表任何真实产品数据。
| 能力域 | 能力项 | 承载产品 | 目标版本 | 成熟度 | 负责人 | 判定依据 |
|---|---|---|---|---|---|---|
| 订单处理 | 批量导入订单 | 订单中心 | V3.2 | 已上线 | 产品经理甲 | V3.2 发布说明 |
| 订单处理 | 订单异常自动拦截 | 订单中心 | V4.0 | 规划中 | 产品经理甲 | 产品规划文档 |
| 结算对账 | 按账期生成对账单 | 结算服务 | V2.5 | 已规模化 | 产品经理乙 | 三个业务线稳定使用，有月度对账记录 |
| 结算对账 | 对账差异人工核销 | 结算服务 | V2.1 | 已下线 | 产品经理乙 | V3.0 起由自动核销替代 |
成熟度判定依据逐条对应：批量导入订单以发布说明为证，标为已上线；订单异常自动拦截仅有规划文档，标为规划中；按账期生成对账单有多个业务线的使用记录，达到规模化标准；对账差异人工核销已被新能力替代，保留记录并标为已下线，便于追溯历史版本的能力构成。
容易填错的地方有三处。一是把“已上线”写成“已完成开发”，后者可能尚未发布；二是能力描述写成功能操作步骤，失去业务语义；三是下线能力直接删除记录，导致旧版本能力无法回溯。填写时对照口径说明逐项检查，可以避免大部分偏差。
维护机制与完成检查
能力地图的价值取决于更新是否及时。首版发布后，需要设定变更触发条件和定期评审节奏，并用检查清单验收。
变更触发条件
以下情况应触发地图更新：新产品上线或新能力项纳入范围；能力下线或停止维护；目标版本调整导致成熟度变化；承载产品发生迁移。触发后由对应能力域的更新责任人修改记录，地图维护人登记变更并更新版本号。
定期评审节奏
建议按季度组织一次全量评审，核对成熟度是否与实际状态一致；版本发布频繁的产品线可缩短到月度增量核对。评审由评审人组织，产品经理提供变更说明，业务代表抽查规模化判定依据。评审结论与修订记录一并归档。
完成检查清单
- 字段完整：必填字段无空缺，选填字段按需填写。
- 成熟度有依据：每条能力项的成熟度可指向发布记录、使用数据或反馈。
- 负责人明确：每个能力域有更新责任人，每条能力项有信息负责人。
- 版本可追溯：版本号与更新时间登记完整，下线能力保留记录。
- 口径一致：能力域取值来自统一枚举，能力项命名符合规则。
地图失效的信号与纠正动作
常见失效信号包括：同一能力在不同产品线名称不一致、成熟度长期未更新、评审会连续缺席、地图与实际发布版本对不上。出现这些信号时，先缩小范围重做一条产品线的核对，再恢复全量评审；若填写负担是主因，可精简选填字段，保留必填项和判定依据，优先保证地图可持续更新。
当团队以“产品-项目”模式组织研发时，能力地图中的承载产品、版本与成熟度信息需要与项目数据保持对应。ONES Plan 的产品管理服务于这类团队，支持管理产品线并通过工作项属性跨项目管理，与 ONES Project 数据互通；地图中的能力项与版本信息可以在文档中维护，相关变更通过工作项流转和评审记录留痕。具体承载对象与字段配置范围以实际产品配置为准，建设前可先用一条产品线验证字段是否满足汇总需要。
常见问题
能力项和需求、功能清单到底怎么区分，填写时容易混在一起怎么办？
区分的关键看记录对象是否长期稳定。能力项描述产品持续具备的能力，例如“批量导入订单”，它不随某个需求关闭而消失；需求有生命周期，会关闭、会变更；功能清单按界面模块罗列，一个能力项可能由多个功能共同支撑。填写时如果一条记录能对应到某个具体需求单号，它更可能是需求而不是能力项；如果一条记录只能描述某个按钮或菜单，它更可能是功能而不是能力项。建议在口径说明中给出正反例，评审时逐条对照。
成熟度标注经常凭感觉，怎么让判定更可核验？
为每个档位绑定证据来源。规划中对应产品规划文档和目标版本；已上线对应版本发布说明；已规模化对应多个客户或业务场景的稳定使用记录；已下线对应替代能力或移除记录。填写时要求判定依据字段可指向具体文档、发布记录或使用数据，评审时抽查证据是否成立。证据缺失的条目退回补充，不直接进入发布版本。
多条产品线并行时，能力域名称各写各的，汇总对不上怎么办？
把能力域做成固定枚举值，由地图维护人统一维护，各产品线只能从中选择，不能自行新增同义名称。新增能力域需要走评审，说明与现有域的区别。能力项命名也统一规则，例如动词开头、可判定有无。这样跨产品线汇总时同一维度才能对齐，否则地图只能单线阅读，无法回答整个产品集合在哪些能力上薄弱。
首版能力地图建完后，怎么判断它是否还在有效运转？
看几个信号：同一能力在不同产品线名称是否一致，成熟度是否长期未更新，评审会是否连续缺席，地图记录与实际发布版本是否对得上。出现这些信号时，先缩小范围重做一条产品线的核对，再恢复全量评审。如果填写负担是主因，可以精简选填字段，保留必填项和判定依据，优先保证地图能持续更新。
能力地图的信息放在文档里还是工作项里维护更合适？
取决于团队已有的协作习惯和需要联动的数据。文档适合承载分层口径说明、字段规范和评审记录，便于阅读和版本留痕；工作项适合承载能力项与产品、版本、负责人的关联，便于按产品线筛选和跟踪变更。两者可以配合使用：文档维护口径与评审结论，工作项维护能力项记录。ONES 的文档与工作项管理可作为承载方式之一，具体字段配置范围以实际产品配置为准，建议先用一条产品线验证汇总需要是否满足。
