标签：
项目在客户的眼中，需求经常是含糊不清的，他们也经常道不清述不明，客户内部也常常众口不一。客户没有责任把需求整理好来告诉你，就算告诉你的也不一定就是他们最终想要的，所以作为项目经理，“范围管理”是非常重要的活动。这里主要讲述一下我作为项目经理的职能时，在项目范围管理中，进行的收集需求、定义范围、创建WBS、确认范围、控制范围的过程。
项目管理-时间管理-甘特图（http://www.cnblogs.com/wgp13x/p/4385475.html）是我的项目管理专辑的第一篇，他们都很重要。
一、收集需求、定义范围
项目范围管理是重中之重，矣是很多项目做失败的关键所在。如何正确的掌握客户的需求是范围管理的目标，而需求往往隐藏太深以至于看不到。收集需求有多种工具与技术，在瀑布或迭代式开发过程中，确定需求通常要花费较大的时间与精力来做，比如之前我们使用的UML大象技术（详情见：http://www.cnblogs.com/wgp13x/p/3824964.html）中的业务需求分析技术，因为此种项目的规模较大，需求一旦发生变更造成的影响是巨大的，要慎重对待。
下面是项目管理中十大知识领域之一的项目范围管理的框架图。
二、创建WBS，确认范围
项目范围一般不可能在项目进行过程中一成不变，但这不是在动手开发前不进行范围确定的借口。如果没有创建经过多方共同确认的范围文档，那简直是一个恶梦。你肯定也遇到过，想一下，当你接近完成某功能时，一个领导说这个跟我想要的不一样么，我想象中的应该能完成那样的功能啊，另一个领导说也不对，应该是另一种效果，你是不是很抓狂。说到底，业务肯定是业务单位最了解，沟通重要，方法更重要。我们要在动手做之前“确定”好，要做什么，做出来的产品应该是什么样的。注意这里的“确定”不是项目经理说的算的，也不是某一领导说的算的，有争议的要及时沟通，尽早解决。
上面是我用“亿图”工具绘制的我们上个项目的WBS图，内容不全，这里只用作说明。
下面是我制作的《项目需求规格说明书》的一部分，它是使用EXCEL绘制，TFS管理。
上图中画红框的部分是会经常用到的，它们可以与TFS集成使用，因此非常易用，项目团队中的成员可以随时查看我们的项目范围。
三、控制范围
项目范围一般不可能在项目进行过程中一成不变，就像接口肯定不能完全一路到底一样。双方开发前“敲定”的接口真的能“敲定”吗？总有技术细节在真正实施前没有被考虑到。项目范围也一样，尤其是对经验欠缺的项目更是如此。项目开始前指定的项目范围需要随着业务分析与系统分析的过程，进行细化与补充，甚至详细分析完成了都会有“个别”的项目范围不能确定，但这只是很少数的。沟通是最重要的，无论在何时进行范围确认与更新时，一定要保持与干系人的及时沟通。毕竟我们是服务提供者，没有什么事情是不能商量的。会出现这么一种情况，在开发后期出现了“莫名遗漏”的需求，产生的原因很多，只能避免，无法杜绝。这里可能会产生一个“变更”，这时我们就要考量此“变更”会带来的影响，进度上的、成本上的等等，再作决定如何处理，关于这些就要在“变更管理”一节中详述了。
总结
项目范围是“三权分立”中的最基本、极重要的一权，它是后续开发的依据，更是系统测试的依据。没有它很多扯皮的事情就要发生，没有它系统测试都无所适从。项目范围管理非常重要，这也是我在管理上个项目中所取得的极其amazing的经验与技能。
家里有一整套1995年猪年邮票，距今整整20年了，不知道价值现在几何。猪邮票还挺可爱的
，给大家贴两张欣赏一下。
项目管理-范围管理-项目需求规格说明书
标签：
原文地址：http://www.cnblogs.com/wgp13x/p/4445485.html
