研发风险控制

研发团队最危险的资源问题，通常不是“人不够”，而是计划表里每个人都只有 80% 负载，实际却有人连续三周加班、关键任务仍然延期。资源负载、产能和风险控制看似是排期问题，实质上是需求…

研发团队的工时表看起来是在记录“做了几小时”，实际最容易暴露的却是任务拆分、估算、变更和风险管理是否失真。一个常见现场是：迭代计划写着某功能需 5 人天，开发结束后工时表累计 8 …

工时管理计划工时全流程，真正要管的不是“每个人每天填了几小时”，而是计划如何形成、变化如何留痕、偏差如何转化为风险信号。一个常见的研发现场是：迭代计划看起来每人都排满了，临近发布却…

迭代计划里写着“本周完成 32 个需求”，周四看板却突然多出 11 个阻塞项，这通常不是团队到周四才开始变慢，而是进度管理把“完成了多少”当成了“还剩多少风险”。迭代进度教程真正要…

迭代目标写成“完成登录改版、优化查询性能、修复线上问题”，看上去任务明确，到了迭代末却常常只剩下“代码已经合并，业务效果还没验证”。迭代管理真正要做好的不是把工作塞进计划，而是让团…

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

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

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

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

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