从定义到迭代，这就是敏捷时代里，项目范围管理的全部流程。不管是哪种方法论，核心都逃不开把“做该做的”落实到具体工作上。本质上，它是让团队把“该有什么”的产品边界，和“必须完成哪些工作”的项目边界分开来看。所谓产品范围，就是最终交付物得具备的特征和功能，得拿需求去衡量；而项目范围呢，就是为了造出这个东西必须干的那些活，得拿里程碑、预算和时间表去校验。只有这两条线对齐了，事情才算真的做对了。 现在的需求管理可不光是收集了，而是要把商业价值贯穿到整个生命周期里。商业分析师给项目经理做了个“外脑”，一起干这四件事：找出业务痛点和真实需求，给出可行方案并评估回报，把干系人的需求转成能测试的产品特性，还得保证上线后能持续赚钱。一旦队伍里有了商业分析师，项目经理只需操心两件事：把这些活动写进计划，保证按时按预算把价值交出去；再让大家信息透明，任何改动都要以价值最大化为前提。 不管是敏捷还是其他的办法，范围管理这几个步骤是跑不掉的：先得规划范围管理，制定个计划当路线图；接着收集需求，把大家的想法变成需求文档；然后定义范围，用说明书、功能清单和用户故事把产品的样子写清楚；再把项目范围拆成WBS，任务包细化到每个人都知道要干啥；最后确认验收和控制变更。 每个项目都有独特之处，项目经理得根据五个因素去裁剪流程：知识储备够不够？验收和审计的机制在不在？是用纯敏捷还是混合方法？需求稳不稳定？治理层有啥特殊要求？把这些因素填进“裁剪登记表”，就能在标准化和灵活性之间找个平衡点。 当需求变化快、风险大的时候，“一次定义全部”的老办法肯定不行。这时候就得用敏捷或适应型方法，“一次定义”改成“多次小步定义”，给项目争取时间。典型的节奏是启动时先定个最小范围，锁定第一批需求；每个迭代里都重复收集、定义、拆WBS的过程；发起人要一直跟着参与，每轮迭代结束都要确认和控制。 通过多次迭代把模糊的东西变成清晰的功能，最后凑成完整的产品。在适应型的生命周期里，没有一成不变的范围基准，只有动态的未完成项清单。每做完一轮迭代清单就往前挪一步，直到产品上线为止。