批量分配

去年 Q3，我帮一家做工业 SaaS 的公司做研发效能复盘，翻到一条让我印象很深的数据：他们 180 人的研发组织，一个双周迭代里，任务从「创建」到「被责任人确认认领」的中位耗时是…

2019 年我刚接手一条 40 人的产品线时，在一次迭代规划会上，手动在项目管理工具里把 87 条需求逐条拖给 14 个负责人，整整花了 2 小时 47 分钟。散会后核对，发现有 …

批量分配看似只是“把任务一次发给多个人”，我在实际项目里却见过它把一次版本发布拖后三天。问题不在功能本身，而在于产品经理把批量分配当成一个“操作动作”，忽略了它其实是一次“协同契约…

上个月帮一个120人的研发组织做交付复盘，我们在3.2万条历史任务记录里挖出一个反常识的数字：批量分配给一个迭代带来的"分派效率提升"，平均只能维持4天；但从第…

去年 Q4 的一个周二晚上十一点，我盯着迭代看板上 142 条待分配的需求，用批量操作把它们按模块分给了 9 个研发。整个过程 11 分钟，我当时的自我评价是效率很高。三天后测试同…

上周三凌晨一点，我在协作工具里看到一条消息：“迭代里 87 个任务全被分到测试组了，明早九点评审。”发消息的是我们团队的产品经理，起因很简单：他想省事，在列表页全选了几十条工作项，…

上个季度我陪一家 200 人规模的研发组织做迭代复盘，翻出一组挺刺眼的数字：产品经理在每个双周迭代开头，平均要花 2.7 小时把 130 多个任务分派到 6 个研发小组、20 多名…

上周三凌晨一点，我在一个 400 人规模的产品研发群里看到一条消息：一位产品经理说他把 37 个需求分派给 9 个人，花了整整两小时，第二天早上发现有 4 个人收到的任务重复、2 …

我带过的一个 70 人规模研发团队，在迭代复盘时做过一次分派行为统计：一个两周迭代里，产品经理和研发负责人加起来手动指派了 300 多条工作项，其中真正需要"停下来想一想…

2023年我参与一个1200人规模装备制造企业的PMO流程改造，信息部负责人给我看了一张他们引以为傲的排产表：用两周时间把387个研发任务分派给6条产品线的92名工程师。结果三周后…