交付复盘与产品化沉淀

1. 复盘的对象是决策与机制，不只是项目故事

项目完成后，最常见的复盘是列出做了多少功能、开了多少会议、解决多少问题。这些可以描述工作量，却不能说明下一次如何更好地交付。FDE 复盘应连接原始目标、当时证据、所作决定、实际结果和后续动作。

本周把 12 周材料分为客户专属资产、行业模板和产品通用改进，并验证迁移条件。复用不等于复制客户代码，更不等于把客户数据和策略改个名字后公开。

2. 五步复盘如何落到可检查的记录

先回到最初目标，避免用最终做成的事情倒过来修改目标；再按相同口径评估结果，区分已达、部分达到、未达和未验证；接着分析原因，查阅当时的证据与决定，不用事后全知视角责备个人；然后总结适用条件；最后形成具体改进动作。

一次有效复盘应能指出至少一个“当时合理但后来证伪”的判断。不是所有失败都来自疏忽，也不是所有成功都可归因于方案本身。保留不确定性，比写“加强沟通、持续优化”更有用。

3. 六类常见失败模式

以下是本课用于自检的失败模式，不是来自客户数量统计。每一类都要能对应早期信号和可执行修正。

不要把这张表当作万能诊断。若项目失败来自采购取消、组织调整或外部政策变化，也应如实记录。能控制、能影响和只能观察的因素，要分别处理。

4. 资产分层：哪些能带到下一项交付

客户专属资产包含真实数据、内部策略、合同、权限映射和特定系统秘密，默认不进入公共模板。行业模板可以包含去掉客户身份后的对象模式、指标结构、任务与评估样例，但仍需检查权利与再识别风险。产品通用改进则是跨客户成立的能力，例如参数绑定确认、租户级工具策略或可扩展审计字段。

“匿名化”不是只删客户名字。结合行业、时间、门店规模和特定事故，仍可能识别客户。公开教材应使用独立合成数据和改编问题，不复现私有策略或内部组织细节。

5. 产品反馈要比“客户需要这个功能”更具体

一份可处理的产品反馈包括：原始问题、现有能力、复现步骤、影响范围、临时适配、候选通用接口、兼容风险和测试。第 8 周的确认绑定与第 9 周的客户审计字段，可以作为本课候选反馈。

问题：确认状态只能表示 yes/no，无法绑定版本化动作参数。
现场影响：用户确认后人群或金额变化，执行端无法可靠检测。
租户适配：在客户扩展层保存 payload digest 与有效期。
通用提案：核心提供 confirmation record + validate hook。
兼容要求：现有只读工具不受影响；默认写动作仍需明确策略。
回归样本：改金额、换人群、过期、重放、跨租户、权限撤销。

出现第二个场景后再检验抽象：同一个接口能否用于标签、设备调度或文档发布？如果不得不加入大量零售专属字段，就可能还只是行业适配，而非稳定产品能力。

6. 私有知识如何转成团队知识

拒绝理由、争议记录和失败样本往往比“客户同意了”更有复用价值。记录“为什么这次不用向量检索”“为什么没有自动执行”“为什么撤回某个指标”，可以帮助下一位 FDE 避免重复试错。

建议知识条目包含：问题、上下文、曾尝试方案、选择理由、失败条件、证据位置、适用范围和维护者。敏感原始证据仍留在原有权限范围内，公共方法可以只引用受控记录 ID。不要把所有聊天记录直接复制到全员知识库。

7. 从零售迁移到其他行业

迁移到销售研究时，Member 可能变成 Account/Contact，活动建议变成带证据的客户研究与下一步行动；身份、来源时效、工具权限与结果评估仍可复用，但“30 天复购”和发券规则不能直接迁移。知识服务需要产品型号、文档版本和专业边界；供应链需要事件时序、资源约束和调度后果。

金融和医疗等场景还需要更严格的专业责任、数据与合规审查，不因本课在零售沙盘中通过测试就获得部署资格。迁移分析应写清可直接复用、需重配、需重做和不能承诺四类内容。

可将 Airbus 案例与 Morgan Stanley 案例按进场、需求、原型、变更、验收、沉淀六栏阅读。公开资料未披露某一栏时写“未披露”，不要为了填满图表编造实施细节。

8. 必做作业、思考与验收

必做：提交完整复盘、资产分层清单、两个产品反馈候选和一个跨行业迁移分析；准备答辩证据索引。至少有一项反馈包含复现步骤与回归测试，至少有一项资产被明确判定不应公开或不值得通用化。

思考：如果下一客户恰好提出一个看似类似、但权限和动作后果完全不同的需求，你如何判断复用是否真的减少成本，而不是把风险一起复制？

进阶：写一份面向新 FDE 的工程复盘，围绕具体错误、识别信号和修正方法，不披露客户身份，不用成功故事代替证据。

验收要求：复盘包含未达与反例；资产权利和敏感性已检查；模板有适用条件；产品提案可复现；迁移说明有不能复用的部分；改进动作有责任与验证方式。下一项目应能实际使用这些产物，而不只是阅读一段总结。