项目风险控制

去年秋天，我帮一家做工业设备的中型公司复盘一个延期了两个半月的交付项目。翻遍三百多条任务记录后，我发现真正压垮这个项目的不是需求变更，也不是人力不足，而是被“静默关闭”后又悄悄重开…

去年十一月，我接手一个已经延期两周的交付项目。翻项目启动会的会议纪要，风险清单上写着 11 条风险，责任人、发生概率、影响程度、应对措施一应俱全，格式漂亮得像模板范本。但真正把项目…

2023 年 3 月，我接手了一个已经延期两次的 130 人跨端项目。复盘会上所有人都在争论"到底是需求变更太多，还是测试资源不够"，直到我把工作项列表按类型重…

去年 11 月，我负责的一个 9 人研发小组把版本延期了 23 天。复盘会上所有人都在说“需求变更太频繁”“测试环境不稳定”，但我把任务列表按时间轴拉了一遍，真正的原因是：这个版本…

去年 Q3，我参与复盘一个 42 人、跨 5 个小组的交付项目：项目经理在周会上笃定地说"关键路径没动，缓冲还有 6 天"，但两周后项目延期 11 天交付。翻查…

2021 年我接手过一个已经延期 6 周的项目。接手第一周我只做了一件事：把看板上所有在途任务的状态字段导出来，对着 87 条记录逐个核对。结果是，看板上 79 个任务显示&quo…

先给结论：任务管理失控，本质是风险暴露机制的失控 2023年我接手一个132人的跨部门交付项目，第三周就被打脸：周报上18个模块全绿，但客户验收前11天，集成测试暴露出7个阻塞级缺…

先给结论：任务拆分的本质是把不确定性切到可承诺的粒度 我带过的一个 11 人版本团队，曾经把一个看起来只有 6 周工作量的系统改造拖成了 97 天。复盘时我们发现，真正的问题不在开…

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

去年第四季度，我帮一家做智能硬件的公司做研发效能复盘时，发现一个反常识的数据：项目延期最严重的三条产品线，任务拆解粒度反而最细，平均每个需求拆出23个子任务，而按时交付的产品线平均…