软技能系列最后一章。排期这件事，技术人普遍两极化：要么拍脑袋报「两周差不多」，要么被逼着报「一周」然后加班三周。排期烂的代价不只是延期——是团队失去信任：leader 不信你的排期，就会开始压排期；压排期又导致估得更保守，恶性循环。
先讲清楚：排期是「承诺」，不是「期望」
把排期当成承诺，评估方式会完全不同：
- 期望值：理想情况下多久做完 → 乐观估计，不能用来承诺。
- 承诺值：大概率能按期交付的时间 → 排期应该是承诺值。
- 常见翻车：把乐观估计当排期，再用加班补差值——补不上的时候，延期和信任一起崩。
评估的拆解法：别估「整个需求」，估「拆开的任务」
- 先拆任务再估：一个 2 周的「需求」没法估准；拆成 8 个 1–3 天的任务，每个单估，误差会互相抵消一部分。
- 用「历史速度」校准，不用感觉：记录自己过去 3 个月「估 vs 实际」的偏差系数——多数人会系统性低估 1.5–2 倍，知道自己的系数，评估就准了一半。
- 三明治估算：乐观值 + 悲观值取中再往上加一点：
(乐观 + 悲观 + 4×最可能) / 6——逼自己给区间，而不是给一个假装精确的点。
buffer 怎么给（给对了是专业，给错了是注水）
- 给「不确定性」留 buffer，不给「已知工作」注水：新领域、跨团队、依赖他人 → 每项单独加缓冲；熟悉的纯编码 → 按系数即可。
- buffer 藏在任务里，不单独列一行：单独列「预留 2 天缓冲」会被直接砍掉；藏进各任务的评估里，才是真的 buffer。
- 沟通 buffer 的存在：向上汇报时可以讲「这是承诺值，内部包含了对风险的缓冲」——诚实说明，比假装精确后延期强。
五个排期陷阱（对号入座）
- 漏掉「非编码」时间：评审、联调、修 bug、写文档、上线发布——这些常占 30%–40%，却总被排除在估算外。
- 用「别人承诺的时间」当自己的依据：依赖另一个团队时，把他的口头排期原样写进自己的排期——他的延期会传导成你的延期，要留「依赖缓冲」。
- 一个需求估完就不管了：需求中途变大是常态，排期要能「重新对齐」——变更发生时重新排期，而不是闷头扛到延期。
- 把「排期表」当「进度表」：排期更新不及时，表就失去意义。
- 报复性估时：被压过一次排期后，下次估 3 倍——用过度注水报复，比延期还伤协作。
落地清单
- 排期按承诺值报，不按乐观值
- 任务拆到 1–3 天粒度再估
- 记录自己的偏差系数，用历史校准
- 非编码时间算进排期，依赖项留缓冲
- 需求变更时重新对齐排期，不闷头扛
相关：技术沟通与需求博弈 ｜ 技术人如何做技术汇报