需求管理

资源评估最容易失真的时刻，往往不是团队完全不知道自己有多少人，而是每个人都能报出一个看似合理的数字：产品说需要两名研发，研发说本季度已经排满，管理者看着项目表却仍然无法回答“这项需…

版本规划会上，最容易造成延期的往往不是“需求太多”，而是团队把不同确定性、不同价值和不同依赖关系的需求放进同一张优先级清单里，再用一个看似精确的日期承诺全部交付。对企业管理者来说，…

需求排期最容易犯的错，是把“开发要几天”当成“需求什么时候能交付”。在一个包含产品、研发、测试、数据和外部接口的需求里，编码可能只占整个周期的三分之一；真正拉长日期的，往往是需求反…

迭代规划流程与规范：企业管理者需求排期风险控制关键指标 迭代计划按时发布，不等于排期风险受控：如果计划内需求完成率很高，却有大量高优先级事项在最后几天插入，团队可能只是靠加班把失控…

资源评估最容易犯的错，不是算错了团队有多少人，而是把“有几个人”误当成“有多少可用产能”。一个看起来有 12 名研发、4 名测试的团队，扣除支持工作、会议、休假、维护和并行项目后，…

需求排期最危险的错误，往往不是把日期算错，而是把“人名和工时都填满了”误认为“项目已经可交付”。我做需求评估时，首先追问的不是“这项需求几天能做完”，而是：在既定日期、可用技能、依…

需求排期最危险的时刻，往往不是需求太多，而是所有需求都被标成“高优先级”，每个部门都认为自己的事项必须进入下个版本。此时如果只按人天相加，计划表看起来能装下，实际上却可能同时撞上依…

版本规划失效，往往不是因为需求太多，而是因为团队把“有人提出”误当成“值得进入本版本”。我在梳理中大型团队的排期机制时，反复看到一种情形：计划会上，产品、销售、研发和交付各自拿着一…

需求排期最容易出问题的时刻，往往不是团队没有计划，而是计划看起来过于确定：本季度承诺了 40 项需求，开发容量按人头算得很充足，到了第三周却发现关键依赖尚未交付、线上缺陷挤占迭代、…

需求排期最容易出问题的地方，往往不是团队不会打分，而是每个人都能给自己的需求找到一个“最高优先级”的理由：销售说客户马上续约，产品说这是战略方向，研发说技术债已经拖慢交付，管理层则…