研发任务管理

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

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

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

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

去年冬天我接手一家工业 SaaS 公司的研发效能诊断，团队 130 人、19 个研发小组，跑的是很标准的双周迭代。看板上每个迭代挂着 180 多条任务，乍看管理得很细，但导出一份&…

去年我接手过一个 180 人研发组织的效能复盘。他们在三个月前刚上线了一套“完整”的任务管理制度：12 个状态、23 个必填字段、每天两次站会、每周一次工时汇总。上线第九周我拉了一…

一个 130 人的研发团队，三个月内把事项管理制度推翻重做了两遍，第一版是"全员同一个看板、所有任务颗粒度统一到半天"，结果两周后看板积压到 4000 多条，没…

上个月我帮一个 300 人的研发组织做交付复盘，翻出他们半年的任务数据后，发现一件挺刺眼的事：需求从创建到上线的平均周期是 47 天，而其中真正处于"开发中"状…

我把一个 6 人后端小组的子任务看板，和一个 180 人研发中心的子任务看板并排放在一起看过，结果很反常识：前者的父任务平均挂 2.3 个子任务，迭代准时率 91%；后者平均挂 7…

去年下半年，我帮一个 31 人的研发团队做流程复盘，导出他们近 6 个月的工作项记录一共 2143 条。我把每条任务从"创建"到"关闭"之间…