研发容量规划

版本计划失效，通常不是因为团队不会排日期，而是因为计划表里写着“确定上线”的事项，背后仍有需求未澄清、依赖未确认、测试资源未落实。某个 120 人产品研发组织的版本复盘中，团队连续…

版本规划最容易出问题的时刻，往往不是开发延期，而是每个部门都认为自己已经把需求“排进去了”：销售答应了客户日期，产品承诺了功能范围，研发按估算安排了迭代，测试却到临近发布才发现关键…

开发周期管理最容易失真的地方，不是工期估短了几天，而是团队把“需求已经排进迭代”误当成“这项工作已经具备交付条件”。我做需求排期时，首先检查需求是否足够清楚、团队本周期能拿出多少有…

需求排期最常见的失误，不是把日期排错了，而是把“有人提了需求”误当成“团队已经答应交付”。我做排期设计时，通常先问三个问题：这件事为什么现在做、谁有权确认范围、如果它插队，原计划里…

版本规划最容易失真的时刻，往往不是需求太多，而是每个部门都能讲出一个“必须进下个版本”的理由。销售说客户续约等着，产品说用户体验不能再拖，研发说架构风险已经累积，管理者最后只能在会…

需求池里有 120 条需求，季度开发容量却只有 70 人天；销售已经向客户承诺月底交付，研发负责人则认为其中至少三分之一还没说清验收标准。此时把需求按“重要、紧急”排个序，并不能得…

需求排期最容易出问题的地方，不是需求太多，而是管理层把“排进版本”误当成“团队已经承诺交付”。我复盘过的排期争议里，常见情况是版本计划写得很满，到了发布前两周才发现关键依赖未就绪、…

开发周期排期最容易出错的地方，往往不是工期估算少了几天，而是管理层把“需求优先级”直接当成“团队承诺”：需求看起来重要，便进入最近版本；业务负责人给出期望日期，计划就被倒排出来；研…

开发周期管理最容易失真的地方，不是研发团队估时不准，而是管理层把“希望本季度完成”当成了已经排入计划的承诺。一个常见场景是：季度初排进二十多项需求，到了中段，销售承诺、合规整改和线…

开发周期越紧，需求排期越不能靠“把每个人的工时填满”。我在排期诊断中反复看到一种反常识现象：团队日历看起来排得越满，版本延期反而越容易发生。原因通常不是开发不够努力，而是需求进入计…