项目管理

2023 年 11 月到 2024 年 3 月，我参与了一家 180 人规模企业研发团队的效能改造。改造前，他们的看板非常"好看"：每个人名下都挂着 3 到 5…

去年我帮一家 130 人的研发中心做交付复盘，翻完 3400 条任务记录后发现：真正拖慢交付的不是写代码慢，而是任务从创建到有人认领平均要等 41 小时，其中 37% 的任务超过 …

去年我帮一家做工业 SaaS 的研发团队做流程复盘时，发现一个很反常识的数字：在他们 3 个月、1200 条需求工作项的样本里，真正造成延期的主因不是"开发做得慢&quo…

去年第三季度，我帮一家做工业物联网的研发团队做交付复盘时，发现一个被所有人忽略的问题：当季度延期交付的 14 个任务里，有 9 个的延期根因不是技术难，而是"任务负责人中…

去年第四季度，我帮一家约180人的企业服务公司做研发效能复盘。三个迭代里，有27个任务在两个迭代之间"原地打转"，既没被关闭，也没被推进。我原以为是执行层懈怠，…

很多研发管理者把“任务分派”当成一句话的事：把需求拆成任务、在群里@一个人、写个截止日期，然后等结果。但我们复盘过一批研发团队的迭代数据后发现一个反常识的现象，任务被“指派”得越快…

去年我带着一个38人的研发团队做季度复盘，拉出当季被判定为“返工”的127个任务单，逐条归因之后发现一个很刺眼的结果：其中67%的返工跟技术难度无关，而是派发时没有说清楚“做成什么…

我帮一个 200 人规模的研发团队做效能复盘时，碰到过一个反常识的现象：他们连续三个迭代的需求交付周期缩短了 18%，线上缺陷密度却同期涨了 12%。按常规思路先查测试覆盖率、发布…

2023 年下半年，我接手一个 120 人研发组织的交付效能治理，第一件事就是重做迭代规划会上的批量分配。新规则第一次上线后，分派动作本身从 3.2 小时压缩到 25 分钟，团队当…

我带过一个约 140 人的研发组织，做过一次当时觉得很反常识的统计：把任务分派的平均耗时从 4.2 小时压缩到 40 分钟之后，需求端的交付周期只缩短了 3%。真正把周期砍掉 37…