依赖登记

去年 Q3，我参与过一家 380 人研发组织的季度复盘。会上摆着一份数据：14 次迭代延期，其中 9 次的原因链条最后都指向同一件事，不是人不够，不是需求乱，而是某个后置任务的依赖…

去年秋天，我陪一个 22 人的研发团队做了一次发布复盘。三周的发布窗口，到第 19 天才发现：三个小组之间一共存在 17 条跨组依赖，其中 11 条是 FF（Finish-to-F…

先给一个不太好听但真实的数字：过去三年我深度参与过 11 家中大型企业的 SS 落地辅导，其中 8 家在启动后 6 个月内出现了不同程度的"会议照开、依赖照堵"…

去年第四季度，我把一个延期了47天才交付的项目拉出来做全量复盘，本以为罪魁祸首是需求变更或者人力不足，结果把任务网络图铺开一看，真正的元凶是三条没登记的FS依赖：前端联调必须等接口…

去年第四季度，我参与了一家约 300 人规模研发组织的迭代复盘。他们把当季 23 个延期需求逐一归因，结果有点反常识：只有 4 个是技术难题或人力缺口导致的，剩下 19 个都指向同…

2023 年秋天，我参与复盘一个延期了 23 天才上线的版本。表面结论是"后端接口没按时交付"，但把时间线拉出来之后，真正的问题出在第 4 天：前端负责人在排期…

去年我参与过一个整车研发项目的依赖审计。项目计划里一共 1847 条任务，被明确登记了跨团队依赖关系的只有 63 条，占 3.4%；而在项目延期复盘的根因清单里，71% 的问题最终…

2023年下半年，我帮一家做智能硬件的公司做项目复盘。项目原计划12周交付，实际用了14周零3天。多出来的两周几乎全部来自同一个动作的缺失：结构件的三维数模冻结任务，与模流分析任务…

去年十月，我参与复盘了一个延期 23 天交付的中台版本。项目组的结论在复盘会开始前就已经写好，“需求变更太多”。但我把 47 个延期工作项逐个拆开对时间线后发现，真正由需求本身变化…

2023 年下半年，我参与过一次挺难看的迭代复盘：一个 130 人的研发组织，双周迭代里产品经理一共分派了 47 个任务，迭代结束时有 12 个任务被验收打回，3 个任务从头到尾没…