任务依赖管理

去年第三季度，我参与了一家约 300 人规模的智能硬件研发团队的效能复盘。他们的项目经理给我看了一份延期报告：一个原计划 6 周交付的固件版本，最终用了 9 周，其中真正&quot…

我统计过自己带过的六个研发团队、累计四十多个迭代的任务依赖数据，发现一个反直觉的现象：FF（完成-完成）依赖的数量和迭代延期率之间，并不是简单的正相关，而是呈现"倒U型&…

很多研发团队对"延期"的解释都是同一句话：需求变更多。但我复盘过十几个中大型研发团队的迭代数据后，发现一个反常识的结论，真正拖垮交付节奏的，往往不是需求变更本身…

我在一次季度复盘会上，看到一个 47 人的研发团队把项目延期 6 周的原因归结为"人不够"。但当我把 Sprint 看板上所有任务的依赖关系重新画到一张图上时，…

去年十月底，我帮一家 200 人规模的 SaaS 公司做发布流程复盘，看到了一个非常典型的排期事故。前端团队在周五下午完成了"联调"，负责人按时关闭了任务卡片；…

2023 年第四季度，我带的一个 62 人研发团队做了一次彻底复盘：把过去 6 个迭代里的 387 个研发任务全部拉出来，逐个标注“是否曾经被前置任务卡住”。结果是 41.3% 的…

去年下半年，我帮一家 120 人的 SaaS 公司做季度研发复盘。他们那三个月里有 37 个任务被标记过「阻塞」，我把每一条阻塞记录的根因重新梳理了一遍，发现其中 29 个都指向同…

去年第三季度，我参与过一次迭代延期复盘。那个迭代原定两周交付，最后拖了五天。复盘会上，前端说后端接口没按期联调，后端说数据表的字段定义等风控团队确认等了三天，风控说他们压根不知道这…

上个月我陪一个 60 多人的研发团队做迭代复盘，他们把过去三个迭代的延期记录全部拉了出来。14 次延期里，有 9 次的直接原因不是工作量估错，而是有人在迭代第三天发现：自己要做的东…

去年下半年，我参与了一家 300 人规模公司的研发流程诊断。他们的迭代准时率长期停在 61% 左右，管理层最初判断是估时不准，要求团队"提高估算能力"。我把近三…