项目范围管理

项目场景：

 

与微保合作的一个项目在实施过程中出现了两个比较严重的问题，一个是需求变更频繁导致上线时间一再延误，另一个是上线后，系统问题大大小小层出不穷，严重影响客户体验。

 

问题分析：

 

需求变更频繁是项目开发中经常遇到的问题，恐怕除了客户，各阶段人员都十分讨厌这种朝令夕改的变动，那为什么会发生这种情况，又该如何缓解呢？我们将发出变更请求的原因总结为以下四大类（受软件维护分类规则启发）：

1. 更正性变更，例如功能BUG修复，这种变更需要根据其严重性来确定；
2. 适应性变更，例如适应业务发展、国家政策的变更；
3. 完善性变更，例如完善前期需求调研不缜密或者需求沟通不到位导致的需求漏洞；
4. 预防性变更，例如顺应用户操作行为，追求更好的用户体验，自发提出系统升级；

 

 

针对这四类变更，我们可以又可以从前期规划和后期控制两个维度进行变更管理。杜绝变更请求是不可能的，只是说如何通过系统管理手段尽量让用户不随意提出变更。

 

 

第二点系统频频出现问题，严重影响用户正常使用，这个很明显是质量问题，将在质量管理章节仔细讨论。

 

问题处理：

 

首先我们看下PMP范围管理图是如何规范范围管理的：

 

  以下表格是从变更类型和管理两个维度对项目中的变更的一个概括性处理方案：

 

 

     定义变更流程是为了规范用户变更，控制随意变更的情况，可以定义为：

 

 

      需求跟踪矩阵有两个功用，一个是保证需求可追溯，一个是防止需求遗漏或错误理解，模板可以参照：

 

 
       工作分解结构WBS是对可交付成果的一个细分，其形式多样，以生命周期各阶段作为第二层根据微保项目创建的WBS：