项目管理

项目规划如何做好计划调整？研发团队最佳实践与操作步骤 我真正意识到"计划调整"是一项独立能力，是在一次季度复盘会上。当时我带的研发组织有 6 个小组、约 130…

2024 年我参与复盘一个原计划 6 周交付的版本，实际用了 9 周零 2 天。翻完工时记录后我发现，纯编码工时只增加了 11%，多出来的时间几乎全花在三件事上：等外部团队交付接口…

去年冬天，我帮一家做 SaaS 的研发团队做交付复盘。40 人的研发中心，三个业务线，全年 27 个版本，最终按期发布的只有 11 个。CTO 一开始的判断是"工具不行、…

我做过一次内部复盘：同一个 18 人研发团队，连续两个季度做版本迭代。第一个季度，实施计划写了 27 页，甘特图精细到半天，结果延期 23 天；第二个季度，计划只保留一页半，但延期…

去年第三季度，我参与复盘过一家 400 人规模研发组织的计划调整记录。变更起因很普通：客户把两个功能的交付顺序对调，影响 3 个研发小组、1 个测试组、1 个运维组。变更评审会开了…

2024年下半年，我帮一家约400人的研发组织做效能诊断，翻出他们某季度的变更记录后发现一个刺眼的数字：这个季度里，进入正式流程的"计划调整"只有11次，但迭代…

我做过一个统计：过去三年里，我参与或旁听过的研发项目复盘中，被归因于"需求变更"和"跨团队依赖"的延期占了全部延期原因的七成以上，而被归因于…

2022 年我参与过一次研发组织的季度复盘，最扎心的数字不是交付速度，而是承诺达成率：季度初 6 个团队集体承诺的 37 个里程碑，按期兑现的只有 19 个，达成率 51%。更讽刺…

2023 年 Q2，我带的一个 32 人研发团队做了一次让我印象很深的季度复盘：季度初规划会上我们信心满满地排了 48 个需求，季度末实际交付 19 个，交付率 39.6%。更扎心…

我见过最典型的一次“计划基线翻车”，发生在一家中型 SaaS 公司的季度规划会上。技术负责人把一张排期表投到屏幕上，说“我们 Q3 交付 6 个模块，10 月 15 日上线”，产品…