流水线阶段责任要解决的是“每个阶段谁负责、交付什么、何时算完成、出问题找谁”的问题。划分时先按交付流拆出阶段清单，再为每个阶段固定输入、执行动作、产出物和完成标志，指定负责人与协作角色，最后用一次真实变更走通全流程，验证责任是否闭合。
要点总览（TL;DR）
- 阶段责任划分的产出是一份阶段责任表：按交付流拆出阶段清单，为每个阶段固定输入物、执行动作、产出物和完成标志，再指定负责人与协作角色。
- 每个阶段只设一名负责人，负责人拥有对该阶段完成标志的判断权和暂停流转的权力；协作角色承担配合动作，不承担阶段结论。
- 角色与交付物对应时区分决策权与执行权，交付物写清存放位置和维护人，交接时由接收方核对输入物清单并留下确认记录。
- 回退与升级规则要和阶段责任表放在一起：写明失败退回哪个阶段、由谁重新决策、多久内响应，并用一次真实变更验证回退路径。
- 判断机制是否建立，看责任表是否覆盖全部阶段、完成标志是否可观察可记录、交接确认是否可查，以及真实变更走通的结果。
阶段责任划分的核心答案与操作步骤
阶段责任划分的产出是一份可执行的阶段责任表。它把流水线从“一串自动任务”变成“有明确责任人的交付环节”，让每个阶段的进入条件、完成标准和交接对象都能被核对。划分过程分四步，每步都有对应的产物。
第一步：按交付流拆出阶段清单
从一次变更实际经过的环节出发，而不是从工具界面上的任务列表出发。常见拆法包括：代码提交与评审、构建打包、自动化测试、环境部署、验收确认、发布上线。拆分粒度以“能指定一个负责人、能给出一个完成标志”为准。如果某个阶段由多人分段负责，就继续拆细；如果两个环节总是由同一人连续完成且没有交接动作，可以合并。完成标志是阶段清单定稿：每个阶段有名称、有边界、有前后顺序。
第二步：为每个阶段定义四要素
阶段清单确定后，逐项填写输入物、执行动作、产出物和完成标志。输入物是进入该阶段必须具备的材料或状态，例如合并请求已通过评审、构建所需的依赖版本已锁定。执行动作写清由谁做什么，例如“测试负责人执行回归用例集”。产出物是该阶段留下的可追溯结果，例如测试报告、镜像包、部署记录。完成标志是判断阶段结束的客观条件，例如“回归用例通过率达到约定阈值且无阻断级缺陷”。四要素写不出来的阶段，说明责任还没有真正落到具体动作上。
第三步：指定负责人与协作角色
每个阶段只设一名负责人，对完成标志负责；协作角色按需要列出，承担配合动作但不承担阶段结论。负责人需要具备两件事：对该阶段产出物的质量判断权，以及阶段未达标时暂停流转的权力。协作角色则明确各自提供什么输入、在什么时点介入。这样区分的目的是避免“大家都参与、没人拍板”的情况。
第四步：设定交接与回退规则
交接规则说明上一阶段以什么形式把产出物交给下一阶段，以及下一阶段如何确认接收。常见做法是交接时由接收方核对输入物清单并记录确认，确认后才开始本阶段动作。回退规则说明阶段失败时退回哪里、由谁决定、需要补充什么信息。升级规则说明回退后仍无法解决时，向哪一级角色上报、在多长时间内响应。三类规则与阶段责任表放在一起，才能在执行时直接查用。
阶段责任表建议包含以下字段，可直接作为填写模板：阶段名称、阶段负责人、协作角色、输入物、执行动作、产出物、完成标志、交接确认方式、回退目标阶段、升级对象。字段填满并通过一次真实变更验证后，这张表就可以作为团队执行流水线的依据。
各阶段角色与交付物如何对应
角色与交付物的对应关系要区分两种权力：决策权决定阶段能否通过、能否放行；执行权负责完成阶段内的具体动作。同一人可以在不同阶段承担不同权力，但在同一阶段内应明确哪一项是主导。下表按典型阶段列出常见对应关系，团队可据此裁剪。
| 阶段 | 负责人（决策权） | 协作角色（执行权） | 主要交付物 | 交付物归属与存档 |
|---|---|---|---|---|
| 代码提交与评审 | 开发负责人 | 提交者、评审人 | 合并请求、评审记录、关联的工作项 | 代码仓库保留提交与评审历史，工作项中记录关联关系 |
| 构建打包 | 构建负责人或值班工程师 | 开发人员 | 构建产物、版本号、构建日志 | 制品库按版本存档，构建记录与对应提交关联 |
| 自动化测试 | 测试负责人 | 开发人员、测试执行人员 | 测试报告、缺陷清单、通过率数据 | 测试管理系统或项目文档中按版本归档 |
| 环境部署 | 运维或环境负责人 | 开发人员、测试人员 | 部署记录、环境配置版本、回滚预案 | 部署日志与配置库留存，部署单关联变更 |
| 验收确认 | 产品负责人或业务验收人 | 测试人员、开发人员 | 验收结论、遗留问题清单 | 验收记录随需求或迭代文档存档 |
| 发布上线 | 发布负责人 | 运维、开发值班人员 | 发布记录、上线检查单、监控基线 | 发布单与变更单关联存档，保留回滚版本信息 |
交付物归属要写清两件事：存在哪里、由谁维护。存在位置决定后续能否追溯，维护人决定内容更新由谁负责。交接时的确认动作建议统一为“接收方核对输入物清单并记录确认结果”，确认记录与交付物放在同一处，避免交接只停留在口头。对于跨团队交接的阶段，确认动作还应包含对完成标志的复核，例如测试负责人接收构建产物时，同时核对版本号与构建记录是否一致。
当团队使用 ONES 承载研发过程时，阶段责任表可以作为项目文档维护，代码提交、构建、发布等过程可在项目、迭代和需求中关联查看，流水线执行状态与日志随集成同步，便于在交接时核对同一变更在各阶段的实际状态。这一衔接的前提是已完成相应工具链集成，具体集成范围以实际配置为准。
示例：一次变更走完流水线各阶段的责任流转
以下为演示情景，用于说明责任如何随变更传递，不代表特定团队的真实案例。
某需求拆出一个研发任务，开发人员提交代码并创建合并请求，关联该任务。代码评审阶段由开发负责人决策：评审意见关闭、合并请求通过后，阶段完成，交付物是合并记录与评审结论。构建阶段由值班构建工程师负责，输入是已合并的代码版本，产出带版本号的构建产物和构建日志，完成标志是构建成功且产物入库。若构建失败，回退到开发负责人，由提交者修复后重新触发，连续两次失败则升级到开发负责人所在团队的技术负责人。
测试阶段由测试负责人决策，输入是构建产物与版本说明，执行回归与专项测试，产出测试报告和缺陷清单。完成标志是阻断级缺陷清零、通过率达到约定值。若发现阻断级缺陷，回退到开发阶段，缺陷单关联原任务，修复后重新构建并重新进入测试；若缺陷涉及需求理解偏差，升级到产品负责人确认范围。
部署与验收阶段由环境负责人和产品负责人分别负责。部署完成以部署记录和健康检查通过为标志；验收完成以验收结论记录为标志。发布阶段由发布负责人决策，输入是验收通过的版本和上线检查单，产出发布记录与监控基线。发布后出现异常时，按回滚预案退回上一稳定版本，并由发布负责人决定是否升级到变更评审角色。整个流转中，每个阶段的负责人、输入、产出和回退目标都能在阶段责任表中查到，交接确认记录与交付物存放在同一位置。
责任机制落地后的完成检查
判断阶段责任机制是否建立，不看文档写得多完整，而看三件事：责任表是否覆盖全部阶段、每个阶段是否有可核对的负责人和完成标志、交接与回退规则能否在真实变更中执行。可按以下清单逐项核对。
- 阶段清单覆盖了从代码提交到发布上线的全部环节，没有“无人认领”的环节，也没有两个阶段共用同一完成标志的情况。
- 每个阶段都有且只有一名负责人，负责人具备对该阶段完成标志的判断权。
- 每个阶段的输入物、产出物、完成标志均已填写，完成标志是可观察、可记录的条件，而非“基本完成”一类描述。
- 每个交付物写明了存放位置和维护人，交接确认有记录可查。
- 每个阶段写明了回退目标阶段和升级对象，回退后由谁重新决策清晰可查。
- 已用一次真实变更走通全流程，各阶段交接确认记录齐全，至少验证过一次回退路径。
- 验证中发现的责任空白已补入责任表，并同步给相关角色。
清单全部通过后，阶段责任表即可作为团队执行依据；后续阶段调整时，同步更新责任表并重新走一次验证，避免规则与实际执行脱节。
常见问题
阶段负责人和协作角色的边界怎么划，一个人同时负责多个阶段可以吗？
可以，同一个人在不同阶段承担不同角色是常见做法。需要守住的是同一阶段内的权力归属：该阶段只有一名负责人，对完成标志作出判断并决定是否放行；协作角色提供输入、执行具体动作，不替负责人下结论。
如果一个人既是某阶段的执行者又是负责人，建议在责任表里把这两个身份分开写，并在交接确认时留下记录，避免自己执行、自己确认、没有第二人核对的情况。对于风险较高的阶段，例如发布上线，可以要求交接确认由另一名角色复核。
阶段数量拆到多细比较合适，拆得太细会不会增加管理成本？
拆分粒度以“能指定一名负责人、能给出一个完成标志”为准。某个环节由多人分段负责、中间存在交接动作，就继续拆；两个环节长期由同一人连续完成且没有交接，可以合并。
阶段拆得过细确实会增加确认动作和记录负担。实际做法是先按当前交付流拆一版，用一次真实变更走通，观察哪些阶段的交接确认流于形式、哪些阶段经常出现责任不清，再据此合并或细分。阶段清单是随交付方式调整的，不必一次定死。
流水线大部分环节是自动执行的，还需要为每个阶段指定负责人吗？
需要。自动执行改变的是动作由谁完成，不改变失败时由谁判断和处理。构建、自动化测试这类阶段，负责人关注的是完成标志是否达成、失败后回退到哪、是否需要升级，而不是亲手执行每一步。
对全自动阶段，负责人可以按值班制轮换，但责任表里要写清当班负责人是谁、在什么时间窗口内响应。这样流水线报错时才有人对“继续、回退还是升级”作出决定。
交接确认记录放在哪里比较合适，需要和交付物放在一起吗？
建议放在同一处，便于追溯时一次查全。交付物本身有固定存放位置，例如制品库、测试报告归档、发布单；交接确认记录应能关联到对应的交付物和变更，而不是散落在聊天记录里。
如果团队使用 ONES 承载研发过程，阶段责任表可以作为项目文档维护，代码提交、构建、发布等过程可在项目、迭代和需求中关联查看，流水线执行状态与日志随集成同步，交接时能核对同一变更在各阶段的实际状态。这一衔接的前提是已完成相应工具链集成，具体集成范围以实际配置为准。
责任表建好之后，阶段或人员发生调整，怎么保证规则不过期？
把责任表更新纳入阶段调整的固定动作：新增、合并或取消阶段时，同步修改责任表中的负责人、完成标志和回退目标，并通知相关角色。人员轮换时更新负责人字段，交接确认方式保持不变。
调整后建议重新用一次真实变更走通全流程，重点验证新的回退路径是否可执行。定期检查时，可以对照最近几次变更的交接确认记录，看是否存在责任表未覆盖的环节或长期无人确认的阶段。
