第 11 章 四阶段中的角色协作
第 11 章 四阶段中的角色协作¶
Note
本章导读：第 10 章定义了"有哪些角色"，本章回答"这些角色在四个交付阶段里如何分工与漂移"。同一个角色在不同阶段的权责并非固定——发现期业务策略师主导、原型期技术执行与业务策略双轮驱动、构建期技术主导、扩展期向平台与客户双向移交。本章用 RACI 矩阵把这种动态漂移显性化，避免团队在阶段切换时权责不清、互相推诿。 读完本章，你能用 RACI 矩阵写清每个阶段谁负责、谁决策，并化解阶段切换时最常见的权责冲突。
沿用本书的四阶段划分（Discovery 发现 → Prototype 原型 → Build 构建 → Scale 扩展，其来源属性见第三篇 How 总纲），在不同阶段，不同角色的权责会发生动态漂移。本章用 RACI 矩阵把这种漂移显性化。
11.1 总览 RACI 矩阵¶
为了避免推诿扯皮，我们采用 RACI 模型来界定协作边界：
- R（Responsible）：负责执行，真正动手干活的人。
- A（Accountable）：最终审批/负责，背锅的人（每个活动只能有 1 个 A）。
- C（Consulted）：需要咨询意见，提供专业输入。
- I（Informed）：需要知会，单向信息同步。
Tip
FDE 团队四阶段 RACI 协作矩阵模板
（此模板可直接复制到项目开工会 Kick-off PPT 中，向全员及客户对齐边界）
| 阶段/关键活动 | 技术执行工程师 | 业务策略师 | 平台工程师 | FDE 负责人 | 基础设施工程师 |
|---|---|---|---|---|---|
| Discovery - 利益相关者访谈 | C | R | I | A | I |
| Discovery - 数据资产盘点 | R | C | C | A | C |
| Discovery - 快赢场景筛选 | C | R | C | A | I |
| Prototype - 数据管道搭建 | R | I | C | A | R |
| Prototype - 本体建模（Ontology） | R | R | C | A | I |
| Prototype - 原型应用构建 | R | C | I | A | C |
| Prototype - 客户高层 Demo | C | R | I | A | I |
| Build - 数据集成与清洗深化 | R | I | C | A | R |
| Build - 生产级应用开发 | R | C | C | A | C |
| Build - 终端用户培训 | C | R | I | A | I |
| Build - 能力回注识别与提交 | R | R | R | A | I |
| Scale - 新业务场景扩展 | R | R | C | A | C |
| Scale - 客户冠军用户培养 | C | R | I | A | I |
| Scale - 能力回注的平台实施 | C | I | R | A | I |
11.2 Discovery 阶段的团队协作模式¶
核心主旨：业务策略师主导，技术执行辅助，找到那把"金钥匙"。
在这个阶段，业务策略师（Echo）是绝对的主角。他们需要穿梭于客户的各个部门，寻找最具价值的痛点。
- 日常活动：密集开展车间访谈、绘制流程图、筛选需求。
- 技术执行的配合：技术执行工程师虽然不主导，但必须参与核心访谈（Consulted）。他们的任务是进行初步的数据资产盘点，评估业务策略师提出的场景在现有数据条件下"技术上是否可行"。
- 常见陷阱：
Warning
技术过早介入综合症：技术执行工程师听完客户抱怨后，忍不住当场想打开电脑写代码。必须克制！在没有把业务流和利益分配理清楚之前，写的代码 90%都是要推翻的废代码。
11.3 Prototype 阶段的团队协作模式¶
核心主旨："双轮驱动"，在极短时间（通常 2-3 周）内震撼客户。
一旦确定了 MVP 场景，团队进入"战时状态"。
- 协作模式：技术执行工程师和业务策略师背靠背工作。业务策略师每天拿着画好的线框图和业务逻辑草案，与技术执行确认；技术执行则疯狂地清洗脏数据，搭建本体（Ontology）模型和前端界面。
- 基础设施介入：此时，基础设施工程师开始入场，解决诸如"客户 VPN 连不上"、"内网服务器端口未开"等底层问题，扫清障碍。
- 关键节点：实行"每日 Demo"制度。每天下班前，技术执行必须向业务策略师展示当天的软件进展。两人确认无误后，准备每周五向客户 Sponsor 汇报的正式演示。
11.4 Build 阶段的团队协作模式¶
核心主旨：技术主导，追求工程卓越，同时捍卫"能力回注"。
原型得到认可后，项目进入漫长且充满细节挑战的构建期。
- 技术执行主导：处理海量历史数据的批处理/流处理，完善权限控制，重构原型期的"脏代码"。
- 能力回注的保卫战：交付压力最大时，前线团队最容易滑向"纯外包"模式——直接在现场写死代码，而不顾通用性。
Important
20%回注法则：如同 Google 的 20%创新时间，FDE 团队必须每周强制划拨 20%的时间用于代码重构和能力回注提炼。
- FDE 负责人的作用：负责人在这一阶段至关重要。当客户提出无理的定制化需求时，负责人需要站出来，用高超的谈判技巧 Say No，或者争取更多的时间，保护工程师不被需求压垮，同时为平台化留出空间。
11.5 Scale 阶段的团队协作模式¶
核心主旨：授人以渔，从 FDE 主导向客户自运营、平台标准化的双向跨越。
- 业务侧的规模化：业务策略师转移重心，从"帮客户做"转变为"教客户做"。重点是在客户内部培养冠军用户（Champion User），让他们成为系统在企业内部的布道师。
- 技术侧的规模化：此时，平台工程师成为接力棒的最终接收者。前线在 Build 阶段识别出的共性痛点（例如，某城商行和某大型险企都需要一种特定模式的知识图谱穿透查询），将由平台工程师主导，抽象并入核心产品线。前线技术执行只需协助测试。
11.6 FDE 团队与平台团队的协同机制¶
前线与后方的矛盾是 ToB 企业的永恒难题：前线嫌平台开发慢、不接地气；后方嫌前线乱写代码、破坏架构。
破局之道：闭环的反馈机制与量化 ROI
先看整条反馈环路的全貌——前线与后方如何通过"提卡→评审→集成→验证"咬合成闭环：
graph TD
pain["前线 FDE 现场<br/>发现共性痛点"] -->|提交需求卡片<br/>Feature Request| review["平台团队双周评审"]
review -->|排期| dev["平台开发集成<br/>抽象入主分支"]
review -->|驳回| wa["给出 Workaround<br/>替代方案"]
dev --> verify["前线升级版本<br/>来源项目回归（V1）"]
verify -->|V1 通过| done["V2 第二场景复用验证<br/>通过后才"毕业入库""]
verify -.->|验证不通过| dev
wa -.->|痛点再次出现| pain
style pain fill:#dbe4f0,stroke:#3949ab,stroke-width:2px
style wa fill:#f5ece0,stroke:#a8895f
style done fill:#e4efe4,stroke:#5b7a5b图 11-1：反馈环路——前线提卡、双周评审、平台集成、前线 V1 回归，再到 V2 第二场景复用验证（闭环且可回退；V1/V2 定义见第 9 章）
- 反馈环路设计（Feedback Loop）：
- FDE 在现场遇到痛点 → 提交标准化的能力回注需求卡片（Feature Request，需附带业务价值和发生频次，见第 9 章 SOP 4）。
- 平台团队双周评审 → 给出排期或驳回（给出 Workaround 替代方案）。
- 平台开发集成 → 前线 FDE 在客户现场升级版本做V1 来源项目回归（证明改造没做坏）→ 再到一个新场景做 V2 第二场景复用验证，通过后才"毕业入库"（V1/V2 见第 9 章）——"现场能跑"不等于"能毕业"，源项目回归只是第一步。
- 沟通与对齐机制：
- 双周同步会：各 FDE 负责人与平台团队产品负责人同步近期重大卡点。
- 季度路线图（Roadmap）对齐会：确保未来 3 个月平台的研发资源投入，与前线打大单的方向一致。
- 代码审核（Code Review）机制：
- FDE 编写的、试图合并入标准产品库的代码，必须经过平台架构师的严格 Review。确保代码符合全局设计规范。
- 决策模型（经济学视角）： 在处理"客户紧急需求 vs 平台标准化"冲突时，高管应引入 ROI 模型决策：
其中 \(V_{platform}\) 是标准化功能带给单个客户的增量价值，\(N\) 是预期复用客户数，\(C_{platform}\) 是平台抽象开发的成本，\(C_{custom}\) 是前线暴力写死的定制化成本。只有当 \(ROI > 1\) 且长期价值显著时，才应坚决压制前线定制冲动，投入平台研发。
11.7 每个阶段的典型冲突场景与化解方案¶
Note
本节导读：RACI 矩阵界定了"谁该管什么"，但边界再清晰，阶段切换与多角色交错时仍会爆发冲突。本节把四个阶段最典型的冲突提前"剧透"出来，给出症状 → 根因 → 化解动作（谁做什么）的固定分析模板，让 FDE 团队在冲突发生前就有预案，而不是临场救火。冲突本身不可怕，可怕的是"没人认领、无限拖期"。
冲突化解的通用纪律：先对齐目标（Why），再对齐动作（Who/What）。任何一个冲突，先坐下来确认双方对"这个阶段的成功标准"理解是否一致——多数冲突的根因并不是某一方不配合，而是对"现在到什么程度算好"没有共识。
冲突一：Discovery 期业务部门与 IT 部门目标不一致¶
| 维度 | 内容 |
|---|---|
| 症状 | 业务部门要"快、要全、要漂亮"，IT 部门处处拦：要安全审计、要走数据审批、强调"底层系统不能动"。访谈时业务抱怨 IT 是"绊脚石"，IT 抱怨业务"不懂规矩"。需求一变再变，快赢场景迟迟锁不定。 |
| 根因 | Discovery 期业务与 IT 两个部门的考核目标与风险偏好不同：业务背着业绩指标要快赢，IT 背着稳定性与合规责任要保守。FDE 若只贴着业务做，会失去 IT 的信任与配合；只贴着 IT 做，又找不到业务真正的痛点。 |
| 化解动作 | - 业务策略师牵头，在访谈初期就把 IT 代表请进同一间会议室，明确三方共同的"问题定义"，而非各自埋头画图。 - FDE 负责人在项目开工会上推动形成书面共识：本阶段唯一目标是"锁定一个可验证的快赢场景"，让业务与 IT 都看到"先解决这个、其他以后再谈"的共同底座。 - 技术执行工程师提前做数据资产盘点时，把"IT 最担心的数据权限/合规红线"单独列一张清单，主动给 IT 一个"我们替你兜住风险"的姿态，化解对抗。 - 若双方仍僵持，FDE 负责人将冲突升级到客户 Sponsor，请其拍板阶段优先级。 |
Tip
一句话心法：Discovery 期不做"业务 vs IT"的二选一，而是把两个部门都变成"找场景"的自己人——让 IT 成为问题定义的一部分，而不是审批的对象。
冲突二：Prototype 期销售/客户临时插入紧急需求，打乱原型范围¶
| 维度 | 内容 |
|---|---|
| 症状 | 原型进行到一半，客户高层或销售突然带来"更急的需求"："既然你们在，顺便把这个报表也做了""下个季度要上汇报，加个模块吧"。原型范围像滚雪球，2-3 周的"战时冲刺"被不断打断，核心 Demo 反而做不完。 |
| 根因 | Prototype 的目标是"快速证明一个 MVP"，但业务侧对"原型"与"正式交付"的边界感知模糊，把 FDE 在场误当成"免费需求池"。销售为了维系客户关系，不愿 Say No，反而帮着加需求。 |
| 化解动作 | - 技术执行工程师把"本周原型范围"冻结成一张可见的清单（白板/共享文档），任何新增需求都进"待办池（Backlog）"而非当场改范围，用可视化让"范围正在膨胀"肉眼可见。 - 业务策略师用第 6 章原型期的客户期望管理话术回应新增需求："这个很有价值，我先记入 Backlog，原型期聚焦证明主场景；它更适合进 Build 或二期，我们评估后再答复。"——既接住情绪，又不打乱节奏。 - FDE 负责人与销售对齐：销售的新增需求必须走书面需求登记，并明确"原型期砍需求的授权在谁手里"；紧急到必须插入的需求，由负责人单独评估工时与风险后决定，而不是默认接受。 - 对强行插入的需求，坚持"先出原型、后谈扩容"：把主场景的 Demo 做扎实，用成功的 Demo 反过来证明"先把这件事做成，比摊子铺大更重要"。 |
冲突三：Build 期"原型=上线"误解导致的工期挤压¶
| 维度 | 内容 |
|---|---|
| 症状 | 客户看了能跑的原型后，误以为"这不就行了吗？"，拒绝为 Build 的三个月工期买单，甚至要求"按原型原样上线"；要么压缩工期逼 FDE 仓促交付，上线后系统必崩、返工成山。 |
| 根因 | 这是第 6 章原型期的客户期望管理没有做好留下的"债"——Demo 时只展示了"能跑"的惊艳，却没埋下"原型 ≠ 生产"的三颗种子（原型只能看问题、沙箱非生产、Build 才能规模化）。客户因此对 Build 的增量价值无感。 |
| 化解动作 | - 业务策略师回顾第 6 章期望管理：复盘 Demo 是否展示了"原型看到问题但解决不了"的环节；若没埋种，则在 Build 开工前补一次"原型能力边界清单"说明会，明示哪些是原型演示、哪些必须生产化。 - 技术执行工程师给出量化的"原型 vs 生产"差距表：数据量级、权限、可扩性、安全审计各差多少，用事实让"按原型上线"的不可行性可见。 - FDE 负责人把 Build 的排期拆成与业务价值挂钩的里程碑，争取把"原型已覆盖 1 个场景、Build 覆盖 5 个、ROI 是 X 倍"的增量价值讲给客户 Sponsor，扭转"Build=白花钱"的认知。 - 防守底线：明确"原型跑在沙箱、要进生产必经安全与合规审计"，这是不可让步的红线，也是争取 Build 工期的挡箭牌。 |
Important
"原型=上线"是四阶段中最贵的误解。 它的预防只能在 Prototype 期（第 6 章期望管理）完成，Build 期只是补救。任何 FDE 团队都应在原型 Demo 时就反问自己一句："客户看这场 Demo，会不会误会系统已经可以上线了？"——会，就立刻把误解的种子拆掉。
冲突四：Scale 期冠军用户流失或客户团队接手意愿不足¶
| 维度 | 内容 |
|---|---|
| 症状 | 刚培养起来的冠军用户（Champion）被调岗/离职，或客户业务方觉得"这系统是 FDE 的，不关我们事"，系统上线后无人维护、无人扩展，FDE 一撤就变成"搁板软件"（呼应第 8 章变革管理的失败模式）。 |
| 根因 | Scale 的核心是"授人以渔"，但组织变革最怕单点依赖与责任悬空：冠军用户只培养了一个人、客户团队没有把"接手"写进考核，FDE 撤场后能力断档。 |
| 化解动作 | - 业务策略师在 Scale 期培养冠军用户网络（呼应第 8 章的冠军用户网络建设），不求单点，而是一支覆盖各业务条线的种子队伍，即便个别人流失也不会断档。 - FDE 负责人推动客户把"系统自运营"写进客户团队的关键绩效与交接节点：明确"谁对上线后的运行负责"，而不是默认 FDE 无限期驻场。 - 技术执行工程师/平台工程师配合产出可自服务的材料——运维手册、值班 SOP、健康度看板（呼应第 7 章"可运营移交"标准），把"接手门槛"降到客户团队能独立承接的水平。 - 按第 8 章 FDE 撤出的三级路线图（FDE 主导 → 客户主导+FDE 辅导 → 客户自运营）设置逐步撤出的节奏与健康退出指标，发现客户迟迟接不住时及时回拉辅导，而不是硬撤或无限驻场。 |
Note
四段冲突的共性规律：前三个冲突（Discovery、Prototype、Build）的根因几乎都指向对"阶段边界与成功标准"的共识缺失，第四个（Scale）指向单点依赖与责任悬空。因此 RACI 矩阵 + 清晰的分阶段目标声明 + 第 6 章期望管理 + 第 8 章变革管理，是化解这一切的"总开关"。
11.8 跨区域/远程 FDE 团队的协作规范¶
Note
本节导读：本章之前的角色协作假设团队"在一起"。但中国大客户跨省部署是常态：总部在北京、数据中心在上海、业务现场在成都，FDE 只能"线上为主、驻场为辅"。本节回答远程协作最锋利的三个问题：谁驻场、异步怎么同步、怎么防止"驻场即失联"。
11.8.1 远程与驻场的分工原则¶
| 分工维度 | 驻场 FDE | 远程 FDE |
|---|---|---|
| 定位 | 客户现场窗口，负责"贴近业务"的高频互动 | 支撑大后方，负责"耗费专注"的深度技术工作 |
| 适合承担 | 车间访谈、现场 Demo、客户关系维护、冠军用户辅导、环境问题现场排查 | 数据管道搭建、代码重构、Ontology 建模、文档与 Playbook 沉淀、平台回注准备 |
| 不适合承担 | 需要长时间无打扰专注的编码工作 | 需要面对面信任与即时反应的业务对齐 |
Tip
"慢工给远程、快活给驻场"：驻场 FDE 的时间被客户碎片化占用是必然的，把需要连续 2 小时以上专注的编码工作硬塞给驻场，往往是低效的来源。反过来，远程 FDE 也别垄断"写代码"，否则会与客户业务脱节——驻场要定期伸手进技术、远程要定期贴近业务，让两类人双向"漂移"，呼应全章的"角色漂移"主题。
11.8.2 异步沟通规范：什么走文档/工单，什么必须同步会议¶
Important
异步优先、同步兜底：跨区协作的默认方式应是可追溯的异步沟通，同步会议只用于"不可延迟的事"。这条纪律能最大化减少跨区的时间窗错位，也让责任留痕。
| 沟通类型 | 事项示例 | 载体 | 响应时效 |
|---|---|---|---|
| 必须异步（走文档/工单） | 需求变更、问题/缺陷上报、权限申请、环境变更、需求回注卡片、每周 Demo 说明 | 工单系统 / 共享文档 / 回注卡片（见第 9 章 SOP 4） | 24h 内应有回复或认领 |
| 必须同步（会议/视频） | 每日站会、Gate 评审、客户高层 Demo、范围冲突裁决、复盘 | 视频会议 + 会后纪要 | 当场解决或明确结论 |
| 二者皆可（先异步后补会议） | 需多方拍板的设计决策、跨区需求协调 | 先写文档对齐事实 → 会议只讨论分歧 | 会议后 1 个工作日产出结论 |
Note
一条金线：凡是会产生"责任结论"的事（谁做、做到什么程度、何时交付），一律落到文档/工单留痕；凡是"纯信息同步"且能异步消化的事，也优先异步。只有"需要即时来回澄清、且影响关键路径"的事，才动用同步会议——否则会议越多，跨区团队越疲惫。
11.8.3 每日站会与周度节奏¶
- 每日站会（线上，15 分钟以内）：固定时段，跨区全员参加。只回答三问——昨天完成什么、今天做什么、有无阻塞。站会产出三项物：今日风险清单、需横跨时区协调的事项、当日 Demo/汇报提醒。站会不解决具体问题，具体问题进异步工单。
- 周度节奏（两级）：
- 周中冲刺会：技术执行与业务策略对齐本周原型/Build 进展与卡点（呼应 Prototype 期"每日 Demo"的周化形态）。
- 周五周报/复盘会：向客户 Sponsor 与 FDE 负责人汇报阶段性成果，同步下周计划；重大变更在周五前完成决策，避免跨周末悬置。
- 节奏红线：跨区项目不允许出现"一周以上没有同步动作"的状态——超过一周没有站会、没有产出物、没有工单更新，默认视为风险，必须主动告警。
11.8.4 共享工作区与 Playbook 沉淀¶
- 单一事实来源（Single Source of Truth）：项目相关文档、代码、数据资产、决策记录，全部收敛到一个共享工作区（Confluence/Wiki/代码仓库的组合），禁止"文件在个人的电脑/聊天里"。
- Playbook 是共享工作区的心脏：跨省项目是 Playbook 最佳的"产粮地"——把"这个省的客户有什么特点、这套系统怎么接、踩过什么坑"沉淀成可复用的作战手册（呼应第 12 章的 Playbook 体系）。
- 沉淀时机：不是项目结束才写，而是发生一次"重复劳动"或"踩坑"后当场沉淀；跨区异地最容易重复踩同一个坑，谁踩了坑谁负责把解法写进 Playbook，作为绩效加分。
Tip
异地协作的"信息不是越多越好，而是越结构化越好"。与其在群里刷屏同步，不如把每个决策都写成"背景—结论—责任—时间"四段式条目，放进共享工作区——这才是远程 FDE 真正能复用的协作资产。
11.8.5 时间区/跨省现场支持轮换与"防止驻场即失联"¶
- 驻场轮换：跨省项目需长期驻场的，实行定期轮换制（例如每 4-8 周轮换一次驻场人员），防止单一工程师长期脱离后方、身心透支（呼应第 12 章的轮岗机制与驻场轮换防倦怠的防范）。轮换交接必须产出《交接文档》，确保知识不随人走。
- 现场支持轮值：建立"现场支持值班表"，谁在哪个省市、谁的手机号/IM 负责当天响应，全局可见；客户只需找得到"今天该找谁"。
- 防止"驻场即失联"的信息透明机制：
- 驻场 FDE 每日在共享工作区留一条"驻场日志"：今天见了谁、发生了什么、有无需要后方支援的卡点——这是驻场与后方的"信息锚点"。
- 后方负责人每日看看驻场日志，主动发现"这个驻场是不是好几天只报平安、没有实质进展"，及时干预。
- 驻场与后方的对齐会议固定化（至少每周一次），不让驻场变成"被遗忘的孤岛"。
- 关键决策（范围变更、交付承诺）禁止驻场单点口头拍板，必须同步到共享工作区并通知后方负责人，避免"驻场嘴上答应了客户、后方不知道也没资源"的失联黑洞。
Important
"驻场即失联"是跨区 FDE 团队最大的隐形杀手。 一个驻场工程师在客户现场忙了一整天，若他当天唯一的"音讯"只是群里一句"今天正常"，那后方团队其实对项目真实状态一无所知。信息透明的标准不是"每天有消息"，而是"每天有可追溯的进展记录"。
11.9 FDE 与客户方 IT 团队的协作边界¶
Note
本节导读：前面讲的是 FDE 团队内部与平台团队的协作，本节把边界延伸到客户方的 IT 团队——系统最终要交到他们手里。边界不清，要么 FDE 越权动客户生产环境惹出事故，要么客户 IT 甩手不管导致"上线即烂尾"。本节回答：谁管什么、争议怎么升级、权限变更怎么留痕、最终移交什么。
11.9.1 谁管什么：交付边界一表说清¶
| 责任域 | FDE 负责 | 客户方 IT 负责 |
|---|---|---|
| 系统与数据 | 交付系统的搭建、数据管道、Ontology、应用开发与迭代 | 生产环境的最终发布、运行时治理 |
| 环境与权限 | 申请开发/测试环境资源、梳理数据接入需求、提出权限申请 | 生产环境、基础网络、账号权限的发放与审计 |
| 运维与交接 | 交付期内提供运维支持、SOP 文档、值班培训 | 交接后的日常运维、监控值守、故障响应 |
| 安全与合规 | 交付方案符合客户要求、配合安全审查 | 安全审计、合规审批、等保/信创合规把关 |
Tip
一条边界心法：FDE 管"交付系统与数据管道"，客户 IT 管"生产环境、权限与运维交接"。 FDE 可以在客户生产环境做受控发布，但发布动作、生产权限的变更，必须由客户 IT 执行或授权——越权的代价是信任的崩塌。
11.9.2 争议怎么升级：联合例会 + 升级通道，避免直接对抗¶
- 联合例会（固定化）：FDE 与客户 IT 建立双周联合例会，同步交付进展、环境与权限问题、风险清单。让"问题"在例会里公开讨论，而不是让 FDE 工程师与 IT 工程师私下互相较劲。
- 升级通道（分级）：
- 一线层：FDE 技术执行 ↔ 客户 IT 对接人，处理日常环境/数据/权限问题，24h 内响应。
- 管理层：问题 3 个工作日未妥善解决，升级到 FDE 负责人 ↔ 客户 IT 负责人，拍板资源与优先级。
- 决策层：涉及生产事故、范围大变、合规红线，升级到客户 Sponsor 与 FDE 项目总监。
- 升级的纪律：升级不是"告状"，而是带着事实与方案去升级——说明问题、已做尝试、需要的决策，让上级做选择题而非问答题。避免直接对抗：任何争议先记录在案，再走升级通道，严禁在客户现场与 IT 当面争执。
Warning
对抗的代价：FDE 与客户 IT 一旦在客户现场直接对抗，输掉的不仅是这一次合作，更是客户对 FDE 团队专业度的整体信任。所有争议先落文档，再上通道，最后才谈对错。
11.9.3 权限与变更的书面留痕¶
- 权限申请留痕：FDE 需要的一切权限（VPN、堡垒机、数据库账号、生产发布权限），一律通过工单/书面审批申请，保留申请人、审批人、有效期、使用目的。禁止"借账号""共用权限"的裸奔式操作。
- 变更留痕（Change Request）：任何对客户生产环境的变更（发布、配置改动、数据操作），必须先写变更单：变更内容、原因、影响范围、回滚方案、执行人、审批人，经客户 IT 审批后执行。
- 发布与回滚记录：每次发布保留版本与时间戳；一旦出问题，能立刻回溯"谁、在何时、改了什么"。
- 统一到客户变更流程：FDE 的变更尽量纳入客户既有的变更管理流程，而不是另起炉灶——既降低摩擦，也让留痕"客户 IT 看得懂、查得清"。
Important
"留痕"是两个目的：一是保护 FDE——出了生产事故，书面的变更与权限记录能证明"动作合规、边界清晰"；二是保护客户 IT——他们要对生产负责，看得见、查得清的记录是他们在合规审计面前的底气。留痕不是桎梏，是双方共同的安全网。
11.9.4 最终要移交什么给客户 IT：交接清单¶
Note
这是 Scale 阶段"可运营移交"落点的甲乙双方交接清单（呼应第 7 章的"进入能力转移的技术条件"与第 8 章的"客户自运营"）。本节只回答"交什么、验什么、签什么"——"客户如何从观摩到自治、FDE 何时撤"的问题归第 8 章，不在这里重复。逐项打勾，双方验收签字后才视为本阶段交接完成。
甲乙分工：乙方（FDE）交——文档、监控、代码与配置、权限等交付物与 SOP；甲方（客户 IT）验——能否独立照着操作、独立巡检、自主回滚；双方签——交接确认单（含验收要点勾兑与遗留问题清单、时间节点）。
| 类别 | 交接物 | 验收要点 |
|---|---|---|
| 文档 | 运维手册、值班 SOP、架构说明、数据字典 | 客户 IT 能独立照着操作，无需 FDE 陪同解释 |
| 监控 | 数据管道健康度看板、告警规则、指标定义 | 客户能看到"昨晚管道跑成功了吗"，异常可自行定位 |
| 代码与配置 | 代码仓库权限移交、配置项清单、回滚方案 | 客户 IT 具备版本管理与回滚能力 |
| 权限 | 生产发布、权限、账号的最终归属与回收清单 | FDE 撤离后不再持有过期的生产权限 |
| 知识 | 疑难问题 FAQ、常见故障处置、Playbook 移交（呼应第 12 章的知识管理） | 客户团队能自服务、未来可自行扩展新场景 |
| 联系人 | 明确交接后的运维值班联系人矩阵（FDE 留一位支持接口 vs 客户 IT 值班人） | 客户知道"出了问题第一时间找谁" |
Tip
交接的验收标准只有一句："FDE 完全不在场时，客户 IT 能否独立让系统正常跑、正常监控、正常应对故障、正常做小扩展？"——答案是"能"，交接才算完成；答案含糊，就继续辅导，而不是把系统"扔"过去。
Important
本章小结：同一角色在四个阶段的权责会漂移，RACI 矩阵把这种漂移写清楚。团队与平台、远程成员、客户 IT 之间的协作边界同样需要事先约定，交接以"FDE 不在场时客户能否独立运维"为标准。