方法论

我们做项目只用一套方法：五步法。每一步都有明确的产出物和完成标准，不完成不进入下一步。

这套方法不是为了显得专业，是为了解决一个具体问题：大部分失败的项目，问题不在做不出来，而在做了一件不该做的事，或者做出来了没人用。

全景

① Discovery · 诊断

核心问题：这件事值不值得做？

做什么：

• 90 分钟诊断会，问 5 个问题（现在谁在做、一天花多少时间、做错了会怎样、有没有现成系统能改、谁拍板预算从哪出、上线后谁维护）
• 看现有流程文档与数据样本
• 判断技术可行性与投入产出比

产出物：一页《场景清单与可行性判断》，包含：

• 问题描述（具体到人和动作）
• 现在的做法与成本
• 建议方案（可能不止一个）
• 粗略投入与周期
• 结论：建议做 / 不建议做 / 建议换方案

怎么算完成：客户拿到这一页，能独立判断"要不要往下走"。

⚠️ 我们会在这一步直接结束并说明原因的情况：

• 规则能解决，不需要 AI → 给规则方案，不收费
• 数据基础不具备 → 说明缺什么，不收费
• 需求还在变、决策人不在场 → 建议等条件成熟
• 只想做演示 → 直接说明不接

这一步免费。 它既是判断，也是筛选：用它换真实需求，也筛掉不合适的客户。

② Frame · 定界

核心问题：做到什么程度算成功？

做什么：

• 划定范围：做什么、明确不做什么
• 定义验收标准：功能标准 + 采用标准 + 交接标准
• 确认客户侧投入：谁对接、谁参与验收、决策人什么时候到位
• 确认数据与权限边界
• 排期与付款节点

产出物：《范围与验收文档》，客户签字确认。

怎么算完成：双方对"什么算做完了"有一致理解，且写下来了。

这一步最容易出问题，因为客户往往觉得"这还要谈？"——但范围不清是 B 端项目最大的纠纷来源。我们会坚持把"不做什么"写进文档。

③ Build · 交付

核心问题：怎么把它做出来？

做什么：

• 写生产代码（不是 demo、不是原型）
• 小步上线：先跑通一条完整链路，再扩展
• 每周同步进展，不搞"憋大招"
• 遇到需求变更，走变更流程，不免费扩范围

产出物：可运行的生产系统 + 技术文档 + 操作手册。

怎么算完成：约定范围内的功能全部跑通，且在测试环境通过验收测试。

原则：

• 能跑通一条链路，胜过做了一半的三条链路
• 能用规则解决的，不用 AI
• 代码要能被人读懂——因为最终要交给客户的人

④ Adopt · 采用

核心问题：有人真的在用吗？

做什么：

• 上线后盯使用数据：谁在用、用了多少次、哪些功能没人碰
• 收集真实反馈，快速迭代
• 培训与答疑（不只是教怎么点，要教为什么这么设计）
• 处理"上线抵触"——通常来自流程变化带来的不适

产出物：使用数据报告 + 优化记录。

怎么算完成：约定的采用率指标达标（例如：X 名业务人员连续使用 N 天，核心功能日活达到 Y）。

这一步是 FDE 与传统实施最大的区别。 传统实施在"上线"就结束了，验收单签完就走。我们必须在"上线"之后继续盯，直到业务人员真的在用。

如果采用率上不去怎么办：

• 先查是不是设计问题（操作太麻烦、流程不合理）→ 改
• 再查是不是培训问题（不会用、不知道怎么用）→ 补培训
• 最后查是不是意愿问题（觉得是来监视自己的、觉得增加了工作量）→ 需要客户管理层介入

采用率上不去，我们不走。

⑤ Transfer · 交接

核心问题：我们走了，你能接住吗？

做什么：

• 移交源码与完整技术文档
• 培训客户团队（2–4 场）：部署、运维、改需求
• 移交运维手册（含常见故障处理）
• 权限回收与数据销毁确认
• 3 个月答疑期

产出物：交接四项指标全部达标 + 结项确认书。

交接四项指标：

最后一项是这套方法的核心指标：它检验的不是单个项目做得好不好，而是有没有形成能力杠杆。

如果第二个项目还是从头再来、还是需要同样多的人，那说明我们只是外包，不是 FDE。

为什么是这五步

它解决了三个具体问题

它和同行的三段式有什么区别

国内同行普遍是"诊断/POC → 共建实施 → 陪跑运营"三段式。

我们多了两步：Frame 定界（把"不做什么"写下来）和 Adopt 采用（把"用起来"作为独立的验收环节）。

这两步是最容易省略、也最容易出事的两步。

五步法不适用的场景

方法是为解决问题服务的，不是反过来。