该帖子同步发自：(飞眉的博客  访问该博客)

　　最近有一次全职项目经理的机会。这是第一次做真正的项目经理，所做的项目也是前所未有的困难：10天，做出一个新产品，几乎每天都有需求变更，中间还得交付一个Alpha版本与一个Beta版本供内测与公测。

　　现在项目几近完工，等待最后的上线。有一些关于项目范围(Project Scope)的心得，想分享一下：

　　1. 产品范围(Product Scope)不等项目范围。

　　简而言之，产品范围是指产品所具备的所有功能，而项目范围是指为实现这些功能，项目团队要做的所有工作。所以简单的用产品规格说明书来衡量项目进度是不正确的，比如为了实现一个好的架构，可能在前面70%的时间，一个产品功能都没有实现，而在到90%的进度时，所有的功能都完成了，但仍存在很多bug。所以在70%的时候，只根据产品范围来看项目的人会感到恐慌，而在90%的时候，他们又会错误的乐观。作为专业的项目管理人，应该要有这个基本的判断能力。

　　2. 处理好来自外部的项目范围变更。

　　最常见的一种情况就是产品需求变更。有一种错误的认为是，固化需求是项目经理的职责。其实项目经理是无权决定是否需要产品需求变更的，他的职责在于：对外告知所有的利益攸关方(Stakeholder)，此需求变更导致的范围变更的代价具体是什么(预算超支、项目延期、加班、团队士气下降等等);对内确认所有的范围变更都是可行的，且确保所有的项目团队都能准确及时更新到新的项目范围。

　　产品经理说，我要加一个功能，那么项目经理应该为他评估此功能的增加，可能会导致项目延期。更积极的是，与产品经理一起评估，制定出合理的变更方案。其中值得一提的是，避免产品经理单线的与项目成员达成变更，而未经项目经理确认。

　　3. 处理好来自项目内部的范围变更

　　一个有趣的名词叫“渡金边(Gold Plating)”：比如某个优秀的开发人员，为了追求完美而擅自决定为它打造一些更好的效果。这看起来是很值得鼓励的，但它的危害性是，项目可能为此付出更多的代价：时间、金钱。原本两天可以完成的工作，变成四天才能完成。这是一种项目范围失控的情况，所以项目经理要理智的阻止这种情况的发生。向所有的项目成员明确，什么是需要做的，什么是不需要做的。

　　总而言之，项目范围的管理，就意味着项目经理要随时掌控项目的边界，并确保所有的项目成员，所有的stakeholder都知道这个边界在哪里。