项目经理该如何应对客户的需求变更

项目经理该如何应对客户的需求变更 

在项目实施过程中，大家或许遇到这种情况：
当我们辛辛苦苦熬了几个月的通宵、加班后，终于完成了客户提出的功能需求，而大家正准备按部就班上线或实施时，客户、企业用户突然又提出了新的需求。这对整个团队来说，简直是晴天霹雳。毕竟，用户只是说了简单的一句话，但是对于项目的调整来说工作量是巨大的。

需求变更，本应是客户的权力，但切勿把一些无关痛痒的变更宠惯养成堂而皇之的变更。

对于客户提出的变更，无论大小都给予解决，客户对此是非常满意，但一味的迁就用户使项目进度一拖再拖，则会造成项目无法交付，最终成为了一个“不可能完成的任务”。

但是，如果我们对客户的要求一概不理，自顾自地按照最初的需求和计划实施，最终很可能验收通不过，导致公司的利益受损。

一、需求变更的表现形式及原因

需求变更的表现形式是多方面的，如客户临时改变想法、客户的习惯、项目预算增加或减少、国家政策的改变、客户对功能需求改变等。

项目变更可能来自方案服务商、客户或产品供应商等，也可能来源于项目组内部。虽然需求变更的表现形式千差万别，但究其根本不外乎以下几种原因:

1.范围没有圈定就开始细化
细化工作是由需求分析人员完成的，一般是根据用户提出的描述性、总结性的短短几句话去细化，提取其中的一个个功能，并给出描述。当细化到一定程度后并开始系统设计时，范围会发生变化，那细节用例的描述可能就有很多要改动。

2.没有指定需求的基线
随着项目的进展，需求的基线（需求变更的分界线）也在变化。是否容许变更的依据是合同以及对成本的影响，比如软件整体结构已经设计出来是不容许改变需求范围的，因为整体结构会对整个项目的进度和成本有初步预算。随着项目的进展，基线将越定越高(容许的变更将越少)，其过程如下:变更请求->比较基线->变更实现。

3.没有良好的软件结构适应变化
组件式的软件结构就是提供了快速适应需求变化的体系结构，数据层封装了数据访问逻辑，业务层封装了业务逻辑，表示层展现用户表示逻辑。但适应变化必须遵循一些松耦合原则，各层之间还是存在一些联系的，设计要力求减少会对接口人口参数产生变化。如果业务逻辑封装好了，则表示层界面上的一些排列或减少信息的要求是很容易适应的。如果接口定义得合理，那么即使业务流程有变化，也能够快速适应变化。因此，在成本影响的容许范围内可以降低需求的基线，提高客户的满意度。

二、需求变更引发的一系列问题

1.需求来回的变动，拿不准客户真正想做什么；
2.系统的灵活性差，后期维护时间超过开发期两三倍；
3.进入开发周期的“无期徒刑”，开发周期延长；
4.团队的士气低下，影响整体开发进度；
5.自身定位不足，团队无交互沟通。

三、需求变更的控制策略

需求变更的控制不应该只是项目实施过程考虑的事情，而是要分布在整个项目生命周期的全过程。为了将项目变更的影响降低到最小，就需要采用综合变更控制方法。

综合变更控制主要内容是找出影响项目变更的因素、判断项目变更范围是否已经发生等。

综合变更控制的主要依据是项目计划、变更请求和提供了项目执行状况信息的绩效报告。

为保证项目变更的规范和有效实施，通常项目实施组织会有一个变更控制系统。变更控制系统是一个正式和文档化的程序，它定义了项目绩效如何被监控和评估，并且包含了哪种级别的项目文件可以被变更，包括文件处理、系统跟踪、过程程序、变更审批权限控制等。

综合变更控制的结果主要有更新的项目计划、纠正措施和经验总结。

四、预防项目启动阶段的变更

任何项目的变更都无可避免，也无从逃避，只能积极应对，这个应对应该是从项目启动的需求分析阶段就开始了。

对一个需求分析做得很好的项目来说，基准文件定义的范围越详细清晰，用户跟项目经理扯皮的幌子就越少。如果需求做得好，文档清晰且又有客户签字，那么后期客户提出的变更就超出了合同范围，需要另外收费。

当然，如果需求没做好，基准文件里的范围含糊不清，被客户抓住空子，往往要付出许多无谓的牺牲。

相对于需求来说， WBS、风险管理、计划进度等都是次要的，只要需求做好了就会一帆风顺。

五、正确对待需求的变更

工作中，我们不得不面对需求变更，那么用什么办法改善这种现状呢？

1.加强人员培训
首先，加强对需求分析人员的培训，尽可能增强软件系统、行业的背景知识，提高与客户的沟通能力，增强服务意识和责任感。同时，规范需求分析人员和客户沟通的方式，以及规范需求说明的格式。如果可能的话，尽量采取用户可以理解的图例来对需求进行标准、规范的描述，保证双方对需求达到共同的认识。

2.加强文档管理
需求文档是相当重要的，在做文档时大家普遍流于形式，文档也有，格式也正确，但没有人关心文档的真正内容是否正确，格式是否真的合理，是否实用，很多情况下是在几天时间里赶出来或补上去的。

当需要文档时，虽然完全符合格式的要求，可在里面能找到的线索是有限的，结果还要花很长时间查找数据表结构、甚至查看数据表的内容，询问当时的开发人员，才分析到所要的关系。

这种情况在设计文档里也存在，所以不管是开发人员、还是项目管理人员都要注意文档的有效性和有用性问题，甚至对文档的格式进行一下合理性检查。

六、项目实施阶段的变更控制

成功项目和失败项目的区别就在于项目的整个过程是否是可控的。项目经理应该树立一个理念——“需求变更是必然的、可控的、有益的”。项目实施阶段的变更控制需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。

能力的提高往往不是从成功的经验中来，而是从失败的教训中来。许多项目经理不注重经验教训总结和积累，很少系统地分析总结，或者不知道如何分析总结，以至于同样的问题反复出现。

事实上，项目总结工作应作为现有项目或将来项目持续改进工作的一项重要内容，同时也可以作为对项目合同、设计方案内容与目标的确认和验证。项目总结工作包括项目中事先识别的风险和没有预料到而发生的变更等风险的应对措施的分析和总结，也包括项目中发生的变更和项目中发生问题的分析统计的总结。

需求变更既然不可避免，那么就必须有一套规范的处理流程。对于需求变更的处理流程应该分为:提出变更->变更评估->实施变更。

CMM提出“分配需求的变更被复审，并加入到软件项目中来”，其关键是在需求发生变更时，没有必要马上把这些变更付诸于软件开发工作之中。

实际上，坚持把需求变更付诸开发努力，企业就会形成一种混乱且不稳定的氛围，进而严重破坏项目的控制和管理。

七、控制需求需要注意的问题

1.需求一定要与投入有联系，如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。在项目的开始，无论是开发方还是出资方都要明确这一条：需求变，开发的投入也要变。

2.需求的变更要经过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。

3.小的需求变更也要经过正规的需求管理流程。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间，最终导致项目失败。

4.精确的需求与范围定义并不会阻止需求的变更。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非需求写细了，它就不会变化了。

5.注意沟通的技巧。由于需求的变更可能来自客户方，也可能来自开发方，因此，作为需求管理者，项目经理需要采用各种沟通技巧来使项目的各方各得其所。