技术项目范围管理：来自实践的经验教训

范围蔓延是项目管理中最持久的问题之一。技术项目尤其脆弱——用户看到可运行软件后需求会演变，利益相关方在项目进行中参与度加深，技术复杂性揭示了项目章程中未曾预见的依赖关系。

三个典型场景

1. 不断扩大的发现阶段 ——一个政府机构委托了一个为期八周的发现阶段。四周后，接连不断的请求在没有预算调整的情况下增加了六周工作量。经验教训：从第一天起就建立正式的变更请求流程。

2. 不断增多的功能 ——一个内部报告工具的故事点从40增长到200余，贯穿整个冲刺评审过程，但没有预算调整。经验教训：产品负责人必须有权维护范围边界。

3. 出乎所有人意料的集成 ——被推迟到第二阶段的系统集成被证明是第一阶段的阻塞前提，产生了18万美元的额外费用。经验教训：在确定范围前须进行严格的依赖关系梳理。

核心经验

• 范围必须书面界定，由发起人签字认可，并在工作开始前完成。

• 变更请求不是官僚障碍，而是对项目、团队和发起人的保护。

• 在敏捷项目中，产品负责人必须有权维护范围边界。

• 依赖关系梳理与需求收集同等重要。

XNM咨询提供项目与计划交付支持，包括范围管理框架和变更控制流程。了解我们的。