项目管理

核心结论：负责人变更不是一次字段修改，而是一次风险事件 先说一个我在复盘会上遇到过很多次的场景。某团队在一个迭代周期内，因为人员借调、请假、离职、优先级调整，累计变更了 63 次任…

去年 Q3，我参与复盘一个 P0 级线上故障的延期时，追到的起点不是代码，而是一次看起来毫无波澜的任务转交。周五 20:40，一位后端工程师把一个"支付回调超时&quot…

去年 Q3，我在一家 400 人规模的研发组织里做了一次并不光彩的实验：把 12 个迭代、913 条工作项，按"负责人字段批量填充"的方式一次性派下去。操作只花…

2024 年 3 月，我参与了一次不太体面的项目复盘。一个 60 人规模的研发团队做跨模块重构，项目经理把 31 个任务分派给 12 名工程师，人均 2～3 个任务，工作量表看起来…

去年 Q3，我参与了一家 300 人规模 SaaS 公司的研发效能复盘。数据里有一个很反常识的数字：需求从提出到上线平均流转 6.4 个环节，但被真正“接住”的只有 4.1 个。消…

2023 年我带过一个 14 人的后端团队，一个迭代里创建了 87 条“多人任务”，每条任务的负责人字段里都塞着 2 到 4 个名字。迭代结束那天，其中 23 条停在“进度 90%…

2023 年下半年，我参与过一家约 280 人研发组织的交付诊断。他们的管理层给我看的第一组数据很漂亮：需求平均在 4.2 小时内就能派到具体开发手上，比半年前的 11 小时快了将…

我带过一个 37 人的研发团队，某年 Q3 连续三个迭代延期，最初的复盘结论是"人手不够、需求太急"。后来我把当季所有延期任务拉出来逐条对账，发现真正原因排第一…

2024年我做过一次研发效能复盘，覆盖 6 个研发团队、约 480 名工程师、累计 1.2 万个工作项。按我的原始假设，导致迭代延期的第一原因应该是技术难点或需求变更。但把数据摊开…

去年秋天我接手一个研发流程诊断项目，客户是一家做工业视觉设备的公司，研发中心 320 人，5 条产品线，横跨算法、嵌入式、平台后端、前端和测试五个职能。他们的工具栈不算落后，项目管…