本章一句话:技术再好,交付节奏错了、灰度翻车了、客户不信你、能力没留下来——项目照样失败。本章讲 CDEF 之外、却决定成败的"现场软工程"。

10.1 MVD(最小可行交付):先跑通,再完美

MVD(Minimum Viable Delivery,最小可行交付)是 FDE 交付节奏的第一原则:用最短时间,做出一个能在客户真实环境跑通、产生可感知价值的最小系统。

为什么要 MVD

• 快速验证假设:你以为是痛点的东西,跑通才知道客户买不买账;
• 建立信任:客户看到"真跑起来了",才会投入更多资源;
• 降低风险:小步快跑,错了能及时调整,避免大投入打水漂;
• 抢占心智:在客户内部政治里,"先跑通的人"占主动。

MVD 的边界 MVD 不是"简陋的 demo",而是"最小但真实可用"的系统。区别在于:

• demo:用假数据、跳过异常、只演示 happy path;
• MVD:用真实数据(哪怕少量)、处理关键异常、能完成至少一个真实业务闭环。

MVD 的范围圈定 FDE 在 Design 阶段就要回答:"最小的、能让客户感受到价值的那一块,是什么?" 通常:

• 选一个高频、痛点强、价值可量化的场景;
• 只做核心闭环,砍掉所有"锦上添花";
• 用现成模型/组件,不自己造轮子;
• 时间压缩在 2—4 周。

MVD 的交付标准:客户的一线人员,愿意在真实工作里用它(哪怕只是部分替代),并且能说出"它帮我省了 XX 时间 / 提升了 XX"。一旦达到这个标准,MVD 就成功了,可以进入加固和扩展。

10.2 灰度上线:逐步放量,控住风险

灰度上线是 FDE 把系统从"MVD"推向"全量生产"的安全通道。

为什么必须灰度 AI 系统有不确定性(幻觉、误判),直接全量上线风险极大——一次大范围错误可能毁掉客户信任。灰度让风险可控:先小范围、看效果、调问题、再放大。

灰度的典型节奏

1. 影子模式(shadow):系统跑着,但不影响真实业务,只对比效果(如 AI 预测 vs 人工结果);
2. 小流量试点:5%—10% 流量走 AI,人工仍兜底;
3. 扩大:效果达标,逐步扩到 30%→50%→80%;
4. 全量:稳定后全量,人工转为抽审/兜底。

灰度的关键指标

• 效果指标:准确率、召回率(对照北极星);
• 业务指标:良品率、处理时长、成本;
• 风险指标:错误率、bad case、人工介入率、客诉;
• 系统指标:延迟、可用性、成本。

灰度的退出条件:每个灰度阶段,要有明确的"达标继续、不达标回退"标准。不达标时果断回退,不硬撑。客户更信任"敢回退"的 FDE,而不是"硬撑出事"的 FDE。

10.3 现场生存:与客户共处的艺术

FDE 的大部分时间在客户现场,能不能"活下来、混得好",是技术之外的关键能力。

现场生存的基本功

• 融入:穿得像客户的人、说得像客户的话、吃得惯客户的饭——降低"外来者"的违和感;
• 谦逊:不摆技术专家架子,尊重客户一线的经验("你们比我懂业务");
• 靠谱:答应的事做到,做不到提前说,绝不过度承诺;
• 可见:让客户随时知道你在做什么、进度如何(每日同步);
• 不添乱:不给客户 IT 增加负担,自己的环境自己搞定。

现场生存的红线

• 不碰客户生产数据未经授权(合规红线);
• 不在客户面前吐槽客户(/甲方的政治复杂,言论会被放大);
• 不卷入客户内部派系(保持中立,只对事不对人);
• 不留安全隐患(自己的代码、账号、密钥要管好)。

现场生存的本质:FDE 在客户现场,代表的不只是自己,是背后的公司。一个 FDE 的现场表现,直接影响客户对整个公司的信任。

10.4 信任建立:从"外人"到"自己人"

信任是 FDE 一切工作的前提——客户不信你,再好的技术也用不上。

信任建立的阶段

1. 初步信任(靠专业):第一次接触,靠"你懂行业、懂技术、问对问题"建立"这个人靠谱"的印象;
2. 深化信任(靠交付):MVD 跑通、解决一个真问题,客户从"靠谱"升级到"能成事";
3. 深度信任(靠人格):长期共事,客户把你当"自己人",愿意把更大的事交给你。

建立信任的具体动作

• 说客户听得懂的话:少用术语,多用客户的业务语言;
• 承认不懂:不懂就说不懂,比装懂更能赢得信任;
• 透明:进度、问题、风险,如实同步,不藏;
• 兑现小承诺:连续兑现小承诺,比一次大承诺更建信任;
• 替客户着想:主动想"怎么帮客户省成本/降风险",而不只想着自己的交付。

信任的复利:信任一旦建立,会带来复利——客户会把更多项目、更核心的系统、更高的预算交给你。这也是 FDE 商业价值持续放大的根基。

10.5 知识转移:把能力留给客户

知识转移是 FDE 避免"单点依赖"、实现可持续交付的关键——也是防 capability atrophy 的核心动作。

为什么要知识转移

• 客户不想永远依赖乙方(成本、风险);
• 监管/审计要求"系统可由客户自主运维";
• FDE 团队要解放出来做新项目,不能被老项目拴住;
• 知识转移做得好,客户满意度高,续约/扩展机会大。

知识转移的内容

• 系统文档:架构、数据流、接口、配置、运维手册;
• 操作培训:一线人员怎么用、管理员怎么运维;
• 故障应对:常见问题、处理流程、应急预案;
• 演进指南:业务变化时怎么调整、模型漂移时怎么处理;
• 决策记录:为什么这么设计(ADR,Architecture Decision Records),方便未来理解。

知识转移的方式

• 文档:可留存、可检索的基础;
• 培训:集中讲解、实操演练;
• 共建:让客户人员参与开发,边做边学(最有效);
• 陪跑:交付后一段时间持续支持,逐步放手;
• 认证:给客户人员发"通过认证",激励学习。

知识转移的检验标准:FDE 撤离后,客户团队能独立运行、维护、基本演进系统。达不到这个标准,知识转移就没完成。

10.6 交付节奏管理:周计划与阶段门

FDE 项目要有清晰的节奏管理,避免"无期限拖延"或"赶工出次品"。

周计划机制

• 每周一个可交付的小目标(周迭代);
• 每周与客户同步进度、问题、下周计划;
• 用看板/任务清单可视化进度。

阶段门机制(见第 7 章)

• Context→Design→Engineer→Feedback 每个门有明确标准;
• 达标推进,不达标回溯或调整;
• 阶段门也是与客户对齐预期、争取资源的节点。

典型项目节奏(参考)

• 第 1—2 周:Context 勘探 + 对齐北极星;
• 第 3—4 周:Design 方案 + 技术选型;
• 第 5—8 周:Engineer MVD 跑通;
• 第 9—10 周:加固 + 灰度;
• 第 11—12 周:全量 + Feedback 闭环;
• 持续:知识转移 + 运维支持。

节奏管理的本质:让客户始终知道"现在到哪了、下一步是什么、什么时候能看到价值"。这种确定性,是 FDE 给客户的重要价值。

10.7 现场抗压:沟通、冲突、延期

FDE 在现场,难免遇到高压场景,需要抗压能力:

沟通高压

• 客户高层突然关注,要你 5 分钟讲清楚价值 → 准备"电梯演讲";
• 客户技术团队质疑你的方案 → 用数据/逻辑回应,不情绪化;
• 跨部门对齐,各方诉求冲突 → 找共同利益,做取舍。

冲突处理

• 客户内部派系斗争波及项目 → 保持中立,聚焦业务结果;
• 客户需求频繁变更 → 用阶段门 + 结果定义卡守住边界;
• 与客户 IT 团队技术分歧 → 求同存异,用 PoC 数据说话。

延期处理

• 预警:发现可能延期,第一时间告知(绝不隐瞒);
• 重新对齐:和客户重新确认优先级、范围、时间;
• 交付价值:即使延期,也要交付阶段性价值(不让客户"白等")。

抗压的核心:FDE 要有"对结果负责到底"的 owner 心态——遇到问题不甩锅、不逃避,主动解决、主动沟通。这种心态,是 FDE 区别于"打工人"的精神内核。

本章小结

• MVD(最小可行交付):最小但真实可用,先跑通建信任,再加固扩展;
• 灰度上线:影子→小流量→扩大→全量,每阶段有达标/回退标准;
• 现场生存:融入、谦逊、靠谱、可见、不添乱,守合规与中立红线;
• 信任建立:专业→交付→人格三阶段,靠说人话、承认不懂、透明、兑现承诺;
• 知识转移:文档+培训+共建+陪跑+认证,目标是客户能独立运维;
• 交付节奏:周计划 + 阶段门,典型 12 周项目节奏;
• 现场抗压:沟通/冲突/延期,核心是 owner 心态,对结果负责到底。

本章来源:本书第 5—9 章、fde-delivery 技能包(60-team-survival 团队生存、70-pitfalls-checklists 踩坑清单、120-deployment-runbook 灰度)、Palantir forward deployment 文化、TSIA《4 Ways FDE Powers AI》、LinkedIn Learning《FDE in the Age of AI》、SVPG、用户库《FDE工程师完全指南》《CDEF方法论》。