上一篇把范围拆成了一棵 WBS，拆到最后是一份工作包清单：字段映射表、脚本主体、试跑与修复、正式迁移、客服培训、上线切换……每一块都能估、能派给一个人、能检查。手上终于有了可以开工的活。
接着大多数人会做同一件事：打开 Excel 或甘特图模板，在每一行后面填上开始和结束日期。填完之后表格看起来很完整，颜色一格一格排开，像一份计划。
这篇要说明的是，这个顺序是反的。日期不是排期的起点，是排期的结果。 真正应该先做的两件事是：理清工作包之间谁等谁，把几个必须按时到达的点标成里程碑。把这两件事做完，日期才轮得到算。
一、为什么不能一上来就填日期
日期天然是这份计划里最不稳的信息。它依赖你的估算（估算本来就带误差）、依赖那个人那周有没有别的活、依赖外部供应商会不会延期。三个不确定叠在一起，你在开工第一周填下的“3 月 18 日”，到了第二周就有一半概率要改。
依赖关系要稳得多。它比日期更接近事情本身的性质：“字段映射表没定下来就写不了迁移脚本”，这句话在项目从头到尾都成立，跟具体哪一天无关。所以先固定稳的东西，再让不稳的东西挂上去，整张表才不会每改一次就散架 7。
第二个理由更实际。你单独看一个工作包，给它三周是合理的；九个工作包各自看也都合理；但这九个日期合到一起，可能有两个撞在同一个人身上、可能有一块在等一份还没到的合同。冲突不在单个格子里，只在它们互相之间。 而如果逻辑关系已经先画出来了，谁挡着谁一眼能看见；如果只有一列日期，你只能靠逐个比对去猜。
二、第一步：只问“谁等谁”，不问“几号”
把工作包两两摆在一起，只回答一个问题：B 能不能在 A 做完之前就开始？ 这个问题的答案就是一条依赖（也叫逻辑关系）。称呼上，前面的那块叫紧前活动（predecessor），后面那块叫紧后活动（successor）。
日常最常用的是两种形式。
完成—开始（finish-to-start，FS）：A 做完了 B 才能开始。最典型：“脚本试跑通过，才能做正式迁移”。PMBOK 里说，这是最常见的一种逻辑关系 4。
开始—开始（start-to-start，SS）：A 一开始，B 就可以开始，不必等 A 完工。这个容易被忽略，但很有用。比如“新系统配置”和“客服培训”之间，你其实不需要等全部配置完才做培训——系统能登录了，就能先教基础操作，边配边教。这就是两块活并行搭接。
拿客服系统这个项目，完整过一遍。WBS 里那六块工作包摆出来后，依赖是这样的：
- 字段映射表 → 脚本主体（FS）
- 脚本主体 → 试跑与修复（FS）
- 试跑与修复 → 正式迁移（FS）
- 新系统配置 → 客服培训（SS）
- 正式迁移 → 上线切换（FS）
- 客服培训 → 上线切换（FS）
写成表就是一句话一行。注意这件事有多便宜：不用画漂亮的图，不用软件，列个清单就够了。
然后把关系连起来看：
图一出来，答案就自己浮上来了。这里有两条腿：一条是数据迁移链（映射表 → 脚本 → 试跑 → 正式迁移），一条是配置 → 培训，两条腿最后汇到“上线切换”。迁移链明显更长，它从头到尾卡着上线时间；配置和培训那条腿反而可能有富余。这种判断在只有日期的一列表格里是看不见的。
（最长的那条链有个名字，叫关键路径，它是后面讲“进度失控怎么办”时要专门处理的东西。这里先知道它存在。）
三、分清哪些依赖能动，哪些动不了
依赖不能一律平等看待。排期往后走总会遇到时间不够，那时候你要知道先动哪根。
硬逻辑（mandatory dependency）：由工作本身的性质决定，改不了。“基础没浇完不能搭结构”，或者合同里写死的顺序 4。客服项目里，映射表没定就写不出脚本，这属于硬逻辑。
软逻辑（discretionary dependency）：不是非这样不可，是团队的习惯或最佳实践。比如“需求文档必须评审两轮才能开发”。它可以用，但要写下来是被有意选的——因为它悄悄限制了你后面的排期空间；真要压缩工期时，最容易先动的就是它 5。
外部依赖：等的是项目之外的东西。等供应商交货、等一份盖章的合作函、等对方团队的数据接口。它通常不受你控制，所以不能只是画在链里，得单独列出来盯 4。
四、第二步：把关键节点标成里程碑
依赖画完，你得到的是一张只有先后、没有时间的网络。这时候插进去的第二样东西，是里程碑。
PMI 给里程碑的定义很朴素：项目中的一个重要时点或事件 1。关键在下一句——里程碑的工期是零 3。它不是一项要花三天做的活，而是一个“到了这里就算过去了”的时刻。客服项目里的里程碑可以是：迁移脚本试跑通过、数据正式迁移完成、客服考核合格、上线切换完成。
为什么它必须有零工期？因为它是最干净的状态汇报单位。一个工作包可以说“完成 70%”，一个里程碑没有 70%。对盯着项目的人来说，“数据迁移还差一点”和“数据迁移这个点还没到”，是两件完全不同的事。
这里有个配套做法值得抄：不要只在阶段末尾放一个里程碑，然后在它前面几个月听不到任何消息。PMI 的一篇文章建议，在里程碑之前再加几个短间隔的检查点（原文叫 inch pebbles），定期要求交出一小块可检查的东西；否则一旦大里程碑赶不上，剩下的时间根本不够补救 2。落到你的项目里，就是“正式迁移”之前先有“试跑通过”，而且两者之间隔着两周，不是两个月。
里程碑也不宜多。如果一张排期表上二十个里程碑，那说明你把很多普通完成点也标成了里程碑，看表的人反而分不出哪个真的要紧。判断标准可以简单一点：这个点是不是外人（老板、客户、隔壁部门）也会关心？ 只对你自己有意义的点，留在工作包层面就够了。
五、日期是什么时候才登场的
现在你有了依赖网络和里程碑，接下来补两样东西：每个工作包大概要多久（工期估算），以及干活的人和设备什么时候有空（资源日历）。把这四样——逻辑关系、工期、资源可用性、日历约束——一起交给排期工具或计算规则，才会得到那张带日期的表 6。
这也解释了一个新手常有的困惑：为什么计划里的日期总在变？因为日期是最下游的东西。依赖改一条，下游所有日期跟着移动；某人请了两周假，日期也跟着移动。 如果一开始就把日期钉死写进表里当成“事实”，后面每改一次都像是在认错，团队就会开始偷偷按自己的日期干。
所以顺序应该是：先有一张只有箭头、没有日期的图（或者一张“谁等谁”的表），把逻辑说对；再标出里程碑，把不可错过的点说清；最后才让日期落到格子里。日期是这一串动作的产物，不是它的开头。
顺带说清楚适用的边界。十几个人的小项目，真没必要画正式的网络图，把前面那种“A → B”的清单一列，加上几个里程碑，就足够支撑排期了。半年以后才做的工作包，依赖也只需要粗粗连一下——近的排细、远的排粗，等它靠近了再补细节，这是常规做法，不算偷懒。
六、几个常见的坑
把所有活串成一条线。 “工作包 1 做完做 2，2 做完做 3……”排出来的工期会明显长于实际需要。别忘了问一句：这块真的必须等上一块做完吗，还是只要它开始就行？前面那个“配置”和“培训”就是靠这个问题省下时间。
把软逻辑当硬逻辑。 “按我们的惯例要先出方案再开发”——这是可以商量的，但只有写下来才谈得动。凡是自己定的顺序，都标一下它的性质。
漏掉外部依赖。 供应商、审批、别人团队的成果，这些不在你的工作包清单里，却实实在在卡着你的链条。它们必须在图上占一个位置，并且单独有个人盯着。
把里程碑写成日期。 “3 月 20 日”不是里程碑，“数据迁移在 3 月 20 日完成”才是。里程碑描述的是到达了什么状态，日期只是它当时的计划落点——状态不会因为你改日期就消失。
下次排期，先别打开甘特图。先拿出一张白纸，把工作包写成名词，在它们之间画上箭头，标出那些外人也要关心的时间点。等这张图看得顺了，再去填日期，你会发现要改的地方比过去少得多。