研发流程优化

去年十一月，我陪一家做企业服务的研发组织做季度复盘。他们 4 个研发小组、118 名工程师、9 个迭代，Sprint 承诺完成率连续三次停在 62% 附近，可每个人的日程表看起来都…

研发团队看起来“人手不够”，有时并不是缺人，而是关键工程师同时背着五六项任务、等待评审的工作被算成了已完成、不同团队对“可用产能”的口径也不一致。资源负载工作负载管理要解决的，正是…

研发团队出现资源冲突时，最容易被误判的情况是：项目明明已经安排了足够的人，任务也分配到了具体负责人，但到了迭代中期，关键需求依然延期，测试排队、开发等待、技术负责人被多个项目反复拉…

人力资源计划要做好研发团队工作量，关键不是把每个人的工时填满，而是提前判断哪些工作会真正消耗产能、哪些任务会在流程中反复返工，以及团队需要为不确定性保留多少空间。我在研发流程诊断中…

延期分析真正落地，关键不是每周统计“晚了几天”，而是把延期从结果追责改成过程诊断：在承诺日期之前识别风险，区分可控与不可控原因，再把分析结果落实为资源调整、范围取舍和流程改进。下面…

延期审批最容易失效的时刻，往往不是负责人说“做不完”，而是团队只把计划结束日期往后挪了几天，却没有说明哪些工作被挤压、哪些承诺需要重谈。研发延期管理的核心不是让每次延期都通过或都被…

研发团队资源管理效率，往往不是“人够不够”的问题，而是技能、流程和规范能不能把合适的人放到合适的工作上。一个常见信号是：团队看板上每个人都有任务，关键项目却仍因某个稀缺技能等待两周…

研发团队做资源管理，最常见的误判不是“人手不够”，而是把每个人都排满，就以为资源利用率提高了。一个迭代里，开发任务看起来全部有人负责，实际却有关键评审等两天、测试集中到最后三天、线…

研发团队资源管理最容易出现的误判，不是“人不够”，而是把所有人的时间都当成可随时调用的空闲容量：计划表显示每人每周还有两天，项目却连续延期；管理者不断借人救火，关键模块反而没人能稳…

研发团队的资源管理，最容易被误判成“人手不够”：项目延期，就加人；需求堆积，就催进度；几个关键成员忙不过来，就把任务拆给更多人。可我在梳理研发流程时反复看到另一种情况：团队并非缺少…