研发风险控制

去年 Q4，我帮一家 320 人的研发组织做年度人力盘点。HR 交上来的计划表非常漂亮：18 个项目、94 个研发人头、四个季度 FTE 排得满满当当，整体利用率算下来 98%。三…

去年第四季度，我参与了一家约600人研发组织的年度复盘。他们在年初做过一份很漂亮的《研发人力投入计划》：新功能62%、技术债18%、维护支持10%、应急预留10%。到了12月，实际…

研发团队的资源管理失控，往往不是“人不够”这么简单：同一位资深工程师同时被三个项目列为关键人，迭代计划看起来都能按时交付，直到线上故障、需求变更或关键人员请假，所有计划一起失效。我…

Bug 优先级排错，通常不是因为团队不知道“线上故障比文案错字严重”，而是因为每个人都在用不同的尺子：产品看用户投诉，研发看修复成本，测试看复现难度，业务看发布日期。结果是一个影响…

看板已完成教程：研发团队风险控制，避坑指南 研发看板上最容易被误判的，不是“进行中”，而是“已完成”：卡片变绿了，风险却可能还留在未验收的代码、未解除的依赖、未关闭的缺陷和无人跟进…

研发看板上有任务、有负责人，也有“进行中”和“已完成”，项目仍可能在上线前突然发现接口未联调、关键测试环境不可用，或者一个重要决策始终没人拍板。问题通常不在于看板上少了一列，而在于…

研发看板上最危险的信号，往往不是“红色风险”太少，而是所有卡片都在移动，关键依赖却没人负责；待办不断增加，团队仍把“进行中”当作进展。做好 Kanban，不是把任务贴上墙，而是让工…

研发甘特图最危险的时刻，往往不是某个任务延期，而是日期被改了很多次，团队却已经说不清最初承诺了什么。没有保留计划基线，延期就失去参照；没有记录当前预测，管理者会把旧日期误当成最新承…

去年年底，我帮一家做工业物联网的研发团队做了一次进度复盘。他们 42 人的研发中心，年初立了 17 个版本目标，到 12 月 31 日真正按原计划交付的只有 6 个，交付率 35%…

2023年我接手过一个典型的研发进度失控项目：一个12人的后端团队，原计划14周交付的订单中台重构，在第8周进度评审时实际完成度只有41%。团队每天加班，周报上写满了"进…