模块 1 · 客户嵌入与业务翻译

模块 1 · 客户嵌入与业务翻译（第 1-2 周）

💡 一句话总结：进入客户现场的头两周，做两件事——拿到 1 份《客户业务画像 v1.0》和 1 张 Stakeholder Map。

🎯 本模块三大特点

📚 系统：模块 1 在 12 周 Residency 中的定位是地基——后面 10 周的所有工作都建立在这两周的产出之上
🔧 实战：本周产出 1 份《客户业务画像 v1.0》+ 1 张 Stakeholder Map
⚡ 不啰嗦：不堆理论，直接进客户现场

📖 学习导航

上一节	本模块位置	下一模块
Day 4 · 安全与红队演练	模块 1 / 共 8 模块（第 1-2 周）	模块 2 · 解决方案设计与 ADR

📅 两周时间表

时间	任务	产出
Day 1	入客户现场，与对接人 / 决策人 / 受益者各开 1 次会	3 份会议纪要
Day 2-3	跟客户走 1-2 天完整业务流程	1 份《现状流程地图》
Day 4-5	整理事实 / 假设 / 未知，画 Stakeholder Map	1 张 Stakeholder Map
Day 6-7	写《客户业务画像 v0.1》，发给客户 review	v0.1 文档
Day 8-10	拿到客户反馈，迭代到 v1.0	v1.0 文档

🚀 直接开始：2 个核心实战任务

任务 1：1 周内输出《客户业务画像 v1.0》

目标：把客户的模糊需求，结构化成 1 份可决策的文档
难度：⭐⭐⭐
时间：1 周

模板（在 Day 1 的 v0.1 基础上迭代）：

# 客户业务画像 v1.0

## 0. 文档元信息
- 客户名称：[脱敏处理]
- 行业 / 规模：
- FDE 派驻周期：2026-XX-XX 至 2026-XX-XX
- 文档更新：每周一更新，重大决策随时更新
- 主要对接人：[角色 / 联系方式]

## 一、客户基本信息
- 主营业务：
- 组织架构（与本项目相关的部分）：
- 关键联系人 + 角色

## 二、业务痛点（按优先级排序）
| 优先级 | 痛点 | 当前解法 | 为什么不够好 | 涉及角色 |
|---|---|---|---|---|
| P0 | [痛点 1] | [现状] | [原因] | [角色] |
| P1 | [痛点 2] | [现状] | [原因] | [角色] |
| P2 | [痛点 3] | [现状] | [原因] | [角色] |

## 三、初步假设（要验证）
- H1：[核心业务问题是 X，不是 Y]
- H2：[成功上线的衡量指标是 Z]
- H3：[技术方案可行，路径是 A]

## 四、约束条件
- 预算：[数字]
- 时间：[上线 deadline]
- 合规：[等保 / GDPR / 行业法规]
- 技术栈：[客户已有系统]

## 五、风险与缓解
| 风险 | 概率 | 影响 | 缓解措施 |
|---|---|---|---|
| 决策人申请 / 项目暂停 | 中 | 高 | 每周保持沟通 |
| 数据出域问题 | 低 | 高 | Day 1 确认数据流向 |
| 业务方配合度低 | 中 | 中 | 把业务方拉进工作流 |

## 六、下一步行动
- 本周：与 XXX 再聊 1 次 / 拿到 XXX 数据访问权限
- 下周：输出技术方案 v0.1

## 七、附录
- 会议纪要原文链接
- 现状流程地图
- Stakeholder Map

执行结果：

客户业务方签字确认的 v1.0 文档
进入 [模块 2 · 解决方案设计] 的输入

任务 2：画 1 张 Stakeholder Map（4 类角色标注）

目标：把客户方所有相关人都标到图上，定差异化沟通策略
难度：⭐⭐
时间：持续维护

模板（4 类角色 × 应对策略）：

影响力 ↑
  高 │  ⭐ 决策人（项目成败他们说了算）
     │  - 姓名：
     │  - 关心：业务 ROI、上线时间
     │  - 担心：投入打水漂、合规风险
     │  - 沟通频率：每周一次 30 分钟同步会
     │
     │     ⭐ 发起人（最初想搞 AI 的人）
     │     - 姓名：
     │     - 关心：AI 真的能解决问题
     │     - 担心：技术搞不定 / 效果差
     │     - 沟通频率：每天 1 次 5 分钟对齐
     │
  中 │   ⭐ 受益者（真正会用 AI 的人）
     │   - 姓名：共 X 人
     │   - 关心：用了省事、不添乱
     │   - 担心：学习成本、改变习惯
     │   - 沟通频率：每周收集反馈 1 次
     │
     │              ⭐ 守门人（卡审批 / 合规的人）
     │              - 姓名：
     │              - 关心：合规不出事
     │              - 担心：上线被监管挑战
     │              - 沟通频率：每 2 周同步一次进度
  低 │      ⭐ 信息源（提供数据 / 流程的人）
     │      - 姓名：共 X 人
     │      - 沟通频率：按需
     └──────────────────────────────────→ 支持度
       反对              中立              支持

执行结果：

1 张 Stakeholder Map（建议贴在项目空间，随时更新）
每个角色对应 1 句话的沟通策略

📚 系统学习：核心概念

概念 1：FDE 派驻的真实工作节奏

一句话解释：FDE 在客户现场不是"写代码 + 等反馈"，是 "每天对齐 5 个不同角色，每周交付 1 个可见成果"。

典型一天：

09:00  跟业务方 30 分钟：聊昨天用了 AI 后的感受
10:00  跟 IT 1 小时：解决 1 个集成卡点
11:00  跟决策人 15 分钟：汇报本周进度
14:00  自己写代码 4 小时：跑通 1 个新功能
18:00  写当日工作日报，发给 mentor + 客户对接人

概念 2：业务画像的"事实 / 假设 / 未知"三分法

为什么重要：FDE 拿到信息后第一件事就是分类——事实才能直接用，假设要验证，未知要主动探查。

3 类含义：

事实（Fact）：客户说过的话、有数据支撑的现状、有合同 / 邮件确认的事
假设（Hypothesis）：基于经验的推断，必须在后续工作中验证
未知（Unknown）：还不清楚的，要么承认就反问，要么承认不知道

反例： "客户想要 AI 客服" → 这是 1 个需求，但不是事实。客户想要的可能是"减少客服压力"，AI 客服只是你的假设方案之一。

概念 3：怎么写客户能看进去的文档

FDE 写文档的 3 个原则：

少用技术黑话：把"模型推理"换成"AI 算答案"，把"RAG"换成"从文档里找答案"
多列业务影响：每个技术决策都补 1 行"对客户业务的影响"
可视化优先：能用图不用表，能用表不用文字

⚡ 避坑指南：常见错误

错误类型	错误做法	正确做法	为什么
只跟对接人聊	"信息科 X 主任说需求就是这些"	主动见决策人 / 受益者 / 守门人	对接人 ≠ 决策人，信息会被过滤
假设当事实	"客户想要 X"（其实是你的推断）	区分清楚，假设要去证明	假设当事实 = 项目跑偏
业务画像写完不迭代	v0.1 写完就存档	每周一更新，重大变化随时更新	业务画像是活文档，不是写一次就完
Stakeholder Map 漏画守门人	只画支持者	把审批 / 合规的人都标出来	守门人没沟通 = 上线被卡
客户文档"机器味"重	直接复制内部技术文档	用客户语言重写	客户看不懂 = 反馈无效