项目排期：预估 vs 承诺、buffer 该放多少

一句话速记

排期的核心区分：预估（“我 80% 的信心在这个时间范围内做完”）不是承诺（“我一定在这个时间点交付”）。给老板和合作方的永远用承诺——用预估 × 1.5~2.5 的系数（取决于不确定度），再留 20% 的紧急事件 buffer。排期不是猜一个数字，是把你脑子里对不确定性的认知翻译成一个数字。

通俗解释（5 分钟版）

为什么你的预估总是错的：

你心里想的时间线：
  开发 3 天 → 联调 2 天 → 测试 2 天 → 上线 1 天 = 8 天

实际发生的：
  开发 3 天 + 一个库升级导致兼容问题多花 1 天 = 4 天
  联调 2 天 + 下游团队跳票晚了一天开始 = 3 天
  测试 2 天 + 发现一个边缘 case 多测 1 天 = 3 天
  上线 1 天 + 灰度发现问题要回滚 = 2 天
  = 12 天（是你的预估的 1.5 倍）

这 4 天的额外时间不是意外——它们就是不确定性的实现。
你的预估算法默认了"一切顺利"，但一切从来不会顺利。

关键细节

预估 vs 承诺

预估（estimate）：
  - 你在心里对工作量的判断
  - 用"信心区间"来表述（"我有 80% 把握在 8-12 天内完成"）
  - 可以随着信息增多动态调整
  - 只在内部讨论时用

承诺（commitment）：
  - 你对外的交付时间
  - 用确切日期（"4 月 15 日前上线"）
  - 一旦给出就不能随便改
  - 对外和对上：给承诺不给预估

承诺 = 预估 × 不确定性系数 × 紧急事件 buffer

不确定系数怎么定：

不确定性低（0.8-1.2 倍）：
  - 团队做过类似的事，技术栈成熟
  - 需求冻结，不会变
  - 没有外部依赖
  - 单人就能完成

不确定性中（1.3-1.8 倍）：
  - 做过类似的但有新组件/新接口
  - 需求大体稳定但细节待定
  - 有 1-2 个外部依赖

不确定性高（1.8-2.5 倍）：
  - 没做过，技术选型都没定
  - 需求可能变
  - 依赖多个团队
  - 需要学习和探索

紧急事件 buffer：
  所有承诺之上再留 20% —— 线上故障、紧急需求、人员请假。
  这部分不用精确算，但要留。

实操步骤

第 1 步：拆任务（WBS）

不要估"做一个 XX 系统"——太大。

拆到每个子任务 < 2 天：
  - 用户模块：建表 0.5 天 + CRUD 接口 1 天 + 单元测试 0.5 天
  - 权限模块：设计 0.5 天 + 实现 1.5 天 + 联调 0.5 天
  - ...

拆完后加"胶水时间"：
  - 沟通对齐、写方案文档、review 其他人的 MR、开周会、
    处理线上小问题——这些你的"工作时间"里 20-30% 被它们吃掉

第 2 步：估每个子任务（用三点法）

每个子任务给三个值：
  乐观（最好的情况）：2 天
  最可能（正常情况）：3 天  
  悲观（踩坑的情况）：5 天

预期时间 = (乐观 + 4 × 最可能 + 悲观) / 6
         = (2 + 12 + 5) / 6
         = 3.17 天

这是 PERT（Program Evaluation and Review Technique），
半个世纪前美军造北极星导弹用的，但你估 CRUD 接口一样管用。

第 3 步：加 buffer，转承诺

内部预估：所有子任务加起来 × 胶水系数 = 预估工时
承诺时间：预估工时 × 不确定系数 × 1.2 = 承诺工时

例如：
  子任务加起来 = 20 天 × 0.8（胶水吃掉 20%）= 实际开发 ≈ 25 天
  不确定系数 1.5 → 37.5 天 + 20% buffer → 约 45 天

你给老板/合作方的数字：45 天（约 9 周）
你给自己和团队的数字：25 天开发（约 5 周），有 20 天的 buffer

不要觉得"骗"了老板——那 20 天 buffer 被吃掉的时候，
老板只会感谢你早告诉了他，而不是骂你为什么没兑现

排期的沟通

告诉老板排期时不只说日期：

✗ "4 月 15 日上线。"

✓ "我们计划 4 月 15 日上线。前提条件是：
    ① XX 团队的接口在 3 月 20 日前给到（否则延后 2 周）
    ② 需求不再变更（如果变更需重新评估排期）
    ③ 老王在这期间没有被抽走（如果抽走减人排期不变）"
  → 这不只是"告诉 TA 时间"，是帮 TA 理解边界

被压排期时的应对：

老板："能不能提前两周？"

✗ "不行，做不到。"（对抗式）
✗ "好的。"（不设边界，最后自己背锅）

✓ "如果要去掉两周，我们需要做三件事：
    ① 砍需求：哪些功能可以做 V2？
    ② 加人：如果能调一个人过来可以省 X 天
    ③ 降质量：如果接受 V1 不做灰度不做降级，可以省 Y 天
   
   你看哪个方案更好？"
  → 你给了选择，让老板感受到 trade-off 而不是"你在拒绝"

延伸追问

• Q：如果已经给了承诺但明显完不成了，怎么办？ → 越早说越好。 发现要延期时立刻同步——不要说”我再努力试试能不能赶”。因为你的下游也在依赖你的交付时间，晚一天说 TA 就少一天调整空间。同步时说清楚：为什么延、延多久、后续怎么避免。
• Q：敏捷开发（Scrum）还需要这样排期吗？ → Sprint 内部不需要这么重的排期。但跨 Sprint 的大项目、对外的承诺（比如给客户/给合作方的交付日），仍然需要。敏捷不意味着没有承诺日，只是承诺日的粒度更小、更频繁。
• Q：怎么判断一个人的排期能力好不好？ → 看 TA 的历史偏差率。每次项目记录”预估多少天 → 实际多少天”，算一个偏差率（实际/预估）。好的排在 0.8-1.2 之间（考虑到 buffer，一般偏保守），差的是 2-3 倍。偏差率本身就是你作为 TL 判断 TA 排期能力的数据，也是 TA 自己学习的参照。

我的记法

• 预估 ≠ 承诺：内部用预估（信心区间），对外用承诺（日期）
• 三点估时：(乐观 + 4×最可能 + 悲观) / 6
• 承诺公式：预估 × 不确定系数（1.0-2.5）× 紧急事件 buffer（1.2）
• 被压排期不说”不”，给老板 trade-off：砍需求 / 加人 / 降质量
• 一句话：「排期要的不是准，是偏差在你控制范围内——每次偏差都在缩小」

状态

• 已背速记
• 能讲通俗版
• 能答追问