研发平台扩展维护分工的核心，是把“谁提需求、谁设计扩展、谁开发、谁评审、谁上线、谁长期维护”写成一张可填写的分工表，并用接口变更、插件版本、权限配置等具体对象划清边界。下面给出一个假设团队（示例，非真实客户）的完整分工示例，逐项解释每个角色的职责与交接物，并说明换团队规模时如何调整。文中涉及交接记录与工作项状态的部分，可借助 ONES 的工作项与文档能力承载。
要点总览（TL;DR）
- 分工表要覆盖接口集成、插件与应用扩展、配置与权限调整三类事项，字段包括需求提出、扩展负责人、评审/安全、上线执行、交接文档和上线后维护人。
- 示例团队为约80人的假设研发组织，每项扩展只设一个主责人，协作角色参与但不共同决策。
- 平台负责人管准入与优先级，扩展开发与业务需求方以需求说明和验收标准交接，评审/安全在接口权限与数据范围上把关，运维负责监控、版本与回滚。
- 小团队可合并角色但保留交接文档，大团队拆分评审与运维时需约定触发条件、响应时限和升级路径，扩展增多后按扩展类型划分维护责任。
- 示例仅覆盖平台扩展开发与维护，涉及具体产品能力、版本、价格与认证需另行查证，外包协作需补充合同条款。
示例目标：这张分工表要解决什么问题
这张分工表要回答的是扩展事项从提出到长期维护期间，每个环节由谁负责、交什么、交给谁。它适用于研发平台已经开放接口、支持插件或应用扩展，并且存在配置与权限调整需求的团队。示例团队设定为假设情景：约 80 人的研发组织，平台为自研研发管理平台，对外开放 REST 接口，支持插件扩展，扩展类型覆盖接口集成、插件与应用扩展、配置与权限调整三类。
分工表需要覆盖的字段包括：扩展事项名称、扩展类型、需求提出人、扩展负责人、协作角色、评审与安全把关人、上线执行人、交接文档、上线后维护人、维护周期与回滚责任人。字段设计的目标是让每一项扩展在表里都能找到唯一负责人，而不是多个角色共同“看着办”。
判断分工是否清晰，可以用三条标准检验：
- 每项工作有唯一负责人。同一时刻一项扩展只有一个主责人，协作人可以多个，但决策与推进责任不分散。
- 交接有书面产出。需求说明、接口设计、验收标准、上线清单、维护手册都以文档形式留存，口头约定不作为交接依据。
- 维护责任有归属。扩展上线后进入维护期，监控、版本升级、故障响应和回滚都有明确的责任人，避免上线即失管。
完成后的分工表应当能直接回答三个问题：这项扩展谁在推、现在卡在谁那里、出问题找谁。如果表里还需要临时问人才能确认，说明分工还没有落到可执行的程度。
完整示例：一个假设团队的扩展维护分工表
以下为示例团队的分工表填写样例，角色与事项均为假设情景，用于说明填写方式，不代表任何真实客户实践。表中“交接文档”一列指该环节结束时必须产出的书面材料，“上线后维护人”指进入稳定运行期后的长期责任角色。
| 扩展事项（示例） | 扩展类型 | 需求提出 | 扩展负责人 | 协作角色 | 评审/安全 | 上线执行 | 交接文档 | 上线后维护人 |
|---|---|---|---|---|---|---|---|---|
| 新增开放接口对接内部审批系统 | 接口集成 | 业务需求方（审批业务负责人） | 扩展开发（接口方向） | 平台负责人、运维 | 评审/安全（接口权限与数据范围） | 运维 | 需求说明、接口契约、验收标准、上线与回滚清单 | 扩展开发（接口方向），运维负责监控告警 |
| 插件升级至新版本并适配平台变更 | 插件/应用扩展 | 平台负责人（基于平台版本规划） | 扩展开发（插件方向） | 业务需求方、评审/安全 | 评审/安全（插件权限与依赖） | 扩展开发，运维配合发布 | 升级说明、兼容性检查记录、回归测试结论、回滚方案 | 扩展开发（插件方向） |
| 调整项目空间权限策略与数据可见范围 | 配置与权限调整 | 业务需求方（部门管理员） | 平台负责人 | 评审/安全、运维 | 评审/安全（数据范围与最小权限） | 平台负责人执行，运维留档 | 权限变更申请、影响范围说明、变更记录 | 平台负责人，运维负责定期复核 |
填写这张表时有几个细节值得注意。接口集成事项中，需求提出人与扩展开发分离，业务需求方负责说明业务场景和验收标准，扩展开发负责接口设计与实现，评审/安全在接口权限和数据范围上把关，运维负责上线执行与监控接入。插件升级事项的发起方通常是平台负责人，因为升级动因来自平台版本变化，扩展开发承担适配与回归，上线后维护仍归扩展开发。权限调整事项由平台负责人主责，因为权限策略影响面广，需要与评审/安全共同确认最小权限原则，变更记录由运维留档以便审计。
表中每一项都只有一个扩展负责人，协作角色列的是参与方而非共同决策方。交接文档列写的是该事项必须留存的材料，缺一项就视为交接未完成。上线后维护人一列区分了功能维护与监控运维，避免出现“都以为对方在管”的空档。
逐项解释：每个角色为什么这样分
平台负责人承担扩展准入与优先级判断，原因在于扩展会改变平台的接口契约、权限模型和运行负载，需要有人从平台整体视角评估影响。平台负责人不直接写业务代码，但决定一项扩展是否立项、排在什么优先级、是否影响现有集成方。这个角色还负责权限策略调整这类影响面广、变更频率低的事项，因为这类变更需要与安全要求对齐。
扩展开发与业务需求方的分离，交接点落在需求说明和验收标准两份文档上。业务需求方写清楚业务场景、使用角色、期望结果和验收条件；扩展开发据此产出接口设计或插件方案，并在开发前与需求方确认理解一致。分离的理由是业务方最清楚“要什么”，开发方最清楚“怎么做”，两边各写各的文档，评审时对照检查，可以减少需求在传递中变形。
评审/安全角色的把关位置在接口权限与数据范围上。接口集成要确认调用方身份、可访问的数据字段、调用频率是否在平台承受范围内；插件扩展要确认插件申请的权限是否超出其功能所需；权限调整要确认变更后的可见范围符合最小权限原则。评审/安全不负责实现，但在上线前给出通过或不通过的意见，这个意见是上线的前置条件。
运维接手后的责任集中在监控、版本与回滚三件事。上线执行由运维完成或配合完成，上线后监控告警接入运维的值班体系，版本发布记录进入运维的变更台账，回滚方案在扩展上线前就要写好并由运维确认可执行。功能层面的缺陷修复仍归扩展开发，运维负责发现问题和执行回滚，两者通过告警工单衔接。
这些交接动作要落到可查的记录上。在 ONES 中，可以把每项扩展建成一个工作项，用状态流转标记“需求确认—开发中—评审中—待上线—已上线—维护中”，交接文档作为工作项附件或关联文档留存，接口变更、插件版本、权限调整记录随工作项一起归档。ONES 提供丰富多样的 API 接口，可快速集成 ONES 与企业系统，实现数据打通，也支持一键对接 Github、Gitlab、钉钉、企业微信等第三方应用，便于把代码提交、发布通知和沟通记录关联到同一工作项上。基于 ONES 的开放性，还可以进行更多功能开发和拓展，具体接口清单、鉴权方式与扩展规范需以产品官方文档为准。
可迁移规律：换团队规模时怎么调整
分工示例中不依赖具体团队的部分，是“唯一负责人、书面交接、维护归属”这三条原则，以及扩展类型与责任角色的对应关系。团队规模变化时，调整的是角色合并与拆分方式，原则本身不变。
- 小团队可以合并角色，但保留交接文档。十几人的团队里，平台负责人可能同时承担评审和上线执行，扩展开发可能同时负责接口和插件。合并后仍要保留需求说明、验收标准和上线清单，因为文档是交接的载体，角色合并不能替代记录。
- 大团队拆分评审与运维时，要约定接口。评审/安全独立成岗后，需要明确评审的触发条件、响应时限和驳回后的复议路径；运维独立成岗后，需要明确上线窗口、回滚授权和故障升级路径。两个角色之间的接口写清楚，拆分才不会变成推诿。
- 扩展数量增长后，按扩展类型划分维护责任。接口集成、插件扩展、权限配置的技术栈和故障模式不同，按类型分组维护比按业务线分组更利于积累经验。每组设一名维护负责人，组间通过统一的变更记录对接。
- 用工作项状态和文档记录交接，减少口头约定。每项扩展的状态变化对应一次交接，状态变更时更新负责人字段和交接文档，评审意见、上线记录、回滚方案都挂在同一处。这样即使人员变动，接手的人也能从记录里还原上下文。
调整时可以用一个简单检验：把分工表交给一个没参与过该项目的人，看他能否根据表找到当前负责人和下一步动作。如果能，说明分工可迁移；如果还要靠问人，说明记录还不够。
适用边界：哪些情况不适用这张分工表
这张分工表覆盖的是研发平台扩展开发与维护，具体包括接口集成、插件与应用扩展、配置与权限调整三类事项。AI 场景的使用与 AI 研发管理、通用编程与模型算法不在本文范围内，相关分工需要结合具体技术栈另行设计。
涉及具体产品能力、兼容版本、价格与认证时，本文不作结论。示例中的接口契约、插件规范、权限模型都是通用描述，实际落地时需要以产品官方文档、版本说明和商务确认为准。ONES 官网列举了通过开放 API 打通内部审批系统、对接自研需求管理系统、对接企业 IM 工具等集成方向，具体实现细节与效果未在来源中说明，引用时不宜扩大适用范围。
外包或跨组织协作时，需要在分工表之外补充合同与责任条款。外包团队的交付范围、验收方式、知识产权归属、故障响应时限和退出交接，都应写入合同，分工表只解决日常协作层面的责任划分，不能替代法律约定。
最后需要说明，本文的分工表是假设情景下的填写示例，角色设置和事项安排用于说明方法，不代表任何真实客户的组织方式或实践效果。读者可以参照字段结构和交接逻辑，结合自己团队的规模、平台形态和扩展类型做调整。
常见问题
分工表里“唯一负责人”和“协作角色”怎么区分，出现分歧时谁拍板？
唯一负责人指在某一时刻对这项扩展的推进和结果负责的人，协作角色是参与评审、提供信息或配合执行的方。出现分歧时由该事项的扩展负责人拍板，涉及接口权限、数据范围或上线风险的，以评审/安全给出的通过或不通过意见为前置条件。若分歧超出扩展负责人权限，例如影响平台整体接口契约或与其他集成方冲突，则升级到平台负责人决定。把这条升级路径写进分工表，可以避免多人负责变成无人负责。
扩展上线后功能缺陷和运行故障分别由谁处理，怎么衔接？
功能层面的缺陷修复归扩展开发，运行故障的发现、告警响应和回滚执行归运维。两者通过告警工单衔接：运维接到告警后先判断影响范围，属于运行环境或版本问题的按回滚方案处理，属于功能逻辑问题的转给对应扩展开发，并在工单中附上复现信息和影响范围。回滚方案在扩展上线前就要写好并由运维确认可执行，避免故障发生时临时讨论。维护责任在分工表中单独列出，功能维护人与监控运维人分开填写。
团队规模很小，几个人兼多个角色，分工表还有必要填吗？
有必要，但可以简化。小团队里平台负责人可能同时承担评审和上线执行，扩展开发可能同时负责接口和插件，角色合并是合理的。需要保留的是交接文档和状态记录：需求说明、验收标准、上线清单、回滚方案仍然要写，每项扩展仍要有一个当前负责人。文档的作用是在人员变动、休假或事项积压时还原上下文，角色合并不能替代记录。分工表可以只保留事项、负责人、当前状态和交接文档四列，随团队扩大再补充评审、运维等列。
评审/安全独立成岗后，评审要多久响应，驳回后怎么处理？
评审的触发条件、响应时限和驳回后的复议路径需要在拆分角色时一并约定。触发条件可以按变更影响面设定，例如新增接口、扩大数据可见范围、插件申请新权限时触发评审；响应时限按团队节奏约定，例如两个工作日内给出意见；驳回时评审/安全需写明原因和整改要求，扩展开发整改后重新提交，仍有分歧的由平台负责人裁定。把这些写进分工表或配套的评审说明，拆分才不会变成流程卡点。
示例中提到的 ONES 工作项和文档能力，具体能承担哪些交接记录？
按官网开放能力页面的说明，ONES 提供丰富多样的 API 接口，可快速集成 ONES 与企业系统，实现数据打通；也支持一键对接 Github、Gitlab、钉钉、企业微信等第三方应用，基于其开放性可进行更多功能开发和拓展。在分工场景中，可以把每项扩展建成一个工作项，用状态流转标记需求确认、开发、评审、上线和维护各阶段，交接文档作为附件或关联文档留存，代码提交与发布通知关联到同一工作项。具体接口清单、鉴权方式、扩展规范和集成配置方式需以产品官方文档为准。
外包团队参与扩展开发时，分工表要额外补什么？
分工表只解决日常协作层面的责任划分，外包或跨组织协作需要在表外补充合同与责任条款，包括交付范围、验收方式、知识产权归属、故障响应时限、保密要求和退出时的交接义务。分工表中可以把外包方列为扩展开发的执行角色，但需求确认、评审把关和上线授权仍由己方角色承担，交接文档要求与内部团队一致。合同条款与分工表相互对应，避免出现责任真空。
