任务分派

去年第四季度，我帮一家 380 人规模的智能硬件公司做研发效能诊断。他们的研发 VP 给我看了一组数据：迭代周期平均 23 天，其中真正在写代码的时间只有 9 天，剩下 14 天里…

我见过最贵的一次任务分派，是在一个 140 人的研发组织里：一个支付网关灰度联调任务挂了 1 个主办、4 个协办，结果四个人都在等对方先给环境，直到版本冻结前 6 小时才有人发现这…

2023 年 9 月，我负责的一个 12 人交付项目在第 6 个迭代翻车了。需求评审时所有人都点头说没问题，交付当天却冒出 4 个工作项无人认领、2 个做反了方向、1 个卡在等接口…

去年底我帮一家 140 人的硬件研发团队做研发管理流程复盘，他们在一次版本冲刺里干了件很典型的事：版本经理在项目管理平台里一口气把 63 个任务批量分配给 9 个人，操作只花了 4…

我把过去两年经手的 1200 多条任务分派记录重新扒了一遍，得到一个不太舒服的结论：真正因为“没人接”而烂尾的任务，只占 6.8%。剩下九成多的问题，全都发生在任务被答应下来的那一…

去年我复盘过一个延期 23 天的交付项目，根因不是技术方案反复，也不是人力不足，而是一次只用两句话完成的任务转交。原负责人把一件"把老系统用户表迁到新库"的工作…

迭代第三天，我在一个 40 人的研发团队做交付复盘时，听到同一句话被三个人重复："我以为这个任务是小李在做。"任务卡上挂着三个人的评论，却没有一个人点&quot…

2023 年我参与复盘一个 130 人规模的研发组织时，碰到一组很难解释的数据：那个季度被判定为"严重延期"的 17 个需求里，有 14 个的"责任人…

一个 60 人的研发团队做季度复盘时，把本季度所有延期任务翻出来重新归因，结果发现：61% 的延期原因被标记为“等待确认”“信息不足”“不知道找谁”，而不是“技术难”或“人手不够”…

去年复盘一个 180 人研发组织时，我碰到一个反常识的数据：任务认领机制上线后的第一个季度，需求平均交付周期从 9.4 天降到 7.1 天，但线上缺陷数同期上升了 38%。团队负责…