第十一章 复盘与资产沉淀
11.2 六大失败模式自查
承前：11.1 节的五步复盘框架解决的是"怎么复盘一个已经结束的项目"。但复盘有个天然局限——它是事后的。如果一个项目在第三周就注定失败，第十二周再精彩的复盘也只是验尸。有没有办法在项目中途就识别出失败的前兆？这一节我们把常见 FDE 项目失败模式归纳成六种，每一种都给出"识别信号"（项目进行中出现什么现象说明你正在滑向这个失败）和"应对动作"（出现信号后该立刻做什么）。它既是复盘的检查清单，更是每周自查的预警雷达。
11.2.1 失败模式从哪来
先说明这一节内容的性质：这六大失败模式不是某一家公司的官方分类，而是对大量 To B AI 项目失败案例的归纳——素材来自三类公开来源：Palantir/Forward Deployed 模式的行业分析、国内 SaaS 落地失败案例的行业讨论、以及本课程前十章沙盘里埋过的每一个坑。
归纳的逻辑是按项目阶段和归因主体划分：有的失败归因于客户，有的归因于你自己（FDE），有的归因于产品或组织。把归因主体标出来很重要——因为应对动作完全不同：归因于客户的，你要调整的是合同和预期管理；归因于自己的，要调整的是工作方法。
六个失败模式一览：
六大失败模式（按归因主体分组）
客户侧 FDE 自己 产品/组织
┌──────────┐ ┌──────────┐ ┌──────────┐
│ F1 无赞助人 │ │ F3 demo陷阱│ │ F5 定制泥潭 │
│ F2 指标漂移 │ │ F4 范围蔓延│ │ F6 无移交路径│
└──────────┘ └──────────┘ └──────────┘下面逐个拆解。每个模式的叙述结构固定：典型剧情（沙盘或真实案例）→ 识别信号 → 应对动作。
11.2.2 F1：无赞助人失败——"项目活着，但没人需要它"
典型剧情：项目签约时有发起人（青禾的增长副总裁），但项目中期发起人调岗、失势或被架空（W7 数字化总监空降就是这个剧情的温和版本）。项目技术上一切正常，但预算续期、跨部门协调、验收签字全都没人推动，项目在"技术上活着、组织上死亡"的状态里拖到合同到期。
识别信号：
- 发起人连续两次会议缺席，且没有派有决策权的代表；
- 跨部门数据/资源请求的响应周期从 3 天变成 2 周；
- 你问"验收标准谁最终签字"时，得到两个以上互相推让的答案；
- 客户方项目对接人开始回避谈论"项目之后的预算"。
应对动作：第一优先级不是赶进度，而是重建赞助关系。具体三步：向现任对接人书面确认项目商业价值表述是否仍然成立；寻找新的潜在赞助人（往往是被项目数据利益影响的另一位高管——青禾案例里，数字化总监接管后反而成了更强势的赞助人）；若两周内无法确认任何有预算权的赞助人，向自己公司报告风险并启动合同层面的范围收窄谈判，把项目收缩到"已验证的价值岛"上保住口碑。
11.2.3 F2：指标漂移失败——"赢了战役，输了定义"
典型剧情：项目开始时指标是复购率，中途变成"会员活跃度"，验收前又变成"数字化程度"。每次指标变化单看都合理，但项目结束时你已经无法证明任何一件事。更常见的温和版本：指标没变，但归因口径漂了——复购率确实涨了 2 个百分点，但客户市场部坚持那是同期促销活动的功劳，你拿不出对照组数据反驳。
识别信号：
- 复盘每次周会纪要，"成功"的定义出现三个以上版本；
- 客户开始用"感觉""氛围"类词汇评价项目，而不是数字；
- 没有人能说清验收时会用哪份数据、哪个口径算指标。
应对动作：这是 W8"确认策略"要救的场景——书面化、版本化、签字化。任何指标或口径变更必须走变更记录（谁提出、为什么、新旧口径数值各是多少）。青禾沙盘里 W8 的"验收口径书面确认"就是针对这个失败模式的疫苗。如果发现自己已经在漂移中，应对动作是立刻冻结当前指标版本，发起一次专门的口径对齐会，用"如果没有这个 Agent，这 2 个百分点会在吗"的对照组问题重建归因可信度。
11.2.4 F3：demo 陷阱——"惊艳之后是深渊"
典型剧情：W4 数据诊断 demo 大获成功，客户全员兴奋，高管当场要求"两个月内全公司上线"。为了维持这份兴奋，你持续投入做更炫的演示，而不是更深的治理。demo 越来越好看，数据底座越来越薄，直到某个生产环节崩溃。这是 FDE 特有的失败模式：demo 的正反馈和交付的负反馈在争夺你的时间。
识别信号：
- 你最近两周的产出主要是演示材料而不是生产代码/数据治理；
- 客户高管只在你演示时出现，不参加数据问题评审；
- "demo 数据"和"生产数据"已经是两套东西，且差距在扩大。
应对动作：把 W4 demo 的兴奋兑换成资产而不是加演——当场把兴奋转化为 SOW 签字、数据治理授权、验收口径确认（这正是第 4 章 demo 设计的意图）。如果已经陷进去，应对动作是一次"预期重置会"：主动演示一次失败案例（Agent 在脏数据上出错的真实样子），用受控的方式戳破 demo 气泡，然后把资源转回治理。先自曝其短，好过被审计自曝（W9 客户审计那一章的逻辑）。
11.2.5 F4：范围蔓延——"什么都说好，什么都做不完"
典型剧情：客户每个部门都提需求：复购 Agent 之外，门店店长要排班助手，财务要发票审核，客服要话术推荐。你碍于关系都说"可以看看"，三个月后每个都是半成品。To B 项目的范围蔓延比 To C 产品的功能蔓延更致命，因为合同和验收在那里卡着。
识别信号：
- 待办清单里超过 30% 的条目不在 SOW 范围内；
- 你开始用"顺手就做了"来描述那些范围外工作；
- 核心指标的进度连续三周没有推进。
应对动作：严格走第 3 章 SOW 的需求定义与变更控制流程：范围外需求一律进"二期清单"，用一句话记录价值假设和预估工作量，不做任何承诺。范围蔓延的心理学本质是你在用免费劳动购买客户好感——但客户真正会感谢你的时刻只有一个：验收通过的时刻。青禾沙盘里"复购率北极星"的设计（所有需求对齐到唯一指标）本身就是抗范围蔓延的架构性防御。
11.2.6 F5：定制泥潭——"每个客户都是一次重写"
典型剧情：为了满足青禾，你在产品外写了大量一次性代码：私有会员 ID 映射逻辑、特制的门店权限模型。项目验收成功，但这些代码不可复用，下个客户来又要重写一遍。这个失败模式的账要在组织层面才算得清：单个项目看是盈利的，十个项目累计看是亏损的——这就是 Palantir 早期被质疑"定制化不可扩展"的原因，也是后来整个行业把"前置部署经验产品化"当作核心命题的原因。
识别信号：
- 你在项目里的私有代码量超过产品配置量的 3 倍；
- 产品团队回复你的定制需求时说"这个应该在前置层解决"；
- 第二个客户来了，你发现第一个项目的代码几乎不能复用。
应对动作：执行下一节（11.3）的资产分层纪律：定制代码出现时立刻分类——客户专属（留在客户环境，脱敏后只留方法论）、行业可复用（参数化成模板）、产品改进（提给 PM）。控制定制泥潭的关键时机是写第一行私有代码之前：先问"这个逻辑参数化后能覆盖几个客户"，答案低于 2 就要警惕。这也是本课程反复强调的"出现第二个样本再沉淀抽象层"原则的另一半——过早抽象和过晚抽象同样昂贵。
11.2.7 F6：无移交路径——"你走了，系统死了"
典型剧情：项目成功上线，验收签字，你奔赴下一个客户。三个月后客户内部没人会调 prompt、没人懂评估集怎么更新、没人知道语义层怎么加字段。系统性能缓慢退化，客户把原因归结为"产品不行"，续约谈判破裂。FDE 项目最大的隐性失败：交付了一个依赖你本人的系统。
识别信号：
- 所有运维问题都直接找你，客户内部无人认领；
- 客户团队没有出现在任何评估迭代会议里；
- 文档存在，但客户方没人读过（问"上次谁看过 runbook"全场沉默）。
应对动作：从项目中期就开始"让自己变得可离开"：每个关键操作配 runbook，每个决策写决策记录（为什么这么做），刻意安排客户团队主导至少两次评估迭代（你在旁边看）。验收标准里加入"客户独立运营一周"的实战检验。移交不是最后一天的动作，是贯穿后半程的过程——第 8 章"放权路径"对内（Agent 权限）讲过同样的逻辑，对外（客户组织）完全同构。
11.2.8 六模式自查表与使用方法
把六个模式压缩成一张每周 10 分钟的自查表：
| 模式 | 每周自查问题 | 红线信号 |
|---|---|---|
| F1 无赞助人 | 发起人本周有实质性参与吗？ | 连续 2 周无 |
| F2 指标漂移 | 我能用一句话说出今天的验收口径吗？ | 说不出口径 |
| F3 demo 陷阱 | 本周生产资产 vs 演示资产的工时比？ | < 5:5 |
| F4 范围蔓延 | 待办里范围外条目占比？ | > 30% |
| F5 定制泥潭 | 本周新写的私有代码有分类去向吗？ | 无去向 |
| F6 无移交 | 客户团队本周独立完成了什么？ | 连续 3 周为 0 |
使用纪律：每周五填一次，任何一格触红线，下周第一个日程就是针对该模式的应对动作。这比月底复盘提前 3 周发现问题——而 FDE 项目里，3 周往往就是"可挽回"和"不可挽回"的分界线。
沙盘收尾：青禾项目验收后，你把这张自查表回填到过去 11 周的周报上——发现 F3 在 W5 触过线（你确实花了太多时间打磨 demo）、F6 在 W9 之前一直亮红灯。这就是复盘和自查的关系：自查表是运行时的看门狗，复盘是关机后的验尸报告，两者合起来，才构成对失败模式的完整防御。
11.2.9 要点总结
- 六大失败模式按归因主体分三组：客户侧（无赞助人、指标漂移）、FDE 侧（demo 陷阱、范围蔓延）、产品组织侧（定制泥潭、无移交路径）。
- 每个模式的应对动作完全不同——先判归因，再选动作，不要用加班解决组织问题。
- 自查表每周跑一次，任何红线触发下周第一优先级就是应对动作；比事后复盘提前 3 周发现问题。
- demo 的兴奋要当场兑换成合同资产；定制代码要在写之前问"参数化能覆盖几个客户"。
- 交付依赖你本人的系统是隐性失败——"可离开性"应该进验收标准。
参考资料
- Palantir Forward Deployed Software Engineer Interview Guide — 前置部署模式的工程文化分析，含定制化与可扩展性张力的讨论
- Palantir's Skywise: the Runway to Monopolize the Sky — Skywise 如何把定制部署经验平台化，反衬"定制泥潭"的商业代价
- 从客服到客户成功：SaaS 增长的真正起点 — 36 氪对国内 To B 项目"交付后死亡"现象的分析，F6 无移交路径的国内样本
- What Is a Good NRR for SaaS? — 无移交路径失败最终在续约/NRR 指标上显形的量化背景