# 排期不是往甘特图里填日期：先理依赖，再标里程碑

为什么排期要从“谁等谁”和关键时点开始，日期只能最后算出来

> 进度与排期 · 任务拆解 · 约 8 分钟 · 10 月 02 日

## 本篇要点

1. 排期的起点是依赖关系，不是日期；日期是依赖、工期、资源可用性和日历约束一起算出来的产物，处在最下游，因此也最容易变。
2. 依赖比日期稳定，先固定“谁等谁”再挂日期，计划才不会被每次变动打散；而且冲突只出现在工作包之间，只有先画出关系才看得见。
3. 最常用的逻辑关系是完成—开始（FS，前一项做完后一项才能开始）；开始—开始（SS）表达并行搭接，用来避免把本来可以同时推进的活排成串行。
4. 依赖要区分硬逻辑（工作性质或合同决定，动不了）、软逻辑（团队惯例，可改，是压缩工期时最先动的地方）和外部依赖（不受团队控制，需单独盯）。
5. 里程碑是项目中的重要时点或事件，工期为零，它不是任务，不能用百分比描述，因此是最干净的状态汇报单位。
6. 里程碑之前要加短间隔检查点，避免几个月的沉默后才发现大节点赶不上；里程碑数量要少，标准是外人是否也关心这个点。
7. 把逻辑关系、工期估算、资源可用性和日历约束一起算，才得到带日期的进度表；口径调细了，为后面判断关键路径和进度失控做好准备。
8. 小项目不必画正式网络图，列一张“谁等谁”的清单加几个里程碑就够；远期工作包只粗连依赖，靠近了再补细节。

---

上一篇把范围拆成了一棵 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）

写成表就是一句话一行。注意这件事有多便宜：不用画漂亮的图，不用软件，列个清单就够了。

然后把关系连起来看：

```mermaid
flowchart LR
  A["字段映射表"] --> B["脚本主体"] --> C["试跑与修复"] --> D["正式迁移"]
  E["新系统配置"] --> F["客服培训"]
  D --> G["上线切换"]
  F --> G
```

图一出来，答案就自己浮上来了。这里有两条腿：一条是数据迁移链（映射表 → 脚本 → 试跑 → 正式迁移），一条是配置 → 培训，两条腿最后汇到“上线切换”。迁移链明显更长，它从头到尾卡着上线时间；配置和培训那条腿反而可能有富余。这种判断在只有日期的一列表格里是看不见的。

（最长的那条链有个名字，叫关键路径，它是后面讲“进度失控怎么办”时要专门处理的东西。这里先知道它存在。）

## 三、分清哪些依赖能动，哪些动不了

依赖不能一律平等看待。排期往后走总会遇到时间不够，那时候你要知道先动哪根。

**硬逻辑（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 日完成”才是。里程碑描述的是到达了什么状态，日期只是它当时的计划落点——状态不会因为你改日期就消失。

下次排期，先别打开甘特图。先拿出一张白纸，把工作包写成名词，在它们之间画上箭头，标出那些外人也要关心的时间点。等这张图看得顺了，再去填日期，你会发现要改的地方比过去少得多。

## 术语表

- 依赖（逻辑关系）：两个工作包之间“谁等谁”的关系，回答后一项能不能在前一项完成前开始。
- 紧前 / 紧后活动：一对依赖里，前面的叫紧前（predecessor），后面的叫紧后（successor）。
- 完成—开始（FS）：紧前做完，紧后才能开始，最常用的一种关系。
- 开始—开始（SS）：紧前一开始紧后就可以开始，用来让两块活并行搭接、缩短总工期。
- 硬逻辑 / 软逻辑：硬逻辑由工作性质或合同决定改不了；软逻辑是团队自己定的顺序，可以商量，也是压缩工期时最先动的地方。
- 外部依赖：等的是项目之外的东西（供应商、审批、别人团队的成果），不受你控制，需要单独盯。
- 网络图：把工作包用箭头连起来、只表示先后关系的图，不含日期。
- 里程碑：项目中一个重要的时点或事件，工期为零，不是任务，用来对外汇报状态。
- 检查点（inch pebble）：放在里程碑之前的短间隔小节点，用来避免长时间听不到进展。

## 来源

1. [PMI Lexicon of Project Management Terms — milestone 定义为项目中的重要时点或事件](https://www.pmi.org/-/media/pmi/documents/registered/pdf/pmbok-standards/pmi-lexicon-pm-terms.pdf)
2. [PMI: Manage Milestone Managing Deliverables — 里程碑管理、检查点（inch pebbles）与按交付物管进度](https://www.pmi.org/learning/library/manage-milestone-managing-deliverables-10437)
3. [Estimating Activity Durations — 里程碑与活动的区别，里程碑工期为零](https://pressbooks.ulib.csuohio.edu/project-management-navigating-the-complexity/chapter/7-3-estimating-activity-durations/)
4. [PMBOK: Activity Sequencing — PDM 逻辑关系，以及硬逻辑、软逻辑、外部依赖的定义](https://cin.ufpe.br/~if717/Pmbok2000/pmbok_v2/wbs_6.2.html)
5. [PMBOK 6.3 Sequence Activities: Dependency Determination — 哪些依赖可以改、哪些改不了](https://4squareviews.com/2013/03/30/5th-edition-pmbok-guide-chapter-6-dependency-determination-2/)
6. [PMBOK: Schedule Development — 网络图、工期估算、资源需求与日历共同决定活动的起止日期](https://www.cin.ufpe.br/~if717/Pmbok2000/pmbok_v2/wbs_6.4.html)
7. [Steps in Project Scheduling — 排期六步流程的先后顺序](https://www.projectengineer.net/steps-in-project-scheduling/)

---

原文：https://pangzhengboyin.com/articles/dependencies-and-milestones-before-dates-58d44179

> **庞征博引** · 想学的，慢慢都会
>
> 庞征博引是把想学的东西写成连载的 AI 学习工具。说出想学什么，它会先了解你的基础，再把主题写成一篇篇 5–10 分钟能读完的文章；边读边问，接下来学什么跟着你走。这篇就是这样写出来的。
>
> 开始你自己的连载 → https://pangzhengboyin.com