虽然现在是敏捷时代，但把项目范围管好这事的道理没变。以前我们总爱用“不做多余的事”来形容它，现在把这句话拆开，其实就是看清楚“产品”和“项目”到底画了哪条分界线。产品范围说的是你最终要交付什么东西，功能到底有哪些，得用需求来衡量；项目范围呢，就是为了做出那个东西得干哪些活，得看里程碑、预算和时间表是不是都对上了。这两条线要是能对齐了，项目才算真正做对了事情。 商业分析师现在得给项目经理当“外脑”，不能光是干老本行收需求了。大家一起合作，主要是要搞定这几件事：先看看业务到底哪儿痛，把真需求找出来；再想想方案行不行得通，算算投进去的钱能不能赚回来；接着把干系人说的话变成可以测试的产品特性；最后还得盯着项目上线以后能不能一直赚钱。有了这个搭档在团队里，项目经理省心多了，只要把需求活动写进计划里按部就班干就行，只要商业分析师那边和大家保持信息透明，不管怎么变都得先看能不能最大化价值。 不管你用不用敏捷这套法子，项目范围管理的流程其实也就那么几步。第一步就是规划范围管理，得像画路线图那样，把怎么定义、确认、控制产品和项目的边界写清楚；接下来是收集需求，别让干系人说的话到了最后变成猜谜语；再定义范围的时候，要用说明书或者功能清单把产品的事说透；WBS这一步特别关键，得把可交付成果拆成每个人都能接手的小任务包；验收的时候组织大家正式签个字确认；最后是控制范围，变更是一定要走流程的，不能让需求跑掉。 每个项目都不一样，所以流程得照着实际情况剪一剪。得看看公司有没有知识库能复用；有没有正式的验收标准；是用纯敏捷还是混合开发；需求是不是像沙子一样容易变；还有公司治理层管得严不严。把这些因素列在一张“裁剪登记表”上就能找到平衡点了。 当需求变来变去、风险又大的时候，那种一次性把范围定死的老办法肯定行不通。敏捷和适应型的办法就是把一次定义变成多次小步定义。一开始先弄个最小的可用范围出来；在每一轮迭代里重复收集需求、定义功能、拆WBS这三步；让发起人和客户代表一直在旁边看着；每轮迭代结束前都要把确认范围和控制范围这两件事干完。 这样就能把模糊的需求慢慢打磨成清晰的功能了。在这种适应型的生命周期里可没有那种完全冻结的基准范围，只有一张不断更新的未完成项清单。每过一轮迭代清单就往前挪一步，直到最后产品真正上线为止。