容量校验

我带过的一个 40 人项目组，曾经在两周内连续踩了同一个坑：任务在群里 @ 了人、在工具里建了单、周会上还口头确认过一次，结果到交付前一天才发现，真正要动手的两个人根本不知道这件事…

2024 年我参与复盘过一个延期 6 周的交付项目，最后定位到的根因不是技术难题，而是一张挂了 14 天没人真正处理的接口联调单，系统里负责人一栏填着某位已经转岗两个月的同事，原负…

去年十月，我参与复盘了一个延期 23 天交付的中台版本。项目组的结论在复盘会开始前就已经写好，“需求变更太多”。但我把 47 个延期工作项逐个拆开对时间线后发现，真正由需求本身变化…

三周前，我参与一家 180 人硬件研发团队的双周迭代复盘。项目经理给我看了一份操作日志：他在任务列表里勾选了 213 条任务，用批量分配功能一次性指派给 6 个小组长，整个操作耗时…

我带过一个 28 人的实施交付团队，2023 年第三季度接过一个跨 6 个大客户的 ERP 落地项目群。项目启动那天,项目经理在做任务分派,一个下午分了 217 条任务,分了 3 …

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

2023 年 3 月，我参与一家 130 人研发组织的季度规划复盘。启动会上，他们把 412 条任务一次性拖进“待分派池”，PMO 两个人用 Excel 手工分派，干了两天半。提交…

去年第四季度，我帮一家做工业软件的客户做PMO流程诊断。他们有四个PMO、两百三十多个研发、同时在跑十九个项目。我原以为最大的堵点会在需求评审或者发布管控上，结果翻了他们两周的站会…

我做过一个不太严谨但很有启发性的统计：把过去五年经手的四十多个项目复盘记录翻出来，逐条看延期和事故的根因，结果是，真正因为技术难题、外部依赖、需求变更这类“事”的原因导致的延期，只…