FDE 的交付节奏：为什么是 4 到 8 周

传统咨询项目，从启动到交付通常三到六个月。

FDE 的节奏不一样：第一版可用的东西，4 到 8 周就要出来。

这不是为了追求速度，是为了让判断发生在成本最低的时候。

一、为什么是 4 到 8 周

这个区间不是拍的，是两个约束的交集。

**下限来自业务复杂度。** 少于 4 周，通常连业务逻辑都还没摸清，做出来的东西没有验证价值。

**上限来自注意力。** 超过 8 周，业务方的注意力会转移，项目变成"IT 部门的事"，需求开始漂移。

4 到 8 周正好是：能做出一个真实可用的版本，且业务方还保持着参与度。

二、第一版要交付什么

不是演示，不是原型，是能跑的东西。

判断标准有三条：

• **用真实数据。** 演示数据跑通不算，真实数据跑通才算。
• **有人真的用。** 哪怕只有三五个用户，要在真实工作里用。
• **能看出效果。** 快了多少、准了多少、少了几个环节，要能量出来。

做不到这三条，第一版就没有意义。

三、节奏怎么排

**第 1 周：进现场。** 和业务人员坐在一起，看他们怎么干活。这一周不写代码。

**第 2 到 3 周：做最小闭环。** 从一个环节切入，做通端到端，不求覆盖面。

**第 4 周：真实数据验证。** 用客户真实数据跑，记录问题。

**第 5 到 8 周：迭代与判断。** 修问题、扩范围，同时回答一个问题：值不值得规模化。

第 8 周结束时，要做一个明确的决定：扩、改，还是停。

**"停"也是合法结论。** 花 8 周发现某条路不通，比花 8 个月做出来没人用便宜得多。

四、和传统项目的区别

传统项目的判断点在评审会：方案讲一遍，大家点头，然后开发。

FDE 的判断点在真实使用：东西跑起来，用户用不用，一眼就能看出来。

前者验证的是逻辑，后者验证的是价值。逻辑自洽但没人用的东西，在传统项目里能活到上线；在 FDE 里活不过第 4 周。

五、什么时候不适合

两类情况不适合用 FDE 的节奏。

**第一，需求已经非常明确。** 标准化的系统实施，按项目计划推进更高效。

**第二，组织不允许快速试错。** 如果每次上线都要走三个月的审批，4 到 8 周的节奏无从谈起。

一个判断

AI 项目的最大浪费，不是做错了，是做对了但没人用。

4 到 8 周的节奏，本质是把"有没有人用"这个问题，提前到成本还很低的时候回答。

---

*本文观点来自开锐·锐智（iKRC）在 FDE 交付方法上的实践。*