研发平台扩展维护分工要解决的是责任归属和流程衔接：扩展需求由谁提出、谁评审边界、谁开发、谁发布、上线后谁维护、何时退役。本文按角色、阶段、机制文档和上线检查四部分展开，给出可直接套用的职责表、流程表、责任矩阵模板与检查清单，并说明扩展需求与变更记录如何借助 ONES 的工作项与流程记录承载。
要点总览（TL;DR）
- 扩展维护分工先定四类角色：平台产品负责人、扩展开发负责人、平台运维负责人、业务方接口人，每类角色明确决策权和不承担事项。
- 按需求评审、方案设计、开发测试、上线发布、日常维护、下线退役六个阶段划分责任，每个阶段写清输入、输出、完成标志和负责人。
- 用 RACI 简化版责任矩阵和扩展变更申请单把分工固化下来，每项关键工作只设一个最终负责人，审批路径按影响范围分级。
- 小团队兼岗时保留开发与发布审批的制衡，上线确认由非开发者复核，避免自测自发。
- 机制生效前用检查清单逐项核对责任人、输出物、升级路径演练和文档版本管理，运行一段时间后结合故障记录回顾调整。
扩展维护分工先定哪几类角色
扩展维护分工的第一步是把角色定清楚，而不是先切功能模块。建议设置四类核心角色：平台产品负责人、扩展开发负责人、平台运维负责人、业务方接口人。四类角色覆盖从需求判断到运行反馈的完整链条，每类角色都有明确的决策权和明确不承担的事项，避免职责重叠或出现无人负责的环节。
| 角色 | 核心职责 | 决策权 | 不承担事项 |
|---|---|---|---|
| 平台产品负责人 | 收集扩展需求，判断与平台定位的匹配度，排定优先级，划定扩展边界 | 决定做不做、先做哪个、扩展范围到哪里为止 | 不直接编写扩展代码，不承担日常运维值班 |
| 扩展开发负责人 | 负责接口设计、插件或扩展功能实现、单元测试与联调，输出技术方案 | 决定技术实现路径、接口契约细节、代码评审结论 | 不单方面决定需求优先级，不自行批准上线 |
| 平台运维负责人 | 负责部署、监控配置、回滚预案、版本升级执行与运行环境稳定 | 决定发布窗口是否可用、是否触发回滚 | 不修改扩展业务逻辑，不替代开发排查代码缺陷 |
| 业务方接口人 | 提出业务场景需求，提供验收标准，组织使用反馈，确认扩展是否满足场景 | 决定场景验收是否通过 | 不介入技术方案选择，不直接操作生产环境 |
小团队一人多岗时，兼岗原则是保留关键制衡点。开发和发布审批可以由不同人承担，至少让上线确认由非开发者复核，降低自测自发的风险。需求优先级判断与开发实现也不建议由同一人同时拍板，否则容易把“能做”当成“该做”。兼岗时在责任矩阵中如实标注一人多角，冲突点单独列出并约定复核人。
从需求到退役：扩展全生命周期的分工步骤
角色确定后，需要把扩展从提出到退役拆成阶段，每个阶段写清输入、动作、输出、完成标志和负责人。阶段划分的价值在于责任可以随阶段转移，交接有据可查。
| 阶段 | 输入 | 动作 | 输出 | 完成标志 | 负责人 |
|---|---|---|---|---|---|
| 需求提出与边界评审 | 业务场景描述、期望效果 | 业务方接口人提交需求，平台产品负责人评估与平台定位的匹配度、影响范围与优先级 | 扩展需求单、边界说明、优先级结论 | 需求单通过评审并进入排期 | 平台产品负责人 |
| 方案设计与评审 | 已通过的需求单 | 扩展开发负责人输出技术方案，说明接口契约、数据流向、依赖与风险；运维负责人评估部署与监控影响 | 技术方案文档、接口约定 | 方案评审通过，接口契约冻结 | 扩展开发负责人 |
| 开发实现与测试验证 | 技术方案、接口契约 | 开发完成编码与单元测试，联调后提交测试；业务方接口人按验收标准验证场景 | 可部署的扩展包、测试记录、验收结论 | 测试通过且业务验收签字 | 扩展开发负责人（开发）、业务方接口人（验收） |
| 上线发布 | 验收通过的扩展包、回滚方案 | 运维负责人执行部署，开发负责人现场支持，发布后观察监控指标 | 发布记录、监控看板、回滚预案 | 发布完成且观察期内无异常 | 平台运维负责人 |
| 日常维护与版本升级 | 运行监控数据、使用反馈 | 运维负责人处理告警与故障，开发负责人修复缺陷并适配平台版本升级 | 故障记录、修复版本、升级适配说明 | 问题闭环，升级后回归通过 | 平台运维负责人（运行）、扩展开发负责人（修复） |
| 下线与退役 | 使用率数据、业务方确认、平台版本变更通知 | 平台产品负责人判断是否退役，开发负责人停止维护并清理代码，运维负责人下线实例与监控 | 退役通知、清理记录 | 实例下线、相关文档归档 | 平台产品负责人（决策）、平台运维负责人（执行） |
退役的触发条件建议写具体：业务场景消失、扩展被平台原生能力替代、维护成本持续高于收益、依赖的接口或平台版本不再支持。触发后由平台产品负责人确认，避免扩展长期处于无人维护却仍在运行的状态。
责任矩阵与变更流程怎么落地
角色和阶段停留在口头约定时，人员变动就会让分工失效。落地方式是两份文档：一份责任矩阵，一份扩展变更申请单。
责任矩阵可采用 RACI 简化版。每项关键工作只设一个 A（最终负责），R（执行）可以多人，C（咨询）与 I（知会）按需填写。填写方法是先列出关键工作项，如需求评审、方案评审、开发、测试验收、发布、故障处理、版本升级、退役决策，再逐行填入角色代号。检查规则是每行有且只有一个 A，R 不为空，C 和 I 不滥用。多人共同负责是常见隐患，矩阵中出现两个 A 就应拆分工项或明确主次。
| 关键工作 | 平台产品负责人 | 扩展开发负责人 | 平台运维负责人 | 业务方接口人 |
|---|---|---|---|---|
| 需求评审与优先级 | A/R | C | I | C |
| 技术方案评审 | C | A/R | C | I |
| 开发与自测 | I | A/R | I | I |
| 业务验收 | I | C | I | A/R |
| 上线发布 | I | R | A/R | I |
| 故障处理 | I | R | A/R | I |
| 退役决策 | A/R | C | C | C |
扩展变更申请单建议包含以下必填字段：变更目的、影响范围（涉及哪些业务场景与系统）、涉及接口与版本、回滚方案、验证方式、计划上线时间窗、审批人与知会对象。审批路径按影响范围分级：仅内部逻辑调整由扩展开发负责人审批；涉及接口契约变化需平台产品负责人与运维负责人共同审批；影响多个业务方的变更增加业务方接口人确认。跨团队协作时约定升级路径：一线处理人在约定时限内无法解决，升级至扩展开发负责人；涉及运行环境或发布窗口，升级至平台运维负责人；涉及范围与优先级争议，升级至平台产品负责人。响应时限按影响等级分档，例如影响核心业务场景的故障优先处理，一般问题按排期处理，具体时限由团队在机制文档中写明。
这些记录需要有承载位置。ONES 提供 API 接口，可快速集成企业系统实现数据打通，也支持对接 Github、Gitlab、钉钉、企业微信等第三方应用；基于其开放性可进行更多功能开发和拓展。扩展需求单、变更申请、上线记录和故障处理可以放在同一套工作项流转中，让阶段交接和审批留下可追溯的记录。深圳农商行通过 ONES 开放的 API 接口打通内部审批系统、奥哲将 ONES 系统与自研需求管理系统对接，都是官网展示的集成案例，具体实现方式与范围以实际项目为准。
一个扩展插件的分工示例
以下为演示情景，用于说明角色、阶段与交付物如何对应。假设业务方希望研发平台的工作项状态变化能同步到内部协作工具，以工作项状态同步类扩展为例走完整流程。
需求阶段：业务方接口人提交需求单，说明需要同步的状态类型、目标工具和期望时效。平台产品负责人评审后确认该扩展属于平台开放能力范围内的合理扩展，排入迭代，输出边界说明，明确只同步状态字段、不同步附件与评论。
方案阶段：扩展开发负责人输出技术方案，约定调用平台接口获取状态变更事件、映射状态值、调用目标工具接口推送，并写明失败重试与幂等处理。平台运维负责人评估需要新增的监控项与告警阈值。方案评审通过后接口契约冻结。
开发与验收阶段：开发完成编码与单元测试，联调环境验证同步链路。业务方接口人按验收标准检查状态是否准确、延迟是否可接受，输出验收结论。
上线阶段：运维负责人按发布窗口部署，开发负责人现场支持，观察期内监控同步成功率与失败告警。发布记录与回滚方案归档。
维护阶段：日常由运维负责人处理告警，开发负责人修复缺陷。当平台接口发生变更时，责任从运维转移到开发：运维发现同步失败并定位到接口返回变化，提交缺陷单给开发负责人，开发负责人评估兼容性并发布适配版本，运维重新验证。故障处理期间由运维负责人统一对外通报进展，避免多头沟通。
退役阶段：若平台原生支持该同步能力，平台产品负责人发起退役决策，开发负责人停止维护并清理代码，运维负责人下线实例与监控，业务方接口人确认切换方案后归档文档。
分工机制上线前的完成检查
分工方案写完后，用以下清单逐项核对，全部通过再宣布机制生效。
- 四类核心角色均有明确责任人，兼岗情况已在矩阵中标注，没有无人负责的工作项。
- 责任矩阵每行有且只有一个 A，R 不为空，C 与 I 的填写有实际意义。
- 每个阶段都有可验证的输出物，输出物有存放位置和命名规则。
- 扩展变更申请单字段完整，审批路径按影响范围分级且已通知到相关角色。
- 升级路径经过至少一次演练，确认接口变更或故障时责任转移有明确接手人。
- 响应时限已写入机制文档，并与团队实际值班安排一致。
- 退役触发条件已明确，历史扩展有清单可查。
- 责任矩阵与流程文档纳入版本管理，变更留有记录，人员调整时同步更新。
检查中发现空档时，优先补责任人和输出物，再调整流程细节。机制运行一段时间后，结合故障记录和变更单回顾一次分工是否仍然匹配实际工作，把调整结果更新到矩阵和文档中。
常见问题
小团队人手有限，四类角色无法全部专人担任，怎么分工才不出问题？
一人多岗在小团队中是常态，关键是保留制衡点。开发与发布审批建议由不同人承担，至少让上线确认由非开发者复核；需求优先级判断与开发实现也不建议由同一人同时拍板。兼岗情况要在责任矩阵中如实标注一人多角，把冲突点单独列出并约定复核人。角色名称可以合并，但每项关键工作的最终负责人只能有一个。
扩展变更申请单里哪些字段最容易被漏填，漏填会带来什么后果？
实际执行中最容易漏的是回滚方案和影响范围。回滚方案缺失时，上线出问题只能临时想办法，处置时间被拉长；影响范围写得太笼统，审批人无法判断该走哪一级审批，容易把涉及接口契约变化的变更当成内部调整放行。建议把回滚方案、涉及接口与版本、验证方式设为必填，提交时由审批人核对，缺项退回补充。
平台接口发生变更导致扩展失效，责任应该怎么转移？
建议按“发现—定位—修复—验证”的顺序转移责任。运维负责人通过监控发现同步失败，定位到接口返回变化后提交缺陷单给扩展开发负责人；开发负责人评估兼容性并发布适配版本；运维负责人重新验证并恢复监控观察。故障处理期间由运维负责人统一对外通报进展，避免多头沟通。这条路径应在机制上线前至少演练一次，确认每个环节都有明确接手人。
扩展什么时候应该退役，由谁来决定？
常见触发条件包括：业务场景消失、扩展被平台原生能力替代、维护成本持续高于收益、依赖的接口或平台版本不再支持。触发后由平台产品负责人确认退役决策，扩展开发负责人停止维护并清理代码，平台运维负责人下线实例与监控，业务方接口人确认切换方案后归档文档。建议维护一份历史扩展清单，定期检查使用率，避免扩展长期无人维护却仍在运行。
扩展需求和变更记录放在研发管理平台里管理，有什么实际好处？
把扩展需求单、变更申请、上线记录和故障处理放在同一套工作项流转中，阶段交接和审批会留下可追溯的记录，人员调整时接手人可以直接查看历史。ONES 提供 API 接口，可快速集成企业系统实现数据打通，也支持对接 Github、Gitlab、钉钉、企业微信等第三方应用；基于其开放性可进行更多功能开发和拓展。深圳农商行通过 ONES 开放的 API 接口打通内部审批系统、奥哲将 ONES 系统与自研需求管理系统对接，都是官网展示的集成案例，具体实现方式与范围以实际项目为准。
