产品能力地图是一份把产品能力按业务域、用户角色和成熟度分层组织的可视化清单，用来回答“我们现在能做什么、下一步补什么”。下面给出一份虚构SaaS团队的完整填写示例：先定能力域与分级口径，再逐项填写能力条目、现状证据与演进状态，最后解释每个字段的填写理由和可迁移规律。
要点总览（TL;DR）
- 产品能力地图按L1能力域、L2能力、L3子能力三层组织，示例给出5个能力域、15条能力条目的完整填写结果。
- 成熟度采用未规划、规划中、可用、成熟四档，每档以可观察的功能与文档状态为依据，现状证据只写可核验事实。
- 换团队使用时先调整能力域划分，按业务对象而非组织结构命名，并在填表前统一成熟度口径、指定交叉复核人。
- 每条能力分配稳定编号，路线图与版本计划引用同一编号，配合明确的维护人与季度复核节奏保持地图持续可用。
- 能力地图用于描述与规划产品能力集合，不替代研发项目投资组合决策，也不直接作为验收标准或绩效依据。
示例目标：这份能力地图要回答什么
本示例设定一个虚构的多产品线SaaS团队：团队同时运营三条产品线，分别面向中小客户、行业客户和平台合作方。产品负责人需要在年度规划前梳理现有能力，判断哪些能力已经可以对外承诺、哪些仍在补齐、哪些需要排入下一阶段投入。以下情景、能力条目与状态均为演示数据，不代表任何真实客户或真实产品。
这份地图要回答三个问题：第一，能力覆盖范围，即三条产品线合起来覆盖了哪些业务域，是否存在明显空白；第二，各能力成熟度，即每项能力当前处于什么水平，有没有可观察的证据支撑；第三，演进优先级，即哪些能力需要优先投入、目标阶段放在哪里。三个问题对应地图的三类字段：能力域与能力条目、成熟度与现状证据、演进状态与目标阶段。
示例的边界需要提前说明：本文只做能力集合的梳理与演进描述，不涉及研发项目投资组合的取舍，也不展开需求复用与资产管理。能力地图回答“产品能做什么”，项目组合回答“资源投到哪里”，两者相邻但管理对象不同。
| 背景项 | 示例设定 |
|---|---|
| 对象 | 虚构的多产品线SaaS团队，三条产品线共享账号、数据与集成底座 |
| 要回答的问题 | 能力覆盖范围、各能力成熟度、演进优先级 |
| 用途 | 年度规划前的能力盘点，作为路线图讨论的输入 |
| 边界 | 只梳理能力集合与演进状态，不涉及项目投资组合与需求复用 |
完整示例：一张填好的产品能力地图
能力地图采用三层结构：L1为能力域，按业务对象划分，例如账号与权限、数据接入；L2为能力条目，是地图的基本填写单位，每条对应一类可被用户感知的产品能力；L3为子能力，用于在条目下细分具体场景，填写时按需展开，不必每条都拆到L3。下表为L2层级的完整填写结果，共5个能力域、15条能力条目，均为示例数据。
| 能力域（L1） | 能力名称（L2） | 服务对象 | 成熟度 | 现状证据 | 演进状态 | 目标阶段 |
|---|---|---|---|---|---|---|
| 账号与权限 | 组织架构同步 | 企业管理员 | 成熟 | 已上线目录同步，支持增量同步与失败重试，帮助文档含配置步骤 | 维持 | 保持现有水平 |
| 账号与权限 | 角色权限配置 | 企业管理员 | 成熟 | 已上线角色模板与字段级权限，权限变更留操作记录 | 维持 | 保持现有水平 |
| 账号与权限 | 单点登录 | 企业管理员、IT负责人 | 可用 | 已支持标准协议登录，配置文档齐全，异常排查依赖人工 | 优化 | 下一阶段补齐自助排查 |
| 数据接入 | 批量文件导入 | 业务运营人员 | 成熟 | 已上线模板导入与错误行回显，单次导入量有明确上限说明 | 维持 | 保持现有水平 |
| 数据接入 | API数据同步 | 技术集成方 | 可用 | 已开放主要对象读写接口，接口文档覆盖鉴权与限流说明 | 优化 | 下一阶段补充增量同步 |
| 数据接入 | 第三方应用连接器 | 技术集成方、业务运营人员 | 规划中 | 已完成连接器方案评审，尚无上线功能 | 新建 | 本年度内上线首批连接器 |
| 报表分析 | 标准报表 | 业务运营人员、管理者 | 成熟 | 已上线固定报表集，支持时间范围筛选与导出 | 维持 | 保持现有水平 |
| 报表分析 | 自定义报表 | 业务运营人员 | 可用 | 已支持选择字段与聚合方式，复杂计算需人工预处理 | 优化 | 下一阶段支持常用计算字段 |
| 报表分析 | 数据订阅推送 | 管理者 | 未规划 | 无上线功能，仅在用户访谈中记录需求 | 待评估 | 视优先级决定是否立项 |
| 开放集成 | Webhook事件通知 | 技术集成方 | 可用 | 已上线主要业务事件推送，支持重试与投递记录查询 | 维持 | 保持现有水平 |
| 开放集成 | 开放平台应用管理 | 技术集成方、平台合作方 | 规划中 | 已完成应用注册与授权流程设计，开发中 | 新建 | 下一阶段开放试用 |
| 开放集成 | 沙箱测试环境 | 技术集成方 | 未规划 | 无独立沙箱，集成方在测试组织内验证 | 待评估 | 随开放平台一并评估 |
| 运营后台 | 租户与套餐管理 | 内部运营人员 | 成熟 | 已上线租户开通、套餐变更与到期提醒，操作有审计日志 | 维持 | 保持现有水平 |
| 运营后台 | 用量统计 | 内部运营人员、管理者 | 可用 | 已上线核心用量指标看板，部分指标按日汇总 | 优化 | 下一阶段提升统计粒度 |
| 运营后台 | 公告与消息触达 | 内部运营人员 | 规划中 | 已完成触达渠道选型，尚未进入开发 | 新建 | 下一阶段完成首版 |
从表中可以看出地图的分层逻辑：能力域回答“这块业务归谁管”，能力条目回答“具体能做什么”，成熟度与证据回答“做到什么程度”，演进状态与目标阶段回答“接下来怎么走”。同一能力域内的条目可以处于不同成熟度，例如开放集成域中既有可用的Webhook通知，也有尚未规划的沙箱环境，这种差异正是地图要暴露的信息。
逐项解释：每个字段为什么这样填
成熟度采用四档口径，每档都有可观察的判断依据，避免不同产品线各说各话。未规划指没有上线功能、也没有进入排期，仅有需求记录；规划中指方案已评审或已进入开发，但用户还无法使用；可用指功能已上线、主要场景能跑通，但存在已知限制或依赖人工兜底；成熟指功能稳定、文档齐全、异常场景有处理路径，可以对外承诺。示例中“单点登录”填可用而非成熟，原因是异常排查仍依赖人工，这一限制写进了现状证据。
现状证据一栏只写可观察的事实：已上线的功能行为、对外文档、操作记录、明确的限制说明。示例中“已上线模板导入与错误行回显”“接口文档覆盖鉴权与限流说明”都属于可核验的描述；相反，“体验良好”“行业领先”这类主观评价不进入证据栏。证据的作用是让读表的人不必依赖填写者的判断，也能复核成熟度定级是否合理。
演进状态与目标阶段要和路线图节奏对应。示例用维持、优化、新建、待评估四种状态：维持表示保持现有水平、不安排增量投入；优化表示在现有能力上补齐短板；新建表示从规划中走向上线；待评估表示尚未决定是否投入。目标阶段写相对时间，例如“下一阶段”“本年度内”，与团队自己的规划周期对齐，不写具体日期，避免地图变成排期表。
服务对象字段用来防止能力条目退化成功能清单。填写时先问“这项能力为谁解决什么问题”，再给能力命名。例如“角色权限配置”的服务对象是企业管理员，说明它解决的是管理侧的授权问题；如果只写“权限模块”，读表人就无法判断这项能力对哪类用户有价值。服务对象可以写角色，也可以写内外部用户类型，同一能力服务多类对象时并列写出。
| 字段 | 填写口径 | 常见错误 |
|---|---|---|
| 成熟度 | 四档定级，依据可观察的功能与文档状态 | 按投入人力或开发时长定级 |
| 现状证据 | 写已上线行为、文档、限制说明 | 写主观评价或未来承诺 |
| 演进状态 | 维持、优化、新建、待评估四选一 | 与目标阶段重复表述 |
| 目标阶段 | 相对规划周期，与路线图节奏一致 | 写成具体交付日期 |
| 服务对象 | 写角色或用户类型，说明解决谁的问题 | 只写功能名，不写服务对象 |
可迁移规律：换一个团队怎么改这份示例
换团队使用时，能力域的划分方式最需要先调整。示例按账号与权限、数据接入、报表分析、开放集成、运营后台划分，依据是业务对象而非组织结构；如果换成按团队划分，例如“平台组能力”“应用组能力”，地图会随组织调整频繁失效，也无法暴露跨产品线的能力空白。判断方法很简单：能力域的名称应当能在不提及任何团队的情况下被理解。
成熟度口径要在填表前统一。多产品线团队容易出现各产品线自评标准不一的情况，例如同样叫“可用”，一条产品线指功能上线，另一条指通过验收。可行做法是先由产品负责人牵头确定四档定义和每档的判断依据，各产品线按同一口径填写，再由一人交叉复核定级。口径统一后，地图上的成熟度分布才有比较意义。
地图条目要与路线图、版本计划使用同一套能力编号。示例中每条能力可以编为“域缩写-序号”，例如账号与权限域的第一条编为AC-01。路线图条目引用能力编号，版本计划中的交付项也引用同一编号，这样从地图可以直接追踪某项能力在哪个阶段被推进、当前进展如何。编号一旦启用，能力改名时保留编号，避免历史记录断链。
复核机制决定地图能否持续可用。建议明确一名地图维护人，负责汇总各产品线的填写与变更；更新频率与规划节奏对齐，例如每季度复核一次，重大能力上线时即时更新；每次变更记录变更人、变更字段和原因，保留历史版本。维护人不必是产品负责人，但需要有跨产品线收集信息的权限。
当团队使用 ONES Plan 管理产品线时，能力地图的维护可以与产品管理工作衔接：ONES Plan 服务于以“产品-项目”模式工作的研发团队，支持管理产品线并通过工作项属性跨项目管理，与 ONES Project 数据互通。团队可以把能力条目作为工作项登记，用自定义项目属性标注能力域、成熟度与目标阶段，在多项目视图中查看各产品线的能力推进情况。这样地图的复核与路线图讨论共用同一份数据，减少表格与项目系统之间的手工同步。
- 能力域按业务对象命名，名称脱离团队名称仍可理解
- 填表前统一成熟度四档定义与判断依据，指定一人交叉复核
- 每条能力分配稳定编号，路线图与版本计划引用同一编号
- 明确地图维护人与更新频率，变更留记录并保留历史版本
- 能力改名保留原编号，新增能力按域内顺序续编
适用边界：能力地图不适合承担什么
能力地图关注产品能力集合的演进，回答“有什么、到什么程度、下一步补什么”。研发项目投资组合要回答的是另一类问题：有限资源在多个项目之间如何分配、哪些项目暂缓、整体投入产出如何平衡。两者可以互相参考，但能力地图不提供资源分配结论，也不能替代投资组合决策。把地图直接当成投资决策依据，容易把“能力重要”误读为“项目该立项”。
具体需求复用与资产管理属于另一类管理对象。需求复用关注同一需求在多个产品线之间如何识别、沉淀和引用，资产管理关注需求与能力之间的对应关系如何维护。这些工作有自己的管理流程和记录方式，不在地图内展开。地图中可以标注某项能力被多条产品线共用，但共用关系的具体管理仍回到需求管理流程中处理。
能力地图是描述与规划工具，不能直接当作验收标准或绩效依据。成熟度定级反映的是填写时点的能力状态，带有判断成分；验收标准需要可测试的条目，绩效依据需要与岗位职责对应的指标，两者都比地图字段更具体。若团队希望用地图驱动考核，需要另行设计可量化的指标，并明确数据来源。
最后需要再次说明：本文的能力条目、成熟度与演进状态均为演示数据，用于说明填写方法，不代表任何真实产品的实际能力。读者迁移使用时，应以自己团队的实际功能、文档和规划为准，重新填写每一项证据与状态。
常见问题
能力地图里的成熟度定级由谁来判断，出现分歧怎么办？
成熟度定级通常由各产品线的产品负责人初评，再由一名跨产品线的复核人交叉核对。出现分歧时，回到现状证据逐条对照：功能是否已上线、主要场景能否跑通、文档是否齐全、异常场景是否有处理路径。证据不足以支撑较高档位时，按较低档位填写，并把缺口写进现状证据。示例中“单点登录”定为可用而非成熟，就是因为异常排查仍依赖人工，这一限制被明确记录，复核时无需再争论。
能力条目和路线图条目需要一一对应吗？
不需要一一对应。一条能力可能跨越多个阶段推进，一个阶段也可能同时推进多条能力。可行的做法是让路线图条目引用能力编号，而不是让两者数量对齐。这样从地图可以看到某项能力被安排在哪个阶段，从路线图也能反查它对应哪条能力。尚未排期的能力保留在地图中，演进状态填待评估，不强行塞进路线图。
多条产品线共用同一项能力时，地图上要重复填写吗？
建议只填一条能力条目，在服务对象中并列写出各产品线的用户类型，并在备注中说明共用关系。重复填写会让同一能力出现多个成熟度定级，反而制造混乱。共用关系的具体管理，例如需求如何在产品线之间识别和引用，回到需求管理流程处理，地图只负责标注这项能力被多条产品线依赖。
地图更新频率应该跟着版本发布走，还是按固定周期复核？
两者结合更稳妥。固定周期复核保证地图不会长期失修，例如与季度规划节奏对齐，每季度整体过一遍；重大能力上线或下线时即时更新对应条目，避免地图与实际情况脱节。每次变更记录变更人、变更字段和原因，保留历史版本，便于回溯某项能力的定级为何调整。
团队已经在用项目管理工具，能力地图还要单独维护一张表吗？
取决于团队已有的管理方式。若项目管理工具支持登记工作项并自定义属性，可以把能力条目作为工作项登记，用属性标注能力域、成熟度与目标阶段，在多项目视图中查看推进情况，减少表格与系统之间的手工同步。以 ONES Plan 为例，它服务于以“产品-项目”模式工作的研发团队，支持管理产品线并通过工作项属性跨项目管理，与 ONES Project 数据互通。是否迁移到工具中维护，要看团队规模与复核频率，条目较少时表格也能满足需求。
