产品能力地图是把一条产品线或一组产品当前具备与规划中的能力，按业务领域、用户任务或价值链组织起来的全景视图，用来回答“我们有哪些能力、覆盖到什么程度、下一步补什么”。它和产品架构图、功能清单描述的对象层级不同：能力地图面向产品集合与能力演进，架构图面向单个产品的内部结构，功能清单面向一条条功能条目。下面给出可直接复述的定义、边界、组成方式，以及三者同口径的区分方法。
要点总览（TL;DR）
- 产品能力地图是按业务领域或用户任务组织的产品能力全景与演进视图，回答“我们有哪些能力、覆盖到什么程度、下一步补什么”。
- 能力地图面向产品集合与能力演进，产品架构图描述单个产品内部的模块与依赖，功能清单逐条罗列功能条目及其状态。
- 判断口诀：问“有哪些能力”看地图，问“怎么搭起来”看架构图，问“做了哪些功能”看清单。
- 能力地图需要固定评审节奏、版本与变更记录，并与路线图双向对应，否则容易退化成一次性汇报材料。
产品能力地图的准确定义
产品能力地图是一张按业务领域或用户任务组织的产品能力全景与演进视图。它把分散在不同产品、不同模块中的能力抽取出来，统一命名、统一分级，并标注归属产品与目标时间，让管理者在一张图上看到能力的分布、强弱和缺口。
一个可用的能力地图通常包含四类核心要素：
- 能力项：地图的基本单元，用业务语言描述“能做什么”，例如“订单拆单”“多仓库存调拨”，而不是“订单模块”。
- 能力分级或成熟度：标注每项能力当前处于什么水平，常见做法是分为规划中、建设中、已上线、领先等几档，也可以按覆盖场景的广度分级。
- 归属产品：说明这项能力由哪个产品承载、在哪些产品间共享，用于识别重复建设和能力空白。
- 时间维度：标注能力的目标时间或演进阶段，使地图能够反映“现在有什么”和“未来补什么”。
这三类要素组合起来，主要服务于三个用途：识别能力空白与重叠，支撑产品线层面的规划与投资取舍，以及在跨团队沟通中提供一张共同参照的能力底图。它描述的是产品集合层面的能力状态，不替代任何单个产品的设计文档。
它覆盖什么、不覆盖什么
能力地图的覆盖范围是产品集合层面的能力分布、覆盖程度与演进方向。判断一份材料是否属于能力地图，可以看它是否同时具备“跨产品的能力视角”和“演进时间维度”这两个特征。只有其中一个，通常属于其他管理材料。
| 内容 | 是否属于能力地图 | 说明 |
|---|---|---|
| 一条产品线在各业务领域的能力分布与强弱 | 属于 | 这是能力地图的核心内容 |
| 能力项的目标时间与演进阶段 | 属于 | 体现地图的演进属性 |
| 能力在多个产品间的共享与重叠 | 属于 | 用于识别重复建设 |
| 研发项目的投资组合与资源分配 | 不属于 | 归项目组合管理，关注投哪些项目、投多少资源 |
| 具体需求的复用与资产管理 | 不属于 | 归需求复用与资产管理，关注需求条目的沉淀与复用 |
| 单个产品内部的模块划分与技术实现 | 不属于 | 归产品架构图，关注结构关系 |
需要说明的是，这些内容与能力地图存在输入输出关系：项目组合的取舍会影响能力优先级，需求资产可以成为能力项的来源，架构图决定能力在单产品内如何落地。它们各自回答不同问题，在同一个规划流程中配合使用，不互相替代。
能力地图由哪些部分组成、如何运转
能力地图的结构通常分三层：领域、能力组、能力项。领域对应业务大板块，例如交易、履约、会员；能力组是领域下的能力聚类；能力项是最小可管理单元。分层的作用是控制颗粒度——领域层用于高层对齐，能力项层用于具体评估，避免一张图里同时出现“支付”和“支付密码找回”这种粒度悬殊的条目。
每个能力项建议维护以下字段：
- 名称与定义：用业务语言写清能力边界，避免同名不同义；
- 归属产品：标明承载产品，共享能力注明共享范围；
- 成熟度：按团队约定的档位标注当前水平；
- 目标时间：标注计划补齐或升级的时间点；
- 关联来源：指向对应的路线图条目或需求来源，便于追溯。
维护机制决定地图能否持续可用。常见做法是设定固定评审节奏，例如每季度评审一次，由产品线负责人牵头，各产品负责人更新自己名下的能力项；评审时对照路线图检查能力项的目标时间是否仍然成立，对照需求来源检查是否有新能力需要入图。地图与路线图之间保持双向对应：路线图上的事项应能落到某个能力项，能力项的变化也应反映到路线图。
版本与变更记录的作用常被低估。能力地图是演进视图，每次评审后的调整都应留下版本记录，说明哪些能力项新增、升级或降级、目标时间如何变化。这样在复盘时能回答“半年前判断的缺口是否补上”，也避免不同团队拿着不同版本的地图讨论。
在工具承载上，能力项本质是一组需要跨产品统一管理、带属性和状态的记录。ONES Plan 面向以“产品-项目”模式工作的研发团队，支持管理产品线，并通过工作项属性跨项目管理，与 ONES Project 数据互通。团队可以把能力项作为带归属产品、成熟度、目标时间属性的工作项维护在产品线下，评审结论和变更记录随工作项状态更新，使能力地图的维护与日常项目管理处在同一套数据中，减少另建表格带来的版本不一致。
与产品架构图、功能清单的边界对照
三个概念容易混用，根源在于它们都描述“产品有什么”。用同一组维度对照，差异会清晰得多。
| 对照维度 | 产品能力地图 | 产品架构图 | 功能清单 |
|---|---|---|---|
| 描述对象 | 产品集合或一条产品线的能力 | 单个产品内部的模块、层次与依赖 | 一条条功能条目 |
| 组织逻辑 | 按业务领域、用户任务或价值链 | 按系统分层与模块调用关系 | 按模块、菜单或版本归类 |
| 回答的问题 | 我们有哪些能力、覆盖到什么程度、下一步补什么 | 产品内部怎么搭起来、模块之间如何依赖 | 做了哪些功能、各自处于什么状态 |
| 主要使用者 | 产品线负责人、规划与投资决策者 | 架构师、研发负责人 | 产品经理、研发、测试、交付 |
| 更新频率 | 按规划周期评审更新，通常季度级 | 随架构调整更新，频率较低 | 随版本迭代更新，频率较高 |
从对照可以看出，三者的对象层级依次收窄：能力地图覆盖产品集合，架构图聚焦单产品结构，功能清单落到功能条目。一个实用的判断口诀是：问“我们有哪些能力”看地图，问“怎么搭起来”看架构图，问“做了哪些功能”看清单。当一份材料同时想回答两个问题时，通常需要拆成两份，否则颗粒度和读者都会错位。
还有两个常见混淆点值得单独说明。其一，能力地图与功能清单都可能出现“列表”形态，区别在于能力项用业务语言描述可交付的价值，功能条目描述具体的操作入口；一个能力项往往对应多个功能条目。其二，能力地图与架构图都可能画成方块图，区别在于方块代表的是业务能力还是系统模块，连线代表的是能力归属还是调用依赖。
具体例子与常见误解
以下为演示情景，用于说明三者如何配合，不代表真实客户案例。某团队负责一条包含三个产品的业务线，计划做年度规划。第一步，产品线负责人组织梳理能力地图，按“获客—交易—履约—服务”四个领域列出能力项，标注每项由哪个产品承载、当前成熟度和目标时间，评审后发现“跨产品统一账户”是空白、“优惠计算”在两个产品中重复建设。第二步，针对需要补齐的能力，相关产品负责人更新该产品的架构图，明确新能力落在哪个模块、与现有模块如何依赖。第三步，研发按架构方案拆分功能条目，进入功能清单跟踪开发状态。三步完成后，能力地图回答“补什么”，架构图回答“怎么搭”，功能清单回答“做到哪了”。
实际工作中，三类典型误解需要纠正：
- 把功能清单汇总当能力地图。把各产品的功能条目合并去重，得到的仍是一张功能列表：它按菜单和模块组织，缺少业务领域视角，也没有成熟度和目标时间，无法支撑“下一步补什么”的判断。纠正方法是先定义能力项，再向下关联功能条目。
- 把单产品架构图放大当产品线能力地图。架构图描述的是一个产品的模块与依赖，即使把多个产品的架构图拼在一起，得到的仍是系统结构拼图，回答不了能力在业务领域的分布与缺口。纠正方法是换用业务语言重新组织能力项。
- 把能力地图当成一次性的汇报材料。只在规划会上画一次、之后不再更新，地图很快与实际脱节，团队会退回各自的功能清单。纠正方法是把能力项纳入固定的评审节奏，保留版本与变更记录，并与路线图保持对应。
当能力项需要跨产品统一维护、评审结论需要留痕时，可以借助 ONES Plan 的产品线管理与工作项属性，把能力项、归属产品和演进状态放在同一处管理，让地图的更新跟着日常项目协作走，而不是每次汇报前重新收集。
常见问题
能力地图和产品路线图是什么关系，需要各画一份吗？
两者回答的问题不同：能力地图描述能力在业务领域的分布与成熟度，路线图描述事项在时间上的排期。实践中可以让二者保持双向对应——路线图上的事项能落到某个能力项，能力项的目标时间变化也反映到路线图。如果团队规模较小，可以把能力项作为路线图条目的属性来维护，减少两份文档不同步的成本；产品线较多、能力需要跨产品统一命名时，分开维护更清晰。
能力项应该拆到多细，和功能条目怎么衔接？
能力项用业务语言描述可交付的价值，一个能力项通常对应多个功能条目。控制颗粒度的一个实用办法是先定领域和能力组，再在能力组下拆能力项，避免同一张图里同时出现“支付”和“支付密码找回”这类粒度悬殊的条目。当某个能力项需要落地时，再向下关联具体功能条目，由功能清单跟踪开发状态。能力项过细会退化成功能列表，过粗则无法支撑缺口判断。
团队刚开始梳理能力地图，第一版应该做到什么程度？
第一版的目标是形成共同参照，不必追求完整。可以先选一条产品线，按业务领域列出主要能力项，标注归属产品与当前成熟度，目标时间可以只填近期需要补齐的几项。评审时重点确认命名是否统一、共享能力是否识别出来、明显空白是否记录在案。后续按固定节奏迭代补充，比一次性画一张大而全的图更容易持续维护。
能力地图由谁维护，产品经理各自更新自己的部分可行吗？
常见做法是由产品线负责人牵头、各产品负责人更新自己名下的能力项，再集中评审。这种方式能兼顾效率与一致性，前提是命名规则和成熟度档位事先约定清楚，否则各产品填出来的内容无法横向比较。评审时对照路线图和需求来源检查变更，评审结论与版本记录留痕，便于复盘时判断此前识别的缺口是否补上。
用表格维护能力地图和用项目管理工具维护，差别在哪里？
表格上手快，适合第一版梳理和小范围讨论；当能力项需要跨产品统一管理、带归属产品与成熟度等属性、还要随评审更新状态时，表格容易出现多版本并存、更新不同步的问题。ONES Plan 面向以“产品-项目”模式工作的研发团队，支持管理产品线，并通过工作项属性跨项目管理，与 ONES Project 数据互通，团队可以把能力项作为带属性的工作项维护在产品线下，让地图更新跟着日常项目协作走。
