依赖等待

很多项目成员直到项目复盘时才发现，自己真正的加班大头不是写代码、画图或写文档，而是"等"，等上游交付、等接口联调、等评审排期、等一个迟迟不回复的确认消息。我在过…

我带过一个横跨算法、前端、后端、测试、运维五个部门、峰值 37 人的项目。上线前第六周，进度表上 68 个任务里有 41 个显示「进行中」，但真正当天有代码提交、文档更新或环境变更…

我见过最典型的一次进度失控，发生在一次两周迭代的最后三天：看板上 78 个任务只有 6 个还是"进行中"，燃尽图几乎贴着理想线走，项目周报写着"进度正…

先给结论：依赖管理的对象是"等待"，不是"任务" 如果你只记住这篇文章的一个判断，我希望是这一条：依赖管理管的不是任务本身，而是任务之间那段…

去年年底我参与复盘一个跨部门版本交付：计划工期 14 个工作日，实际用了 33 个。团队没有一个人摸鱼，日报天天更新，甘特图每周同步，可工期还是翻了一倍多。我把 33 天逐条拆开算…

带过 30 人以上研发团队的人，大概都经历过同一个场景：迭代计划会上，开发看着需求说“这个 5 天能做完”，你把它填进计划表，5 天后打开看板，进度条停在 40%，剩下 60% 卡…

我做跨部门项目执行大约第八年的时候，才真正想明白一件事：跨部门协作里最贵的成本不是沟通，是等待。我们曾经统计过一个两百多人规模的公司里六个跨部门项目的全量任务数据，发现任务从被创建…

一个 60 人的研发团队，一个版本周期能产生 400 到 800 条任务，但真正被负责人在当天主动更新过状态的，往往不到六成。我在过去三年里跟进过十几个这样的团队，最常被问到的不是…