项目需求变更控制不当，给项目经理带来的悲剧结果

（一）什么是需求变更

需求变更，即对项目或者软件开发需求的更变，是指在跟客户签订了项目或软件开发协议之后，在完成交付之前，客户提出的对项目或者软件的功能或非功能性的更改要求。
客观地说，“项目一旦启动，变更也就随之而来”，但是，需求的变更必然会影响到项目的开展或者软件的开发，需求变更对项目或者软件开发成败有重要影响，我们既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以控制需求变更才是最好的应对策略。当然，需求变更控制的目的不是控制变更的发生，而是对变更进行科学的管理，要确保变更有序地进行。
一般地说，为了确保需求变更符合双方的利益，可以采取如下措施来控制需求变更：
1.分级管理客户需求，重点客户重点管理；
2.项目开发生命周期全过程需求变更管理，确保整个项目顺利完成；
3.专人负责需求变更管理工作，确保工作同步进行；
4.契约化管理需求变更。合作双方在签订协议之初，书面约定需求变更的提出方式、评价程序、修改要求、执行过程以及验收要求等。只有这样，才能确保需求变更按程序和要求有序进行。
5.需求变更必须提前沟通，双方要加强信息交换，防止搞突然袭击，更不能提出超越双方能力的需求变更。 

（二）需求变更控制要注意的几个问题

需求的变更通常是不可避免的。所以，敏捷的宣言就提倡拥抱变化。但是，虽然变更是不可避免的，但对于变更一定要进行控制，不受控制的变更可能会提高项目的成本，迟滞项目的进度，甚至给项目带来失败的风险。

这说明需求变更控制这一实践不容小觑，可是经验教训表明，这一实践在具体实施的时候，总是浮于表面，很难取得有意义的效果。

加强需求变更控制，要注意以下几个问题：

必须做好需求变更影响分析
即使软件过程管理体系文件中规定了需求变更影响分析的内容，这个影响分析也会做不好。那是因为管理者和设计师都没有了解清楚变更影响分析的意图。需求变更影响分析包含两个目的，一方面是分析变更会给软件带来哪些影响，包括好的方面，也包括坏的方面，这部分内容将会成为需求变更审批者进行决策的一个依据；另一方面，需求变更影响分析要分析清楚变更的方案，供CCB决策。设计师理解这个意图能更好地分析，决策者理解这个意图也能更好地决策。所以软件过程管理体系文件中也要讲清楚这个意图。

再小的变更也要履行正式的变更流程
变更控制就是要杜绝随意性。因为每一次变更都会对软件带来或大或小的影响，改变了计划、推迟了进度、影响了功能、颠覆了架构……。所以在软件开发过程中，不允许随意改动需求。变更控制的另一个目的是，让需求的变动以及受其影响带来工作产品的改动，都应该让各利益相关方知悉。如果变更不走正式的流程，很有可能这个软件被更改了，但只有少数人知道，一些利益相关方未能及时发现、及时了解软件的变更，将会极大影响后续的工作。

变更决策要慎重
需求变更在某种程度上是开发方和用户的博弈。对于变更的决策一定要慎重。

决策要基于理性而非感性。要考虑清楚变更之后，对软件来说是弊大于利还是利大于弊，以此来判断变更是否实施。变更的决策应尽可能地基于量化的数据，这些量化的数据主要来自于变更申请单中变更影响分析。

管理者在审批需求变更的时候，一定要衡量清楚利害关系，才能批准变更的申请，不能不闻不问，只是机械的签字通过了事。

必须做好变更的验证
每一次变更都有可能引入新的缺陷，所以，在变更完成之后，对变更的验证非常重要。尽管已经分析出了变更对于软件是利大于弊，这个变更值得进行，但是如果变更后没有对软件进行充分的验证，让变更后的软件又引入了新的缺陷，那就是事倍功半，得不偿失。

需求变更控制是需求管理的重要实践，不容小觑。

（三）我的项目血泪史之频繁需求变更

没有播种，何来收获;没有辛苦，何来成功;没有磨难，何来荣耀;没有黯淡，何来辉煌。

前段时间，我出任项目经理承接了一个中型软件项目，公司再三叮咛我一定要尊重客户，充分满足客户需求。项目开始比较顺利，辛辛苦苦熬了几个月的通宵，基本保持项目的正常进度，客户相当满意。但进入后期以来，客户频繁的需求变更却带来很多额外工作。

需求变更不但越来越多，更可怕的是为了节省时间，客户不再向我申请变更，而是直接找程序员商量。程序员疲于应付，往往直接改程序而不做任何记录，很多相关文档也忘记修改。很快就出现一个问题，就是需求、设计和代码无法保持一致，甚至没有人能说清楚现在系统到底改成什么样。后来因频繁出现改好的错误又重新出现，客户投诉表示无法容忍这种低下的项目管理水平。这让我很无奈，疑惑自己到底错在哪里。

Q1：什么是需求变更?

(1)什么是需求分析?
要知道需求变更是什么，首先要知道什么是需求分析。
需求分析是一个复杂的问题。作为软件开发人员，一定了解软件工程学，而这门科学的第一步就是需求分析。打开任何一本软件工程的书籍，翻看目录就知道需求分析的地位。软件需求分析是整个软件开发最关键的一个输入。和传统的生产企业相比较，软件需求具有模糊性、不确定性、变化性和主观性的特点，它不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的。因此，软件需求是软件项目最难把握的问题。
简单的说：需求分析是指理解客户需求，就软件功能与客户达成一致，估计软件风险和评估项目成本代价，最终形成开发计划的一个复杂过程。需求分析主要包括：业务需求、客户需求和功能需求三个部分。业务需求意为客户对产品的目标或者要求，客户需求意为客户在使用产品过程中需要完成的一系列任务，功能需求则指定了产品系统必须提供的功能。 

(2)什么是需求变更?
在软件开发过程中，开发经理所要面对的将是一系列和多方面的考验。其中，最让开发经理头痛的就是需求变更。根据软件工程思想定义，需求说明书一般要经过论证，如果在需求说明书经过论证以后，需要在原有需求基础上追加和补充新的需求，或对原有需求进行修改和削减，均属于需求变更。而且，客户变更需求是软件开发与生俱来的特性，也是一个无法避免的事实。
需求变更好比是万恶之源，为项目的正常开展带来不尽的麻烦。需求变更的表现形式是多方面的，如客户临时改变想法、项目预算增加或减少、客户对功能的需求改变等。需求变更问题是每个开发人员最头痛的问题。因为一旦发生了需求变化，就不得不重新修改设计、重写代码、修改测试用例、调整项目计划等。这时，如果开发团队缺少明确的需求变更控制过程或采用的变更控制无效，很可能会造成开发进度拖延、成本超支、人员士气低落，而且越往后的需求变更产生的风险将越大，甚至导致整个项目失败。

Q2：需求变更无可避免
对于需求变更，我们总认为能够完全掌握它，可实际情况是——需求变更往往在所难免。以前出现这种情况时，总觉得很沮丧，觉得自己的工作做得还不细，有些内容要让用户签字确认就好了。可在经过多次需求变更的痛苦后，才恍然大悟：软件开发的需求变更是无可避免的。

(1)三极世界和需求变更的必然性
需求、客户、开发人员是一个三极世界。这三极的沟通是很不容易的。客户向我们滔滔不绝地描述需求，开发者听得头晕脑胀，但又不得不根据这些来理解需求。有的时候我们也会派好几拨人轮番折腾客户，这样客户也晕头转向，巴不得赶快需求调研结束。这样的需求调研像透过布满小水珠的玻璃看世界一样，即使能够看清轮廓，但细节的丢失在所难免。
之所以这样，是有原因的：第一，是因为客户自己对需求进行了过滤，有时是因为客户对需求的理解也不准确，有时是客户的视角与我们的不同。第二，是开发者对需求的理解偏差。有可能是由于缺乏知识，开发者对需求理解错了;还可能是开发团队内部造成的偏差，比如需求调研人员往往同时做好几个项目，在调研完成后便不在开发团队中，这样偏差便在所难免。还有就是内部沟通、人员更替造成的偏差。因此，在这样一个三极世界，需求变更是必然的。

(2)合同签订马虎，没有真正明白客户需求
当我以合同上没有规定的需求不予开发时，客户搬出销售人员的承诺这一招，更让我几乎吐血。销售人员在签订合同时缺乏对客户需求的认真对待，导致需求描述不清，为开发带来了许多困惑和后患。例如，销售人员有时为使客户能够快速地签订合同，往往草率决定和片面同意客户提出的需求。当客户提出新的需求时，往往是销售人员一看“应该”只是一个小小的修改，没有太大的影响，所以直接答应能变更。

该问题的关键是合同签署得太烂，没有把需求明确再签合同，而且也没有把需求变更的流程写入合同。如果在签合同前就把客户需求弄清楚，后期就根本不需要频繁地变更需求。签订合同时明确定义开发需求的范围，可以为以后各项开发工作的开展奠定好的基础。

Q3：需求变更为何没完没了?
在软件开发中，最常抱怨的是这样一个问题：客户为什么总是反反复复?造成需求变更没完没了的原因，可以是这样几个方面存在问题。
(1)没有明确的需求变更流程
没有明确的需求变更管理流程，就会使需求变更变得泛滥，在这一点上我尝尽了苦头。并不是所有的变更都要修改，也不是所有变更都要立刻修改，明确需求变更管理流程的目的是为了决定什么类型的变更需要修改和什么时候修改。比如单纯的界面风格问题，就可以先不修改，或者规划一下修改的时间待到以后进行优化。另外，对于核心功能的修改没有严格把关流程，有些小需求看起来工作量不大，但是哪些销售人员或者客户没有考虑到的细节问题实际上需要花费开发人员相当长的时间去完成，从而是捡了芝麻掉了西瓜，得不偿失，使开发进度失控和资源。

(2)没有让客户知道需求变更的代价
对变更的影响没有进行成本评估是需求变更泛滥的根本原因，这是我从单纯的技术人员转变到统筹兼顾成本管理的转变点之一，当然为了这一点我也付出了血与泪，为此饱受公司领导和客户的重重抱怨和责备。变更都是有代价的，应该要评估变更的代价和对项目的影响，要让客户了解需求变更的后果。如果客户不知道需求变更付出的代价，对开发人员的辛苦就会难以体会。在评估代价(包括成本、时间等多方面)过程中，可以请客户一起做判断：“我可以修改，但您能接受后果吗?” 

Q4：如何有效控制需求变更?

需求变更对软件开发项目成败有重要影响，既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以实施需求变更之前必须做好控制。需求变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。

(1)明确合同约束，建立需求基线
需求变更给软件开发带来的影响有目共睹，所以在与客户签订合同时，可以增加一些相关条款，如限定客户提出需求变更的时间，规定何种情况的变更可以接受、拒绝或部分接受，还可以规定发生需求变更时必须执行变更管理流程。虽然软件开发合同很难在签订之初就能够精确定义每项需求，单靠合同是帮不上忙的，但也不能忽视合同的约束力。
明确和树立需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(客户参与评审)，建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线，做到小需求可以变更，但大方向要力保不频繁变更。例如，对于项目中的需求，可以实行分级管理，以达到对需求变更的控制和管理。

(2)建立变更审批流程
在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低开发效率，浪费时间。正是这种观念才使需求变更变得不可控，最终导致项目的失败。因此，小的需求变更也要经过正规的需求管理流程，否则会积少成多，积重难返。
明确需求变更审批环节、审批人员、审批事项、审批流程。这么做的目的有两个：一是将客户下达变更的流程尽可能地规范化，减少张嘴就来的非必要、非紧急、非合理、非高层领导意图的无效变更。二是留下书面依据，为今后可能的成本变更和索赔准备好“变更账”。凡未履行审批程序的“变更”，一律是无效变更不予受理。

(3)分级管理变更，定时批量处理
软件开发项目中，“客户永远是对的”和“客户是上帝”并不完全正确，因为在已经签定的项目合同中，任何新需求的变更和增加除了影响项目的正常进行以外，还影响到客户的成本投入收益。因此，用户不断提出对项目进度有重大影响的需求对双赢也并不是好事。
当遇到客户提出需求，不及时处理可能会使项目不能验收通过时，也不能一味拒绝不予开发。因此，当客户坚持变更新需求时，可以建议客户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。例如，每周或每两周甚至每月召开一次需求变更专题会议，集中研究处理这些零碎变更事项，主动控制好工作节奏，尽量避免由于处理零碎变更而影响项目进度。针对会议结果可向客户正式提交一份需求变更计划，注明变更引起的时间、成本、工期代价和增加工作量等。要求客户配合需求变更计划，确定变更时限，控制变更规模，过时变更不候，离谱变更不做，保大局弃小变。

(4)安排专职人员负责变更管理
有时开发任务较重，开发人员容易陷入开发工作中而忽略了与客户的随时沟通。因此，需要安排一名专职的需求变更联络人员，负责与客户及时交流，跟踪和汇报需求变更完成进度和情况。同时，可以成立项目变更控制小组，负责裁定接受哪些变更，小组由项目所涉及的多方人员共同组成，应该包括客户方和开发方的决策人员在内。

(5)确认客户是否接受变更的代价
要让客户认识到变更都是有代价的，要和客户一起判断需求变更是否依然进行。例如，变更是没有问题的，但是要明确客户能否接受由此引起的如进度延迟、费用增加、效率下降等问题。一般来说，如果客户认为该变更是必须的(不是其上级领导拍脑袋提出的)就会接受这些后果。通过与客户协商，这样开发团队即使没有回报，也不会招致公司和客户双方的埋怨。

如果客户认为该变更虽然有必要但是可以暂缓，双方签署备忘录后留待以后解决。如果客户认为该变更可有可无，多数情况下会取消变更。这样即可防止频繁变更，也让客户认识到不是所有的需求都需要变更。