该帖子同步发自：(铁托的博客  访问该博客)

　　范围管理总的来说是两方面的内容，一方面是范围的圈定、划分，另一方面是如何有效应对范围的变更，以避免对项目进度、成本带来的负面影响，增加了项目风险。

　　一、范围的圈定及划分

　　范围管理到底这其中的范围指的是什么?笼统来讲，就是项目的参与人员、时间、成本、管理以及所有涉及该项目的其它杂七杂八事宜。

　　既然范围管理涉及的东西这么多，那我们就得好好谋划谋划，这就要求我们很有必要做好范围管理的前期准备工作，即先要弄出《范围计划编制》和《范围说明书》两样东西来，以便我们能够以科学发展的工作思路指引我们在项目中如履薄冰。

　　《范围计划编制》其实是依附于《项目管理计划》之上的，无非就是写一些项目概述、织架构及人员、进度、方方面面的约束条件而已。

　　《范围说明书》主要阐述项目的来龙去脉、目标以及最终交付给用户的成果清单。

　　我觉得以上两者都是说是顺从《项目管理计划》，或者说是在它的基础之上稍微细化了一点，其实很多都是照抄的，而范围管理真正需要的东西是《范围定义》，所以还得再遵循以上两者进行一次细化，就自动变成了《范围定义》，在《范围定义》中要把项目的参与人员、时间、成本、管理以及所有涉及该项目的其它杂七杂八事宜好好细化一遍，中要详尽描述哪些工作该做，哪些工作不应该做，定出边界，明确所有的输入输出。

　　范围定义搞清了，基本上这范围也就圈定了，接下来就要做范围的划分了。

　　范围的划分，俗称工作任务分解(WBS)，好像项目进度管理中也有一个WBS，这两者是一脉的，是相互对应的，只是一个强调的是范围，一个强调的是时间，所以在细化上有所区别。

　　对于软件开发而言，总的范围划分，除了需求、概要、设计、编码、测试等主体工作外，还有文档撰写、项目管理等工作，所有这些都得安排好人去做，要做到协调一致，不要主体工作一直向前冲，文档撰写跟不上，或者因为项目管理上出了问题，影响到主体工作的有序推进。

　　无疑范围的主体工作任务是我们要关注的重点，这就涉及到划分，只有分清楚了，分到人了，项目经理心里才会有底，以免扯皮，衔接不上。那一个系统应该如何划分?通常是自上而下的方式进行，划子系统、划工作包。

　　引述一个名词，啥叫工作包?是指比子系统更小、更易管理、更易懂的工作单元，反正是可以独立工作的东西。

　　再引述一个名词，WBS字典?就是在WBS的工作包中要附一个资源性的说明，比如谁来做，完工的起止时间，跟其它工作包或子系统的衔接等等。

　　二、范围的变更控制

　　项目经理换了、已参加开来的项目组人员跳槽了，这是范围中的人员变更。

　　项目被要求提前上线，或者因故延期了，这是范围中的进度变更。

　　以上两者发生概率还算小，或者已有一套成熟的解决方案，但对于不同的项目，需求的变更是难免的，所以也得有一套范围中需求变更控制流程。在这些变更之中，我们总是忽略一些小的需求变更，所以也总在不经意口头答应一些小的需求变更，这会是致命的。因为…在这里还有必要引述一个名词，范围蔓延：指的是不断接受一些看似很小的需求变更，当所有小的变更汇总后，才发现需要的付出的工作量比较大，且已影响到成本和进度。

　　除了众多小的变更，还有一些大的变更，除了项目之内的变更，还有项目之外的如政策因素的影响等，综观所有可能的变更，都逼得我们要制定一套变更控制流程来进行应对，在这流程中要界定好变更的批准权限，无论谁来批准，一定要先经过项目组或专门委员会进行充分的评估，以降低项目风险。