3
条线
8 件事，一共 6.8 小时，横跨 09:00 – 17:00。 把时长加起来除一除，会告诉你 1 条就够 —— 差的这 2 条，不是总量堆出来的，是某一分钟挤出来的。
同时有几件事在跑
09:0011:0013:0015:0017:00
柱子的高度就是那一刻同时在跑的件数。最高的那几段是红的 —— 整张表需要几条线，是由它们决定的，别的时间段一概不参与。
挤在一起的是这几件
10:15 – 10:205 分钟
- 需求评审
- 客户电话
- 面试
一整天里，真正需要 3 条线的时间一共 5 分钟。剩下的时间，第 3 条线是空着的 —— 这就是下面那个占用率为什么低，以及为什么低不代表可以少一条。
动一件，少一条
按「要动多少」排的，不是按哪件看着最该动。 每一个建议都在整张表上重算过 —— 把拥挤搬到别处不算解决。
客户电话现在 10:00
挪到 09:55–10:15（往前
5 分钟），就少 1 条线。
面试现在 10:15
挪到 10:20–11:20（往后
5 分钟），就少 1 条线。
需求评审现在 09:30
挪到 09:15–10:15（往前
15 分钟），就少 1 条线。
排给你看
1
09:00–09:30 站会09:30–10:30 需求评审14:00–15:00 方案讨论
2
10:00–10:20 客户电话11:00–12:00 一对一16:00–17:00 复盘
3
10:15–11:15 面试14:30–15:30 供应商
09:0011:0013:0015:0017:00
这不是唯一的排法，但它用的条数是最少的， 而且不需要试 —— 按开始时间挨个塞进最早空出来的那条，用掉的条数正好等于最挤那一刻的件数。 区间的性质，不是运气。
占用率 28%：3 条线在 09:00 – 17:00 这段时间里， 只有这么点是真在做事的。
它不知道的事
它不知道两件事是不是必须同时发生，也不知道哪件能拆开、 哪件能压缩、哪件其实可以不开。它把每一行都当成不能动的整块 —— 所以它给的是「按你写的这样排，最少要几条」，不是「你应该要几条」。
它也不知道一条线是一个人、一间屋子还是一台机器。 如果那条线是人，还有午饭、通勤和上厕所，那都不在这张表里。
贴进来的东西只在这一次请求里存在，不写盘、不记日志、不发给任何人。 这个页面没有任何 JavaScript —— 你把脚本全关掉，它照样是这个样子。