飞飞

三年前我参与过一次项目复盘：一个持续 5 个月的车载系统项目，在第 14 周把「车机蓝牙协议适配」这个任务的负责人从 A 换成 B。在项目管理工具里改这个字段花了不到 10 秒，但…

去年下半年，我参与了一家 200 多人研发组织的交付复盘。他们把过去两个季度 1680 个延期任务做了归因分析，结论有点反常识：真正因为技术难度卡住的只有 11%，剩下 89% 的…

去年冬天我参与了一次跨部门复盘，会议室里最刺眼的不是延期 11 天的看板，而是一份已经开发完成 80% 的支付对账需求：原负责人在休陪产假的两周里，把任务转交给了同组另一位工程师。…

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

去年我帮一家 180 人的 SaaS 公司做研发流程复盘，翻出他们某季度 47 个延期交付的任务，逐个追溯派单记录，结果很刺眼：其中 29 个任务的延期，不是因为技术难,也不是因为…

核心结论：任务分派不是"发任务"，而是一次风险定价 先给结论：绝大多数项目延期，问题不出在执行阶段，而出在任务分派完成的那一刻。分派动作结束的瞬间，团队其实已经…

很多团队在复盘延期项目时，会把原因归结为“人不够”“需求变更太多”“测试时间被压缩”，但我做过十几轮项目流程审计后发现，真正被低估的高频风险源，往往藏在最不起眼的一步：谁把任务指派…

三周前，一个做智能硬件的团队找我复盘延期原因。他们研发中心一共52个人，同时跑4条产品线，用的是一套主流项目管理工具，每个任务都有负责人、有截止时间、有燃尽图，看起来一切正常。但最…

上个月我陪一家做智能硬件的客户复盘一起典型事故：项目经理在周五下午用批量分配功能，把 47 条需求一次性指派给了一个 9 人小组。周一早上，三个工程师的待办列表里各躺着 60 多条…

我把过去三年经手的 17 个研发团队的周会记录、需求池导出文件和项目管理平台的埋点数据翻了一遍，发现一个反常识的数字：任务分派环节消耗的时间，平均占项目经理每周工时的 23%。而其…