项目管理第二篇-解析项目范围管理

欢迎大家来到IT世界,在知识的湖畔探索吧!

范围管理是项目管理中非常重要的一个环节，在这个过程中建立了范围基准，明确了项目验收所必须要做的工作。如果范围管理工作没有做好，就可能出现项目范围蔓延、频繁的需求变更、客户对建设成果不满意等问题，进而可能导致项目失败。

欢迎大家来到IT世界,在知识的湖畔探索吧!

一、规划范围管理

规划范围管理是方法论，确定如何定义、确认和控制项目范围及产品范围的过程，在实际项目中一般裁剪不做，拿我们公司来说项目经理既要负责项目管理（进度、成本等），又要负责需求调研分析、原型设计、测试、实施，这么一大堆工作，我想其他公司应该也差不多，所以项目管理标准步骤里的很多内容都被裁剪了。

二、收集需求

收集需求是为实现项目目标，记录并管理干系人的需要和需求的过程。这个过程是项目管理中最重要的一个过程，很多公司花了很多精力做了很多项目管理规范流程和制度，结果却效果不是很好，为什么呢？精力用错了地方，项目管理中最应该花精力投入的就是收集需求，需求管理没有做好一切都是白搭。

在收集客户需求时使用到的工具有头脑风暴、焦点小组、访谈、问卷调查、标杆对照、原型法等，这里最重要的就是原型法。俗话说一图胜千言，人类很难通过文字把图形中的意思完全表达出来，所以需要用原型法画图。客户有时对自己的需求描述的不清楚，造成双方对需求理解有歧义，针对这种情况我们需要采用Axure等软件画出系统界面及交互逻辑，演示给客户确认，以消除彼此的歧义，充分挖掘客户的需求，在需求调研完成后我们根据调研成果编写了需求规格说明书。需求搜集和分析能力属于隐形知识，比较难以分享，需要在项目中慢慢摸索总结，后面我会再单独写一篇关于需求分析的文章。

林长制界面原型

三、定义范围

定义范围是制定项目和产品详细描述的过程，主要作用是描述项目范围边界和验收标准，在实际项目中一般裁剪不做。一般就用需求规格说明书定义项目的范围，需求规格说明中包含了主要包括项目建设现状、存在的问题、建设目标、需求分析、功能需求（包含界面原型设计）、非功能需求（性能、安全、可扩展性）等，可以根据实际项目需要增减。

PMBOOK和高项教材中对范围基准的定义是经过批准的范围说明书、WBS、WBS字典，这就是理论，为什么王明、李德指挥中国革命失败了呢？就是因为他们照搬马克思主义理论，没有做到活学活用与中国实际情况结合在一起，同样项目管理理论也是一样，如果不能做到活学活用，也是带不好项目的，这里我理解需求规格说明书就是项目的范围基准，一个软件项目那么多功能，谁有精力时间去做范围说明书、WBS、WBS字典。

四、创建WBS

创建WBS是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程 。这里需要注意的是分解是滚动式，有些工作前期可能是粗略的，随着工作的开展逐渐明确后再分解。还有WBS实际工作工作一般是不维护的，工作量太大，但分解的工作还是需要做的，一般由项目经理和技术经理口头进行分配。基于理论知识我理解WBS可以按照项目生命周期进行分解，再按可交付成果进行分解，下图是我画的一个示例,总体的不要太细，太细工作量太大，作为自己对项目有一个整体的概念边界即可。

五、确认范围

确认范围是正式验收已完成的可交付成果的过程，通过本过程可提高项目获得成功验收的可能性。一般具体做法为在项目功能开发并测试完成之后给客户一段时间进行试运行，和用户、监理一起根据范围基准、合同等要求进行范围确认，在这个过程中我们让客户亲自使用体验系统，从而确保可交付成果是满足客户需求的。

六、控制范围

控制范围是监督项目的范围状态，管理范围基准变更的过程，主要作用是在整个项目期间保持对范围基准的维护。对范围基准的变更都要走整体变更控制流程，不是我非要喷教材，这就是理论，不符合实际中国国情，需求规格说明书作为范围基准，其中某项功能增加了一些字段、界面交互增加、优化一下功能操作，这如果都走整体变更控制流程，那该是多大的工作量，项目肯定要干挂了，客户关系也会搞的很紧张。我根据个人理解给出的答案就是如果变更的工作量不是很大，就直接安排给客户做，如果变更工作工作量比较大就需要同用户协商，根据是否在合同范围内、是否是项目建设所必须，再报给公司同用户一起协商后确定是否做。

喜欢本篇文章的朋友们请动动发财的小手，帮忙关注一下和点赞，是我继续坚持分享下去的动力。