协调和组织问题
目的
定义团队如何协调。重点不是画组织架构，而是让工作有人推进、有人拍板、有人审查、有人接收结果。
三角色负责人、组员和工具之间的具体流转见 16-三角色协作流程-three-role-collaboration-flow.md。
草台团队最常见的问题不是“没有流程”，而是每个环节都半开半闭：
有人提需求，但没人记录。
有人开干，但没人定义 scope。
有人改完，但没人验收。
有人上线，但没人看结果。
有人交接任务，但下一位不知道当前状态。
协调的第一原则：每个闭环都必须有一个推进者和一个最终决策人。
角色最小集
不要一开始引入复杂岗位。先保证每个任务能映射到 5 个角色：
| 角色 | 负责什么 | 常见人选 |
|---|---|---|
| Requester | 提出问题，解释业务背景 | 老板、产品、销售、客服、运营 |
| Driver | 推动任务从记录到关闭 | 工程负责人、模块负责人、当班负责人 |
| Approver | 对 scope、优先级、上线风险拍板 | 产品负责人、技术负责人、创始人 |
| Reviewer | 判断实现和风险是否可接受 | 代码 reviewer、模块负责人 |
| Operator | 负责发布、回滚、线上观察 | 工程师、运维、平台负责人 |
一个人可以兼多个角色，但不能让一个角色缺失。最危险的是“大家都参与了，但没人是 Driver”。
决策模型
对草台团队，推荐轻量 DACI：
| DACI | 这里怎么用 |
|---|---|
| Driver | 负责把信息收齐、推动讨论、把任务推进到关闭 |
| Approver | 唯一拍板人，尤其是 scope、上线、回滚、风险接受 |
| Contributors | 给专业意见的人，有建议权，没有最终拍板权 |
| Informed | 受影响但不参与决策的人，事后同步 |
关键约束：
- Approver 只能有一个。
- Driver 不能只是“提醒大家”，必须负责推动到关闭。
- Contributors 不能无限扩大，否则所有决策都会变会议。
- Informed 不应该反复插手已关闭的决策。
Atlassian 的 DACI 定义强调 Driver 推动决策、Approver 是唯一决策者，这一点对草台团队尤其重要，因为多人拍板等于没人拍板。
需要沉淀的重要决策，使用 templates/决策记录-decision-record.md。轻量决策可以直接把 Driver、Approver、选项、结论写在任务卡评论里。
三种协调模式
参考 Team Topologies 的交互模式，草台团队可以简化成三种：
| 模式 | 适合什么时候 | 规则 |
|---|---|---|
| 临时协作 | 问题不清、需要共同探索 | 必须有结束时间和输出 |
| 接口交付 | 一方提供能力，另一方消费 | 必须有清晰输入、输出、SLA 或验收 |
| 帮扶赋能 | 一方教另一方建立能力 | 帮扶者不长期接管 Driver 职责 |
最常见的失败是把“临时协作”变成永久状态。长期协作会让边界模糊，最后所有人都被打断，任务没人闭环。
后续 Agent 协调模式
这一节在人类闭环稳定后再看。不要在 Driver、Approver、验收和证据都不稳定时先设计复杂 Agent 组织。
Agent 进入以后，不要先做复杂多 Agent 组织图。先做 4 种简单角色：
| Agent 角色 | 适合任务 | 必须输出 |
|---|---|---|
| Scout | 查代码、查文档、总结现状 | 发现列表、相关文件、风险 |
| Implementer | 小 scope 改代码、补测试 | patch、测试结果、handoff |
| Reviewer | 评审 diff、找风险、查测试缺口 | review comments、风险等级 |
| Scribe | 总结会议、事故、发布、run 结果 | timeline、action items、Driver |
不要让 Agent 同时承担 Driver、Approver 和 Operator。Agent 可以推进信息整理，但最终决策必须回到人。
Handoff 协议
每次人到人交接，都必须有固定输出。后续接入 Agent 时，也使用同一套交接格式：
Summary
Decision needed
Driver / next actor
Scope
Files or systems touched
Evidence
Risks
Deadline or next checkpoint
交接不是“把聊天记录全甩过去”，而是把下一位执行者真正需要的状态留下来。对工程组织来说，关键是：状态必须写在任务、PR、发布记录或事故记录里，而不是留在某个人脑子里。
草台团队落地方式
第 1 周：先收口入口
目标：所有活跃工作都有任务卡。
做法：
- 群里来的需求，由 Driver 转成任务卡。
- 任务卡只要求目标、Driver、Approver、scope、验收标准、风险。
- 没有 Driver / Approver 的任务不进入开发。
第 2 周：收口 review
目标：代码变化能被判断。
做法：
- PR 或 patch 必须链接任务。
- PR 描述必须写“怎么验证”。
- Reviewer 只看三件事：有没有解决正确问题、有没有测试证据、有没有上线风险。
第 3 周：收口发布
目标：上线和回滚有记录。
做法：
- 发布前列 scope。
- 发布后跑 smoke。
- 发布记录写 Driver、Approver、Operator、commit、smoke、rollback。
第 4 周：巩固人的闭环
目标：让任务从提出到关闭可以重复执行。
做法：
- 抽查任务、PR、发布记录是否有证据。
- 把无 Driver、无 Approver、无 rollback 的问题补齐。
- 对高频卡点做一次复盘，决定是否需要调整角色或流程。
反模式
| 反模式 | 后果 | 修正 |
|---|---|---|
| 老板绕过任务入口直接派活 | 任务不可追踪，优先级失真 | 允许口头派活，但必须补任务卡 |
| 多个负责人但无明确 Driver / Approver | 决策拖延，没人负责关闭 | Driver 和 Approver 各只有一个 |
| 群聊当事实来源 | 结果丢失，复盘困难 | 群聊只通知，事实回写任务、PR、发布或事故记录 |
| 临时战情群长期存在 | 所有人持续被打断 | 每个战情群必须有关闭条件 |
| 交接只靠口头说明 | 下一位不知道当前状态 | 固定使用 handoff 格式 |
| 做完没人业务验收 | 代码合了但业务不认 | 用户可见功能必须有 Business Approver |
| 只追求速度，不补记录 | 下次没人知道为什么这么做 | 紧急通道 24 小时内补闭环 |
组织设计原则
- 先定义闭环，再定义组织。
- 先定义角色责任，再买工具。
- 先让一个任务跑通，再推广到所有任务。
- 先让人能 review 人，再让自动化参与。
- 不要把协作等同于开会；协作必须产出 decision、证据或 Driver。
每周闭环指标
小组长每周只需要先看 5 个指标：
| 指标 | 说明 |
|---|---|
| 无 Driver / Approver 任务数 | 应为 0 |
| Blocked 超过 3 天任务数 | 必须重新拍板或关闭 |
| 无验证证据 PR 比例 | 越低越好 |
| 无 rollback 发布数 | 应为 0 |
| 无业务验收或关闭结论任务数 | 应为 0 |
这些指标比“开了多少会、写了多少文档”更能说明团队是否真的闭环。
参考来源
- Team Topologies: four team types and three interaction modes: https://teamtopologies.com/key-concepts
- Team Topologies interaction modeling: https://teamtopologies.com/key-concepts-content/team-interaction-modeling-with-team-topologies
- Atlassian DACI decision-making framework: https://www.atlassian.com/team-playbook/plays/daci
下一步阅读
读完或填完这份文档后，通常继续看：
- 16-三角色协作流程-three-role-collaboration-flow.md：交接规则明确后，继续看三角色和组员的具体协作步骤。