研发平台扩展维护分工要落到可执行层面，关键是先把扩展开发和日常维护拆成两类工作，再用职责矩阵把每个环节的负责人固定下来，最后用需求单、变更单、交接清单等交付物承载流程。本文按“分类—矩阵—流程—维护—检查”的顺序，给出一套可直接套用的分工机制，适用于接口对接、插件脚本、字段流程定制等扩展场景。
要点总览（TL;DR）
- 先把平台扩展维护拆成扩展开发和日常维护两类工作，以“是否改变平台配置结构或代码”作为初步判断依据，交叉部分用交接清单明确移交时点与接收人。
- 用 RACI 职责矩阵把每类扩展的每个关键环节落到角色上，每行有且仅有一个最终负责人，执行人不能空缺。
- 扩展从需求提出到上线移交，每个环节都要写明输入、动作、输出、负责人和完成标志，用需求单、设计说明、变更单和交接清单承载。
- 上线后按扩展重要程度约定值守方式、故障分级与升级路径，平台升级前由扩展开发核对名下接口和脚本的兼容性。
- 每半年例行评审分工文档，新增扩展类型、角色调整、平台重大升级或发生职责不清导致的故障时立即更新。
先分清扩展开发与日常维护两类工作
分工模糊往往源于工作类型没有拆开。同一个“接口出问题”，可能属于扩展开发的缺陷修复，也可能属于日常维护的配置或网络排查。先建立工作分类清单，才能把责任分配到具体角色。
扩展开发的典型工作
- 接口对接：与外部系统打通数据，定义字段映射、调用方式和异常处理。
- 插件或脚本开发：在平台允许的扩展点上编写自动化逻辑、定时任务或辅助工具。
- 字段与流程定制：新增业务字段、调整审批流或状态流转规则。
- 报表扩展：按业务口径新增统计视图或导出逻辑。
这类工作的共同特征是改变平台的配置结构或代码资产，通常需要设计、评审和上线变更。
日常维护的典型工作
- 配置调整：修改已有字段选项、通知规则、看板视图等不改变结构的设置。
- 权限与账号：处理用户开通、角色调整、权限回收。
- 监控告警：关注接口可用性、任务执行状态和异常日志。
- 故障处置：按级别响应报障，定位问题并恢复服务。
- 版本升级配合：在平台升级前后执行兼容性检查与回归验证。
日常维护以保持现有能力稳定运行为目标，多数动作在既定规范内完成，不需要逐次走完整的设计评审。
交叉点与交接点
两类工作存在明确交叉：扩展上线后进入维护期，缺陷修复可能回到开发侧；平台升级可能同时触发配置调整和扩展兼容性改造。建议以“是否改变平台配置结构或代码”作为初步判断依据，交叉部分通过交接清单明确移交时点、移交内容和接收人。交接清单至少包含扩展名称、涉及接口或脚本、已知限制、回滚方式和原开发负责人。
按扩展类型划分责任范围
把工作分类整理成一张清单，每行是一类扩展或一类维护事项，标注归属方向（开发侧主导、维护侧主导、双方共管）。归属方向不是永久标签，扩展上线移交后，日常运行归维护侧，结构性变更仍回到开发侧。清单应覆盖组织当前实际存在的扩展类型，避免遗漏低频但关键的对接。
用职责矩阵固定每个环节的负责人
工作分类解决“做什么”，职责矩阵解决“谁负责”。推荐采用 RACI 模型，按扩展类型和关键环节逐行填写，确保每行有且仅有一个最终负责人。
需要设置的角色
| 角色 | 主要职责 |
|---|---|
| 平台负责人 | 统筹平台扩展规划，审批上线变更，对整体稳定性负责 |
| 扩展开发 | 承担设计、编码、自测和上线实施 |
| 运维值守 | 负责日常监控、故障第一响应和升级配合 |
| 业务需求方 | 提出需求、确认验收标准、参与上线验证 |
| 安全与合规评审 | 评估接口权限、数据范围和合规风险 |
RACI 四类职责的含义与填写规则
- R（执行人）：实际完成该环节动作的人，可以多人。
- A（最终负责人）：对该环节结果负最终责任，每行只能有一个。
- C（被咨询人）：在决策前需要征求意见的人，双向沟通。
- I（被知会人）：结果确定后需要被告知的人，单向沟通。
填写规则有两条硬约束：每行必须有且仅有一个 A；R 不能空缺。若某环节找不到 A，说明职责尚未分配，应作为待办项处理，而不是留白。
按扩展类型逐行填写
| 扩展类型 / 环节 | R 执行人 | A 最终负责人 | C 被咨询人 | I 被知会人 |
|---|---|---|---|---|
| 接口对接—方案设计 | 扩展开发 | 平台负责人 | 安全评审、业务需求方 | 运维值守 |
| 接口对接—上线变更 | 扩展开发 | 平台负责人 | 运维值守 | 业务需求方 |
| 字段流程定制—配置调整 | 运维值守 | 平台负责人 | 业务需求方 | 扩展开发 |
| 报表扩展—验收 | 业务需求方 | 平台负责人 | 扩展开发 | 运维值守 |
| 故障处置—一级响应 | 运维值守 | 运维值守负责人 | 扩展开发 | 平台负责人 |
表格中的角色名称可按组织实际岗位替换，行数按扩展类型增减。关键是每类扩展的每个关键环节都能在矩阵中找到对应行。
单人兼任多角色时的冲突处理
小团队中平台负责人可能同时是扩展开发，此时上线审批环节会出现自审自批。处理方式有两种：涉及上线审批和安全评审的环节设置审批回避，由上级或指定代行人审批；或在矩阵中明确标注兼任关系，并规定该类环节必须留存书面评审记录。安全与合规评审建议始终由独立于开发的人员承担。
扩展从提出到上线的分工流程与交付物
职责矩阵定义角色，流程定义动作顺序和交付物。每个环节都应说清输入、动作、输出、负责人和完成标志，避免“沟通到位”这类无法核验的表述。
需求提出
输入是业务需求方提交的需求单，内容包含业务背景、期望效果、涉及系统和期望时间。业务方负责确认需求范围和优先级，平台方负责判断属于扩展开发还是配置调整，并给出初步可行性意见。输出是已分类、已确认的需求单，完成标志是平台负责人确认受理。
方案设计与评审
扩展开发负责输出设计说明，内容覆盖接口定义、字段映射、权限范围、数据影响和异常处理。安全与合规评审评估接口权限和数据范围，运维值守评估对现有监控和容量的影响。输出是评审通过的设计说明，完成标志是评审记录留存且遗留问题已闭环。
开发与测试
开发负责人按设计说明实施，测试范围至少覆盖正常流程、异常分支和权限边界。业务需求方参与验收，按需求单中的验收标准逐项确认。输出是测试记录和验收结论，完成标志是验收通过并记录已知限制。
上线与变更
输入是变更单，需写明变更内容、影响范围、上线窗口、回滚预案和审批人。平台负责人审批变更，扩展开发执行上线，运维值守在上线窗口内待命。完成标志是上线验证通过、监控指标正常、回滚预案已确认可执行。
上线后移交
从开发移交到维护值守，使用交接清单逐项确认：扩展名称与用途、涉及接口或脚本位置、已知限制、常见故障处理方式、回滚步骤、原开发负责人和移交日期。完成标志是运维值守确认接收并在清单上签字，此后日常运行归维护侧。
维护期值守、故障与升级的分工约定
上线移交只是维护期的起点。值守、故障响应和平台升级需要事先约定，否则容易出现“出了问题找不到人”的情况。
值守排班与响应时限
按扩展的重要程度约定值守方式：核心对接安排工作日固定值守，非核心扩展可采用报障响应制。响应时限由组织按自身服务能力设定，例如一级故障 30 分钟内响应、二级故障 4 小时内响应，具体数值写入值守约定表并由平台负责人确认。
故障分级与升级路径
| 故障级别 | 判定参考 | 第一响应人 | 升级路径 |
|---|---|---|---|
| 一级 | 核心接口不可用，影响业务主流程 | 运维值守 | 立即通知平台负责人，必要时召集原开发 |
| 二级 | 部分功能异常，有替代操作方式 | 运维值守 | 当班内升级至扩展开发 |
| 三级 | 非核心问题或体验类缺陷 | 运维值守 | 纳入常规排期处理 |
第一响应人负责初步定位和记录，判断属于配置问题还是代码缺陷，再决定是否升级到扩展开发。升级路径应写明联系方式和响应时限。
平台版本升级时的兼容性检查
平台升级前，由平台负责人发起兼容性检查任务，扩展开发负责核对自己名下的接口和脚本是否受影响，运维值守负责准备回滚环境。检查结果汇总为升级检查清单，完成标志是清单中所有扩展项均已确认，未确认项明确延期或下线安排。
扩展下线与废弃
扩展不再使用时，由提出下线的角色填写下线申请，扩展开发确认无其他系统依赖，运维值守执行停用并清理监控项，平台负责人审批。完成标志是扩展从扩展清单中移除，相关账号和密钥回收。
示例：一个接口扩展项目的分工落地
以下为演示性情景，用于说明分工机制如何组合使用，不代表任何真实项目。
场景设定
业务部门提出需求：将研发平台的缺陷数据同步到外部客服系统，便于客服跟踪问题处理进度。该需求属于接口对接类扩展，涉及数据字段映射和权限范围。
各角色的动作与交付物
- 业务需求方：提交需求单，写明同步字段、同步频率和期望上线时间，确认验收标准。
- 平台负责人：受理需求，判定为扩展开发，指定扩展开发负责人，并在职责矩阵中确认该项目的 A 为平台负责人。
- 扩展开发：输出设计说明，定义接口调用方式、字段映射表和异常重试策略。
- 安全与合规评审：评估对外传输的数据范围，确认不含敏感字段，出具评审意见。
- 运维值守：评估新增接口对监控和容量的影响，提出告警配置建议。
评审、上线、移交的完成标志
设计评审完成标志是评审记录留存、安全意见闭环。上线完成标志是变更单审批通过、上线验证通过、监控告警生效。移交完成标志是交接清单由运维值守确认接收，扩展清单中新增该接口条目。
示例中的职责边界与交接点
开发阶段的结构性变更由扩展开发负责，上线后的日常监控和一级响应由运维值守负责。交接点设在移交确认时：移交前缺陷由扩展开发修复，移交后配置类问题由运维值守处理，代码缺陷仍回到扩展开发。这一边界写入职责矩阵，避免后续推诿。
分工机制的完成检查与持续维护
分工机制建立后，需要用检查清单确认其可执行，并设定更新触发条件，防止文档与实际脱节。
完成检查清单
- 职责矩阵覆盖全部扩展类型，每行有且仅有一个 A，无空白责任人。
- 每个关键环节都有明确的输入、输出和完成标志。
- 交接清单和升级路径经过实际演练或走查，确认可执行。
- 值守约定表中的响应时限已由平台负责人确认。
- 单人兼任多角色的审批回避规则已写入制度。
- 扩展清单与职责矩阵中的扩展类型保持一致。
评审周期与更新触发条件
建议每半年对分工文档进行一次例行评审。出现以下情况时应立即更新：新增扩展类型、组织角色调整、平台重大版本升级、发生因职责不清导致的故障。每次更新记录变更内容和确认人。
借助平台工具承载分工记录
需求单、变更单、交接记录和检查清单如果分散在邮件和聊天工具中，追溯成本很高。可以在研发管理平台中统一承载这些记录：业务需求方在需求池提交扩展需求，平台负责人流转审批，扩展开发和运维值守在同一个工作项上更新状态和交接信息。ONES 提供统一的业务需求池、产品需求池与工单系统，支持需求—任务—测试—缺陷的全流程闭环，便于把分工中的每个环节对应到可追溯的记录上。对于接口对接类扩展，ONES 提供 API 接口用于集成企业系统，并支持对接 Github、Gitlab、钉钉、企业微信等应用，扩展上线后的运行状态和变更历史可以在平台内留痕。具体接口清单、调用限制和扩展开发规范需以官方资料和实际版本为准。
常见问题
小团队里平台负责人同时承担扩展开发，上线审批怎么处理？
涉及上线审批和安全评审的环节应设置审批回避，由上级或指定代行人审批；也可以在职责矩阵中标注兼任关系，并规定这类环节必须留存书面评审记录。安全与合规评审建议始终由独立于开发的人员承担，避免自审自批。
扩展上线移交后，配置类问题和代码缺陷分别由谁处理？
移交确认后，日常运行归维护侧，配置调整、权限处理和一级响应由运维值守负责；代码缺陷仍回到扩展开发修复。这条边界应写入职责矩阵和交接清单，交接清单至少包含扩展名称、涉及接口或脚本位置、已知限制、回滚方式和原开发负责人。
值守响应时限和故障分级标准应该由谁定？
这类数值属于组织管理约定，由平台负责人结合自身服务能力确认后写入值守约定表。可以先按影响范围划分级别，例如核心接口不可用、部分功能异常、非核心缺陷三档，再为每档设定第一响应人和升级路径，具体时限按团队实际值守能力填写。
平台版本升级时，怎么确认已有扩展不受影响？
升级前由平台负责人发起兼容性检查任务，扩展开发逐项核对自己名下的接口和脚本，运维值守准备回滚环境，检查结果汇总为升级检查清单。清单中所有扩展项确认后才算完成，未确认项要明确延期或下线安排。
需求单、变更单和交接记录分散在邮件和聊天工具里，怎么统一管理？
可以在研发管理平台中统一承载这些记录：业务需求方在需求池提交扩展需求，平台负责人流转审批，扩展开发和运维值守在同一个工作项上更新状态和交接信息。ONES 提供统一的业务需求池、产品需求池与工单系统，支持需求—任务—测试—缺陷的全流程闭环；同时提供 API 接口用于集成企业系统，并支持对接 Github、Gitlab、钉钉、企业微信等应用，便于把分工中的每个环节对应到可追溯的记录上。具体接口清单、调用限制和扩展开发规范以官方资料和实际版本为准。
