研发任务管理

2024 年 3 月，我接手一家约 200 人规模的 SaaS 公司做研发效能诊断。第一周就撞见一个反常识的现象：他们的《研发任务管理制度》有 37 页，定义了 9 种任务类型、5…

去年 9 月，我帮一家 137 人的研发组织做任务管理复盘。我做的第一件事不是看代码质量，也不是看需求数量，而是把两个迭代、12 个团队、2847 条任务记录全量导出，按&quot…

2021 年我给一个 180 人的研发团队做流程诊断。他们的看板上有 1374 个活跃事项，平均颗粒度 2.2 人天，字段填得相当完整，看起来是一套"精细化"的…

2023 年我接手一个 140 人规模的研发组织做效能诊断，第一周就被看板上的一组数据钉住了：一个季度内团队创建了 11327 条子任务，其中 41% 的子任务生命周期不足 6 小…

如果你去问十个研发负责人“团队任务管理的最大问题是什么”，大概有八个会说是“工具不好用”。但如果真的把工具换掉，你会发现三个月后同样的问题又长出来了，只是换了个界面。我在过去六年里…

我见过一个 6 人的研发小组，把「订单退款」写成一个 40 小时的任务，指派给一个人，然后在前一天的日站会上才发现：退款金额计算的规则要财务系统提供接口，而那条接口的排期在两周之后…

2023 年我接手过一个 128 人研发组织的流程诊断，第一周只做了一件事：把他们的任务看板拉出来，随机抽 200 张标记为「进行中」的任务卡，逐张比对代码仓库的提交记录和测试报告…

2023 年我做过一件现在回想起来代价不小的事：给一个 240 人的研发组织设计了 11 个必填任务字段，结果三个月后，工程师的周期时间中位数从 4.2 天涨到 6.7 天，而管理…

去年我参与复盘一个 140 人的研发组织时，看到一份很难看的数字：季度初排了 386 个任务，季度末真正上线并产生业务价值的是 271 个；剩下的 115 个里有 62 个&quo…

研发团队里最容易被忽视、又最容易出乱子的制度设计，不是代码规范，也不是发布流程，而是「父任务到底怎么用」。我见过一个 120 人的研发组织，在同一个项目管理平台里跑了两年，父任务平…