FDE 怎么做项目推进：把模糊需求跑成可验收的成果
前面两篇讲的是「对外」：怎么和甲方对齐，怎么在老板和意外之间活下来。
这一篇讲「对内」：需求对齐了之后，怎么把它跑成一个可验收的成果。
很多人以为项目推进靠的是项目管理工具——甘特图、看板、里程碑。我们在 FDE 项目里的体会是：那些工具都没用，有用的是三个纪律。
为什么工具没用？因为 FDE 项目的需求是流动的，计划永远赶不上变化。你画一张两星期的甘特图，第三天客户就改需求了。在不确定的环境里，能管住的只有「今天」。
三个纪律分别是：每天的计划、模块的拆解、Git 的提交。一个管节奏，一个管验收，一个管回溯。
一、每天的计划：今天做哪个模块，就必须做哪个模块
我们的规矩是：项目进度一定要写出来，写到「每天做什么」这个粒度。
不是「本周完成数据模块」，是「今天完成数据获取模块的 XX 接口，明天完成采购计划表的字段渲染」。每天开工前，今天的任务是确定的；每天收工前，今天的任务是完成了的。
为什么要这么细？因为 FDE 项目的周期通常很短，按周排计划等于没有计划——等你发现这周跑偏了，一周已经过去了。按天排，跑偏最多跑偏一天。
当天必须出实物，哪怕丑
计划里最关键的一条：今天做哪个模块，今天就要看到这个东西，即使是丑陋的，也要在当天把它做出来。
「丑陋但完成」和「完美但没做完」之间，永远选前者。因为：
- 丑陋的东西可以改，没做完的东西什么都没法改
- 当天出实物，第二天的计划才有着落
- 做出来的东西立刻打上版本号，后面方便回溯——客户说「我觉得上周那版更好」的时候，你能直接切回去，而不是靠记忆
实物是对齐的前提
这条和上一篇讲的「高频对齐」是连着的：跟甲方交流，手里必须有实物。
我们踩过这个坑：今天没做完，第二天空口跟客户讲「我们打算这样做」。客户的反应是什么？他什么都说对。「对对对，就按你说的做」——因为你没有东西给他看，他无从反对。
等到东西真做出来，他一看：「这不是我要的。」
空口对齐的对齐率接近于零。你手里有东西，客户才能想起来自己真正要什么；你手里没东西，客户只是在礼貌。 所以每天的计划不是内部管理动作，是对外沟通的前提——今天的实物，就是明天对齐的弹药。
二、模块的拆解：每个模块都要有入口和出口
需求了解清楚之后，第一件事不是写代码，是拆。
把需求拆成几个模块，每个模块单独做、单独验收。关键标准是：每个模块都要能独立回答「跑没跑通」——它有明确的入口，也有明确的出口。
什么叫入口和出口？
- 数据获取模块：入口是数据源，出口是「我能不能明确看到这个模块的产出」——拉回来的数据长什么样、字段对不对、量够不够，一眼能检查
- 采购计划表模块：入口是整理好的数据，出口是采购计划表本身——这个模块做完，我必须能看到那张表，而不是看到一堆「逻辑已经写好了」
反面的做法是一开始就混为一谈、怼在一起：数据获取、清洗、计算、展示全写在一个流程里。跑不通的时候，你根本不知道断在哪一环；客户问「采购计划表什么时候能看」，你只能回答「快了」。
拆开之后，一切都不一样了：
- 每个模块的进度是可验收的，不是「我感觉差不多了」
- 出了问题能定位到具体模块，不用全链路排查
- 给客户演示的时候可以一个模块一个模块地过，每个模块都有看得见的东西
「快做完了」是最危险的进度汇报。 拆出入口和出口，进度就只剩两种状态：跑通了，或者没跑通。
三、Git 的纪律：分支做事，主干存档
第三条纪律是关于 Git 的。先说清楚一个前提：FDE 项目里，主干历史后面是要用来回溯、用来改东西的。 客户说「回到周三那版」、团队问「这个改动是什么时候引入的」，都依赖主干的历史是干净的。
但写代码不可能不试错。怎么办？靠分支把「做事」和「存档」分开：
- 做新功能就开新分支。一个模块、一个功能点，一条分支。试错、调参、推翻重来，全都发生在这条分支上——分支上的历史乱一点没关系，它是草稿纸。
- 验收通过才合并，合并要规范。模块跑通了、能演示了，才把分支合进主干。合并时把零散的试错提交整理成一条清晰的记录，写清楚这个版本「是什么、能干什么」。
- 主干只留里程碑。主干上的每一个节点，都应该是「如果明天项目出问题，我可以回到这里」的点。
反面的做法是直接在主干上边做边提交：「试一下这个参数」「回滚刚才的改动」「再试一次」——历史被噪音淹没，想找一个「能跑的版本」要在几十个提交里翻，这条历史就废了。
一句话：分支是草稿纸，主干是档案。 草稿可以乱，档案必须每一笔都有意义。
写在最后
三个纪律其实是同一件事的三面：
- 每天的计划保证每天都有实物
- 模块的拆解保证实物是可验收的
- Git 的纪律保证实物是可回溯的
项目推进的本质，就是把「一个模糊的大需求」变成「一串确定的小成果」。每天一个实物，每个实物可验收，每个验收可回溯——做到这三条，项目再乱也乱不到哪去。