一、三个人，三种关心的东西

数据业务员关心「这个数能不能帮我做决定」。他说的话是需求，不是技术。 科学分析师关心「准不准、为什么准」。他交付的是模型和一段解释。 工程技术员关心「稳不稳、多久出数」。他交付的是一条每天自动跑的管道。

三个人的语言不一样，这是常态，不是问题。问题出在没人做翻译。 现实里最常见的失败不是技术不行，是三边各说各话：业务要「用户活跃度」，分析理解成「日活」， 工程按「登录次数」算——数字出来对不上，谁也不认账。 所以口径要先写下来，再动手。这一条比任何工具都重要。

二、把需求拆成任务链，就能算出工期

演示里把一个需求拆成六步：提需求、理解数据、准备数据、建模验证、工程化、上线试运行。 这几步有先后依赖：数据没准备好就没法建模，模型没验证就没法工程化。 这种「必须按顺序走的最长链」叫关键路径，它决定总工期。 演示算出来是 38 天。并且验证了一件事：关键路径上任何一段缩短几天，总工期就缩短几天，一比一。

工程化从 14 天压到 10 天，总工期 34 天；压到 7 天，31 天；压到 4 天，28 天。 没有加速比，没有拐点，就是直接减。 这就是为什么「砍工期」这件事在关键路径上特别有效， 也特别危险——你砍掉的每一天，都是实打实从质量里扣出来的。

三、工程占了七成，而且不是重复劳动

按角色归一下：业务 2 天占 5.3%，分析 9 天占 23.7%，工程 27 天占 71.1%。 很多人看到这个比例的第一反应是「工程效率太低」。但拆开看，工程那 27 天里没有一天是白费的。 准备数据 10 天：要对接三个源系统、处理字段不一致、补缺失值、还要和历史口径对齐。 这一段在实验里往往被一句「用样本数据」跳过了。

工程化 14 天：把 notebook 里的代码变成能定时跑的服务，加监控、加告警、加失败重试、加权限控制。 这些在实验里全都不存在。 上线试运行 3 天：真数据跑起来才会暴露的问题——空值、超时、并发、下游系统不认这个格式。 所以教材 1.6 那个问题的答案是： 实验验证的是「方法可行」，工程要交付的是「每天可行」。这两件事的工作量差一个量级，很正常。

四、想快，只能并行，不能硬砍

关键路径是一条链，链上没得并行。想让总工期短，只有两条路。 第一条是把链外的活提前做：数据准备如果在上一个项目里就完成了，这次就能省 10 天。 这就是「数据中台」这类东西的真实价值——不是技术先进，是复用。 第二条是把链上的活拆开并行：建模和工程化如果有一半能同时做（比如工程师先用假数据把管道搭好）， 就能重叠几天。

两条路都要求同一件事：接口先定。 数据长什么样、模型输出什么格式，先说清楚，两边才能同时动。 这也是这一篇最实用的一句话：工期不是砍出来的，是拆出来的。

五、动手 Demo：算一遍关键路径，看谁占的时间最多

把需求拆成六个有依赖的任务，用拓扑排序算最早开始与最早完成。 找出总工期，再按角色归一次账。 最后试三种「砍工程化」的方案，看总工期怎么变。

tasks = [
    ('提需求',     2, []),
    ('理解数据',   3, ['提需求']),
    ('准备数据',  10, ['理解数据']),
    ('建模验证',   6, ['准备数据']),
    ('工程化',    14, ['建模验证']),
    ('上线试运行', 3, ['工程化']),
]

dur = {t[0]: t[1] for t in tasks}
dep = {t[0]: t[2] for t in tasks}

es, ef, order, seen = {}, {}, [], set()
def visit(n):
    if n in seen:
        return
    for x in dep[n]:
        visit(x)
    seen.add(n)
    order.append(n)

for t in tasks:
    visit(t[0])

for n in order:
    es[n] = max([ef[x] for x in dep[n]] or [0])
    ef[n] = es[n] + dur[n]

print('总工期', max(ef.values()), '天')

实跑输出：

--------------------------------------------------------------------
三个角色：谁负责哪一段
--------------------------------------------------------------------

  ① 教材里的三个角色
  --------------------------------------------------------------------

| 角色 | 管什么 | 关心的数字 |
|---|---|---|
| 数据业务员 | 提问题、定指标、验收 | 这个数能不能帮我做决定 |
| 科学分析师 | 建模、验证、解释 | 准不准、为什么准 |
| 工程技术员 | 取数、搭管道、上线运维 | 稳不稳、多久出数 |

  三个人缺一个都不成：业务不知道能问什么，分析不知道怎么取数，工程不知道取来干什么。

  ② 一个需求从提出到上线，卡在哪一段
  --------------------------------------------------------------------

| 任务 | 天数 | 最早开始 | 最早完成 |
|---|---:|---:|---:|
| 提需求 | 2 | 0 | 2 |
| 理解数据 | 3 | 2 | 5 |
| 准备数据 | 10 | 5 | 15 |
| 建模验证 | 6 | 15 | 21 |
| 工程化 | 14 | 21 | 35 |
| 上线试运行 | 3 | 35 | 38 |

  全部做完要 38 天。
  这几步是一条直线，没有并行的余地：数据没准备好就没法建模，模型没验证就没法工程化。
  这种「一条最长链」叫关键路径，它决定了总工期。
  天数是我按常见项目节奏写的示例，不是测出来的；关键路径的算法是真跑出来的。

  ③ 三个人各占多少天
  --------------------------------------------------------------------

| 角色 | 负责的活 | 天数 | 占总工期 |
|---|---|---:|---:|
| 业务 | 提需求 | 2 天 | 5.3% |
| 分析 | 理解数据、建模验证 | 9 天 | 23.7% |
| 工程 | 准备数据、工程化、上线试运行 | 27 天 | 71.1% |

  工程那段加起来 27 天，是整个项目的大头。
  这就是教材 1.6 节那个问题的答案：为什么验证实验做完了，系统还是上不了线。
  实验只要跑通一次；系统要每天跑通，还得在数据变多、格式变乱、人换了几茬之后照样跑通。
  这两件事的工作量差着一个量级。

  ④ 只优化工程化那一段会怎样
  --------------------------------------------------------------------
  工程化 10 天 -> 总工期 34 天（省 4 天）
  工程化  7 天 -> 总工期 31 天（省 7 天）
  工程化  4 天 -> 总工期 28 天（省 10 天）
  关键路径上的每一段都按 1:1 折进总工期。
  想再快，只能让「准备数据」和「建模」并行——可那要求数据早就备好了。

这段代码做的是「关键路径法」（CPM）的最简版：先拓扑排序保证依赖在前，再一路推最早开始时间。 任何项目管理软件的核心都是这几十行。 max([ef[x] for x in dep[n]] or [0]) 里的 or [0] 是给没有前置依赖的任务兜底——空列表取 max 会报错。 天数是我按常见项目节奏写的示例，不是测出来的。但拓扑排序、最长路径、1:1 折算这三件事是真算的。 按角色归账那段（业务 5.3%、分析 23.7%、工程 71.1%）就是把 dur 按人分组求和，没有任何技巧， 但这个比例能改变很多人的直觉。

30 秒实验

1. 把「准备数据」从 10 天改成 3 天（假设有现成的数据中台），重跑，看总工期变多少。
2. 加一个任务「写文档，4 天，依赖建模验证」，看它会不会改变总工期。（不会——它不在关键路径上。）
3. 把「建模验证」和「工程化」改成能部分并行，试试总工期能压到多少。

常见误区

1. 「工程就是搬砖，没什么技术含量。 」把一次性脚本变成每天跑、坏了能自己恢复、出问题能定位的服务，是另一个专业，不是搬砖。
2. 「实验跑通了，系统就差不多了。」实验验证方法，系统验证持续。 中间那 14 天的工程化不是可选项。
3. 「关键路径上的任务都能砍。」能砍，但砍的是质量。要在不砍质量的前提下缩短，只能提前准备或并行。

下一篇进第 2 章：把这三段摊开看，每一段的输入输出到底是什么。

• ☐ （本篇完，下一篇 2.1 收集、积累、活用）

相关笔记

• 数据为什么突然变多
• 大数据系统的三段路
• 图解机器学习算法 · 索引
• 📊 图解大数据分析 · 索引