项目管理

去年我帮一家 180 人的 SaaS 公司做交付诊断，研发负责人给我看他们的迭代看板：42 个任务，每个任务标题都是"XX 模块开发"，预估工时集中在 3 天，…

任务管理做不好，真正的病灶往往不在工具 2023 年我以研发效能顾问的身份进场过一个 200 人规模的研发组织，当时的场景让我印象很深：他们同时维护着 47 个看板、三套任务系统，…

我带过的一个 23 人研发团队，曾经连续三个迭代出现同一个现象：迭代计划会开满 90 分钟，任务清单拉了 60 多条，看起来排得很满，但到迭代结束仍有四分之一的任务挂在“进行中”，…

去年我帮一个 120 人的研发团队做流程诊断，翻他们任务系统的时候发现一个很扎眼的数字：过去 90 天里，被创建的任务有 4.7 万条，但真正走完「关闭」状态、有明确验收记录的只有…

过去三年我参与过两次研发协同流程改造，最近一次是在一个 130 人规模的研发组织里。项目启动第一周我拉了三个月的任务数据做基线分析，结果不太好看：系统里状态为"进行中&q…

过去三年，我以外部顾问的身份深度参与过 23 个研发团队的任务管理改造，最小的团队 14 人，最大的一个事业部 1260 人。有一个数字在所有团队里反复出现：改造之前，看板上&qu…

我见过一个 140 人的研发中心，在三个月里把任务管理系统的字段从 27 个精简到 9 个，需求平均交付周期反而从 18.4 天降到 11.2 天。也见过另一个 60 人的团队，反…

三年前我接手过一个 180 人研发组织的工作项治理项目。当时他们的现状是：需求写在文档里，任务写在表格里，缺陷写在邮件里，进度靠周会口头同步。团队并不缺工具，他们缺的是把&quot…

我见过一个30人的研发团队，把“登录模块优化”拆成47个子任务，结果交付延期6天；也见过另一个40人团队几乎不用子任务，靠一张共享表格把版本按时发了出去。子任务从来不是“拆得越细越…

我做过一次回溯统计：在一个 200 人规模的研发组织里，父子任务的平均层级深度从 2.1 层涨到 3.4 层，只用了不到两个季度；而同一时间窗内，迭代准时交付率从 78% 掉到 6…