共性能力复用机制要解决的是多个产品线重复建设同一能力、复用范围说不清、出问题找不到负责人的问题。本文用一份演示情景给出可直接参照的填写示例：某公司产品线从三条扩展到五条时，把统一权限、消息通知、报表导出三项能力纳入同一份能力清单，并配套接入申请与变更通知记录，逐项说明字段取值和迁移方法。
要点总览（TL;DR）
- 共性能力复用机制的核心，是把多条产品线反复需要的能力抽成独立单元，用一份能力清单记录归属、覆盖范围、接口约定、版本策略和维护责任人。
- 示例以产品线从三条扩展到五条为演示情景，把统一权限、消息通知、报表导出三项能力纳入清单，并配套接入申请记录与变更通知记录，形成最小闭环。
- 清单字段要能回答三个问题：能力有唯一归属、复用范围可查、变更有人负责；状态至少区分孵化、稳定、退役三档，避免所有能力都标“可用”。
- 迁移到其他团队时，先圈定能力边界再设计字段，按产品线数量与差异度确定复用粒度，用申请与变更两个动作维持清单活性，从三项左右能力起步。
- 这份示例适用于产品集合演进中的能力沉淀；产品线差异极大、能力尚不稳定或条目增长过快时，需要缩小范围、限制接入或按领域拆分清单。
示例要解决什么问题：三条产品线各自造轮子的困境
先交代这份示例的情景设定。以下内容为演示情景，用于说明共性能力复用机制的填写方式，不代表真实客户案例，也不附带量化成效。
某公司的产品集合从三条产品线扩展到五条。扩展之前，每条产品线各自实现登录鉴权、站内消息推送和报表导出，三套代码逻辑相似但细节不同。扩展到五条后，重复建设的问题被放大：同一类权限模型要维护五份，消息通道升级要改五个地方，报表导出的格式规范各写各的。团队希望建立一套共性能力复用机制，让这类能力只建设一次、按约定被多条产品线接入。
这份示例的目标很具体：用一份能力清单，让复用有据可查、有主可找。所谓有据可查，是任何一条产品线想知道某项能力是否已有统一实现、能否接入、接入哪个版本，查清单即可；所谓有主可找，是能力出问题、要变更、要下线时，能直接定位到归属团队和责任人。
判断这套机制是否真的可用，可以看三个观察点：
- 能力有唯一归属：每项共性能力只对应一个归属团队，避免多头维护或无人认领。
- 复用范围可查：清单能回答“哪些产品线在用、是全量复用还是按需接入”。
- 变更有人负责：接口调整、版本升级、能力退役都有明确的责任人和通知动作。
这三个观察点也是后文检查示例是否自洽的标准。清单字段再多，如果回答不了这三个问题，机制就还停留在文档层面。
完整示例：一份填好的共性能力复用清单
下面是填好的能力清单。五条产品线分别记为产品线A至产品线E，其中A、B、C为原有产品线，D、E为新增产品线。三项共性能力在扩展时统一纳入清单管理。
| 能力名称 | 能力编号 | 归属团队 | 覆盖产品线 | 接口形式 | 版本策略 | 接入方式 | 维护责任人 | 状态 |
|---|---|---|---|---|---|---|---|---|
| 统一权限 | CAP-AUTH-01 | 基础平台组 | A、B、C、D、E（全量） | SDK + HTTP API | 语义化版本，主版本升级提前一个迭代通知，旧主版本保留两个迭代 | 引入SDK并完成租户与角色映射配置 | 基础平台组权限方向负责人 | 稳定 |
| 消息通知 | CAP-MSG-02 | 基础平台组 | A、B、D（全量）；C、E（按需接入站内信） | 消息队列主题 + 发送API | 主题与消息体字段向后兼容，新增字段默认值由消费方约定 | 申请主题订阅权限，按消息体规范对接 | 基础平台组消息方向负责人 | 稳定 |
| 报表导出 | CAP-RPT-03 | 数据服务组 | A、C、E（按需接入） | 导出服务API + 模板规范 | 模板规范按季度评审，接口小版本内保持兼容 | 提交导出模板，评审通过后开通调用配额 | 数据服务组报表方向负责人 | 孵化 |
三项能力的覆盖范围刻意做了区分：统一权限是五条产品线都需要的底座能力，全量复用；消息通知在部分产品线只用到站内信，因此按需接入；报表导出尚在孵化，先由三条产品线试点，稳定后再扩大范围。
配套的接入申请记录示例如下，用于记录某条产品线申请接入一项能力的过程：
| 记录项 | 填写内容 |
|---|---|
| 申请编号 | REQ-2024-017 |
| 申请产品线 | 产品线D |
| 申请能力 | CAP-MSG-02 消息通知 |
| 接入范围 | 站内信通道，暂不接入短信与邮件 |
| 申请理由 | 新增产品线需要站内通知，复用统一通道避免自建推送服务 |
| 评估结论 | 通过，按现有消息体规范对接，无需扩展字段 |
| 归属团队确认 | 基础平台组消息方向负责人确认 |
| 预计接入时间 | 下一个迭代内完成联调 |
配套的变更通知示例如下，用于记录一次影响多条产品线的能力变更：
| 记录项 | 填写内容 |
|---|---|
| 通知编号 | CHG-2024-006 |
| 涉及能力 | CAP-AUTH-01 统一权限 |
| 变更内容 | 新增角色继承规则，主版本号升级 |
| 影响范围 | 产品线A、B、C、D、E全部接入方 |
| 兼容说明 | 旧主版本保留两个迭代，期间新旧版本并行 |
| 接入方动作 | 各产品线在两个迭代内完成角色配置迁移并回归验证 |
| 责任人 | 基础平台组权限方向负责人 |
| 通知时间 | 变更上线前一个迭代发出 |
这三份记录构成一个最小闭环：清单说明有什么、谁能用；申请记录说明某条产品线如何获得使用权；变更通知说明能力演进时如何同步到所有接入方。清单中的覆盖产品线数量与情景中的五条产品线一致，状态字段也与实际进展对应——统一权限已稳定运行，消息通知稳定但存在按需接入的差异，报表导出仍在孵化。
逐项解释：每个字段为什么这样填
清单的价值取决于字段能否支撑判断。下面逐项说明示例取值的理由，并给出常见的错填方式作对照。
| 字段 | 示例取值 | 填写理由 | 常见错填 |
|---|---|---|---|
| 能力编号 | CAP-AUTH-01 | 给每项能力一个稳定标识，申请、变更、问题单都引用同一编号，避免同名能力混淆 | 只写能力名称，或编号随版本变化，导致历史记录对不上 |
| 归属团队 | 基础平台组 | 回答“找谁”，一项能力只对应一个团队，责任不分散 | 写多个团队共同负责，实际无人牵头 |
| 覆盖产品线 | A、B、C、D、E（全量） | 区分全量复用与按需接入，让接入方知道自己是标准场景还是特例 | 只写“多条产品线”，无法判断谁在用、谁该被通知 |
| 接口形式 | SDK + HTTP API | 说明接入方以什么方式使用能力，决定联调工作量和技术选型 | 写“提供接口”这类无法指导接入的表述 |
| 版本策略 | 主版本升级提前一个迭代通知，旧版本保留两个迭代 | 把兼容承诺写成可执行的时间约定，接入方据此安排升级 | 写“保持兼容”但不说明兼容多久、如何通知 |
| 接入方式 | 引入SDK并完成租户与角色映射配置 | 把复用落到具体动作，接入方照着做即可，减少来回沟通 | 只写“申请接入”，不说明申请后要做什么 |
| 维护责任人 | 基础平台组权限方向负责人 | 责任落到具体角色，变更通知和问题响应有明确对象 | 只写团队名，出问题时仍需二次询问 |
| 状态 | 稳定 / 孵化 / 退役 | 区分能力成熟度，孵化期控制接入范围，退役期安排迁移 | 所有能力都标“可用”，接入方无法判断风险 |
几个字段之间存在配合关系，填写时需要一起考虑。能力编号与归属团队共同解决“找谁”的问题：编号用于检索，团队用于对接。覆盖产品线与状态共同决定复用范围：孵化状态的能力即使列入清单，也应限制接入产品线数量，示例中报表导出只开放三条产品线正是这个考虑。接口形式与版本策略共同构成兼容承诺：接口形式说明怎么用，版本策略说明升级时接入方有多少缓冲时间，两者缺一，接入方就无法评估长期维护成本。
接入方式与维护责任人需要写成可执行的动作和可定位的角色。示例中“引入SDK并完成租户与角色映射配置”是可以直接排进迭代的任务描述，而“申请接入”只是流程起点。责任人写到方向负责人而非团队名，是为了让变更通知有明确的发出方和接收确认方。
状态字段容易被简化成“可用/不可用”两档，实际至少需要孵化、稳定、退役三档。孵化期意味着接口可能调整、接入范围受控；稳定期意味着兼容承诺生效；退役期意味着不再接受新接入，并需要给出存量接入方的迁移安排。三档状态让清单在能力生命周期内都能给出准确预期。
可迁移规律：换一个团队怎么套用这份示例
这份示例的字段和取值可以整体参照，但迁移到其他团队时需要按自身情况调整。以下步骤给出一个可操作的顺序。
- 先圈定能力边界，再设计字段。列出当前多条产品线重复建设的技术或业务能力，逐项判断是否值得抽成共性能力。判断标准可以是：至少两条产品线有同类需求、实现逻辑高度相似、维护成本随产品线数量线性增长。边界清楚后再决定清单需要哪些字段，避免清单变成功能罗列。
- 按产品线数量与差异度确定复用粒度。产品线少、差异小时，能力可以粗一些，一项能力覆盖全部产品线；产品线多、差异大时，把能力拆细，或在覆盖产品线字段中标注全量与按需两类。示例中消息通知区分全量与按需，就是差异度导致的粒度调整。
- 用申请与变更两个动作维持清单活性。清单填完只是起点。新接入走申请记录，能力演进走变更通知，两类记录都引用能力编号，清单才不会变成过时文档。可以约定：任何接入必须先有申请记录，任何影响接入方的改动必须先发变更通知。
- 明确维护责任与产品线负责人之间的交接约定。能力归属团队负责实现与版本策略，产品线负责人负责本线的接入与升级。交接点写清楚：变更通知发给谁、多久内确认、升级验证由谁完成。示例中变更通知要求各产品线在两个迭代内完成迁移并回归验证，就是交接约定的具体化。
- 从小范围起步再扩展。建议先选三项左右重复度最高的能力纳入清单，跑通申请与变更两个动作，再逐步纳入更多能力。起步范围过大，清单维护成本会迅速超过复用收益。
起步范围的选择可以参考一个简单排序：先纳入所有产品线都依赖的底座能力（如权限、账号），再纳入多数产品线需要但存在差异的能力（如消息通知），最后纳入尚在探索、需要试点的能力（如报表导出）。这个顺序与示例中三项能力的排列一致，也便于在早期就建立全量复用的标准做法。
当能力清单需要在多条产品线之间流转时，承载方式会影响机制能否持续。ONES Plan 的产品管理服务于以“产品-项目”模式工作的研发团队，支持管理产品线并通过工作项属性跨项目管理，与 ONES Project 数据互通；能力清单、接入申请和变更通知可以作为工作项与文档在产品线之间流转，接入状态和责任人随工作项更新，产品线负责人能在多项目视图中查看各线的接入进展。具体表单字段和流程节点需结合团队实际配置。
适用边界：这份示例在什么情况下要调整
这份示例适用于产品集合演进过程中的能力沉淀：产品线数量增加、重复建设成本上升、需要统一管理与复用。它不覆盖研发项目投资组合的立项与资源分配决策，那属于项目组合管理的范畴；具体需求的复用与资产管理也有独立的流程和记录方式，本文不展开。
以下三种情形需要对示例做调整：
- 产品线差异极大。如果各产品线的业务形态、技术栈差异明显，强行统一一项能力可能带来大量适配工作。此时应缩小能力范围，只抽取真正共通的部分，或在覆盖产品线字段中明确标注适用条件，把差异部分留给各产品线自行实现。
- 能力尚不稳定。处于快速迭代期的能力，接口和实现可能频繁变化，过早纳入清单并承诺兼容会束缚演进。可以先将状态标为孵化，限制接入产品线数量，待接口稳定后再转为稳定状态并扩大复用范围。
- 能力数量增长较快。清单条目增多后，维护成本上升，检索和通知都变得困难。可以按领域拆分清单，例如基础能力、数据能力、业务能力各一份，每份保留独立的责任人和评审节奏；也可以合并长期无人接入的能力，避免清单膨胀。
示例中的字段、取值、产品线数量和记录内容均为演示设定，用于说明填写方式。实际落地时，字段取舍、状态划分、通知周期都需要结合团队规模、产品线差异度和现有协作习惯确认，不必照搬本文的全部字段。
常见问题
能力清单填好之后，怎么避免它变成一份过时文档？
关键是把清单和两个日常动作绑定：新接入走申请记录，能力演进走变更通知，两类记录都引用能力编号。可以约定两条硬规则——任何接入必须先有申请记录，任何影响接入方的改动必须先发变更通知。这样清单上的覆盖产品线、版本策略和状态会随记录更新，而不是靠人定期回填。
另一个做法是把清单的维护责任写进归属团队的例行工作，例如每个迭代评审一次状态变化，孵化转稳定、稳定转退役都在评审中确认。
产品线之间差异很大，还能用同一份清单吗？
可以用同一份清单，但需要缩小能力范围。只抽取真正共通的部分纳入清单，差异部分留给各产品线自行实现；同时在覆盖产品线字段中标注适用条件，区分全量复用与按需接入。示例中消息通知在部分产品线只接入站内信，就是按差异度做的粒度调整。
如果差异大到共通部分很少，说明当前阶段更适合先做局部统一，等业务形态收敛后再扩大能力范围。
能力归属团队和产品线负责人之间，交接点应该写清楚哪些内容？
至少写清四件事：变更通知发给谁、多久内需要确认、升级验证由谁完成、出现问题时先找谁。归属团队负责能力实现与版本策略，产品线负责人负责本线的接入与升级，交接约定就是把这两边的动作对齐。
示例中变更通知要求各产品线在两个迭代内完成迁移并回归验证，属于可执行的时间约定；实际周期需要结合团队迭代节奏确认，不必照搬。
能力数量增长后，清单该怎么拆分和维护？
可以按领域拆分，例如基础能力、数据能力、业务能力各一份，每份保留独立的责任人和评审节奏，检索和通知都会更清晰。同时定期清理长期无人接入的能力，合并重复条目，避免清单膨胀。
拆分时保持能力编号规则一致，跨清单引用同一编号，历史申请记录和变更通知才不会对不上。
这份示例里的清单和记录，在ONES里怎么承载？
ONES Plan 的产品管理服务于以“产品-项目”模式工作的研发团队，支持管理产品线并通过工作项属性跨项目管理，与 ONES Project 数据互通。能力清单、接入申请和变更通知可以作为工作项与文档在产品线之间流转，接入状态和责任人随工作项更新，产品线负责人能在多项目总览中查看各线的接入进展。
ONES 未提供共性能力复用清单的专用模板，具体表单字段和流程节点需结合团队实际配置搭建。
