我项目血泪史之频繁需求变更

下面是小编为大家整理的我项目血泪史之频繁需求变更,供大家参考。

　

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

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

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

　 什么是需求变更？

　（1 1 ）什么是需求分析 ?

　要知道需求变更是什么，首先要知道什么是需求分析。

　 需求分析是一个复杂的问题。作为软件开发人员，你必须了解软件工程，而这门科学的第一步就是需求分析。打开任何一本软件工程的书，翻翻目录，就知道需求分析的状况了。软件需求分析是整个软件开发中最关键的输入。与传统制造企业相比，软件需求具有模糊性、不确定性 、可变性和主观性等特点。与制造汽车和计算机等硬件的要求不同，它们是有形的、客观的、可描述的和可检测的。因此，软件需求是软件项目中最难把握的问题。

　简单的说：需求分析是指理解客户需求，就软件功能与客户达成一致，估计软件风险和评估项目成本代

　价，最终形成开发计划的一个复杂过程。需求分析主要包括：业务需求、客户需求和功能需求三个部分。业务需求意为客户对产品的目标或者要求，客户需求意为客户在使用产品过程中需要完成的一系列任务，功能需求则指定了产品系统必须提供的功能。

　 （2 2 ）什么是 需求变更？

　 在软件开发过程中，开发经理所要面对的将是一系列和多方面的考验。其中，最让开发经理头痛的就是需求变更。根据软件工程思想定义，需求说明书一般要经过论证，如果在需求说明书经过论证以后，需要在原有需求基础上追加和补充新的需求，或对原有需求进行修改和削减，均属于需求变更。而且，客户变更需求是软件开发与生俱来的特性，也是一个无法避免的事实。

　需求变更好比是万恶之源，为项目的正常开展带来不尽的麻烦。需求变更的表现形式是多方面的，如客户临时改变想法、项目预算增加或减少、客户对功能的需求改变等。需求变 更问题是每个开发人员最头痛的问题。因为一旦发生了需求变化，就不得不重新修改设计、重写代码、修改测试用例、调整项目计划等。这时，如果开发团队缺少明确的需求变更控制过程或采用的变更控制无效，很可能会造成开发进度拖延、成本超支、人员士气低落，而且越往后的需求变更产生的风险将越大，甚至导致整个项目失败。

　 需求变更无可避免

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

　（1 1 ）三极世界和需求变更的必然性

　 需求、客户、开发者是一个三极世界。与这三极交流并不容易。客户没完没了地给我们描述需求，开发人员觉得头晕，但又不得不根据这些去理解需求。有时候我们会派几个人轮流折腾客户，让客户一头雾水，急于尽快完成需求调研。这种需求调研就像透过一个布满小水珠的玻璃看世界。即使可以清晰地看到轮廓，细节的丢失也是不可避免的。

　之所以这样，是有原因的：第一，是因为客户自己对需求进行了过滤，有时是因为客户对 需求的理解也不准确，有时是客户的视角与我们的不同。第二，是开发者对需求的理解偏差。有可能是由于缺乏知识，开发者对需求理解错了；还可能是开发团队内部造成的偏差，比如需求调研人员往往同时做好几个项目，在调研完成后便不在开发团队中，这样偏差便在所难免。还有就是内部沟通、人员更替造成的偏差。因此，在这样一个三极世界，需求变更是必然的。

　 （2 2 ）合同签订马虎，没有真正明白客户需求

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

　 问题的关键是合同签的不好，签合同前没有明确要求，没有把更改要求的过程写进合同。如果在签约前就明确了客户的要求，后期就没必要频繁更改要求了。在签订合同时明确开发需求的范围，可以为以后的开发工作打下良好的基础。

　需求变更为何没完没了？

　在软件开发中，最常 抱怨的是这样一个问题：客户为什么总是反反复复？造成需求变更没完没了的原因，可以是这样几个方面存在问题。

　 （1 1 ）没有明确的需求变更流程

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

　 （2 2 ）没有让客户知道需求变更的代价

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

　“ 我可以修改，但您能接受后果吗？ ”

　如何有效控制需求变更？

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

　 （1 1 ）明确合同约束，建立需求基线

　 需求变化对软件开发的影响是有目共睹的。因此，在与客户签订合同时，可以增加一些相关条款，如限制客户提出需求变更的时间 ，规定可以接受、拒绝或部分接受变更的情况，规定需求变更时必须实施变更管理流程等。虽然软件开发合同在签订之初很难准确定义每一项需求，单靠合同是帮不上忙的，但合同的约束力也不容忽视。而建立明确的需求基线是需求变化的基础。在开发过程中，在需求被确定和评审( ( 客户参与评审) ) 之后，第一个需求基线被建立。每次更改和评审后，都要重新确定新的需求基线，这样小的需求可以更改，但大的方向要保持不频繁更改。例如，对于一个项目中的需求，可以实施分层管理来控制和管理需求的变化。

　（2 2 ）建立变更审批流程

　 在实践中，人们 往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低开发效率，浪费时间。正是这种观念才使需求变更变得不可控，最终导致项目的失败。因此，小的需求变更也要经过正规的需求管理流程，否则会积少成多，积重难返。

　 明确需求变更审批环节、审批人员、审批事项、审批流程。这么做的目的有两个：一是将客户下达变更的流程尽可能地规范化，减少张嘴就来的非必要、非紧急、非合理、非高层领导意图的无效变更。二是留下书面依据，为今后可能的成本变更和索赔准备好 “ 变更账 ” 。凡未履行审批程序的 “ 变更 ” ，一律是无效变更不予受理。

　（3 3 ）分级管理变更，定时批量处理

　 软件开发项目中， “ 客户永远是对的 ” 和 “ 客户是上帝 ” 并不完全正确，因为在已经签定的项目合同中，任何新需求的变更和增加除了影响项目的正常进行以外，还影响到客户的成本投入收益。因此，用户不断提出对项目进度有重大影响的需求对双赢也并不是好事。

　 当客户的需求得到满足后，如果不及时处理，项目可能不会被接受和通过，所以我们不能就这样拒绝开发。因此，当客户坚持更改新需求时，可以建议他们根据新需求的重要性和紧急程度对其进行评级，这可以作为评估需求更改的依据。比如每周 一次，每两周一次甚至每月一次，召开需求变更专题会议，集中处理这些零碎的变更，积极控制工作节奏，尽量避免因处理零碎的变更而影响项目进度。根据会议结果，你可以正式向客户提交一份需求变更计划，说明变更引起的时间、成本、工期成本和增加的工作量。要求客户配合需求变更计划，确定变更时限，控制变更规模，等待过时的变更，不做离谱的变更，保护大局，摒弃小变更。

　（4 4 ）安排专职人员负责变更管理

　 有时候开发任务比较重，所以开发人员往往会陷入开发工作中，而忽略了随时与客户沟通。因此，需要安排一个专职的需求变更联系人，负 责及时与客户沟通，跟踪和汇报需求变更的进度和情况。同时，可以成立一个项目变更控制小组来决定接受哪些变更。团队由参与项目的许多人组成，包括客户和开发人员的决策者。

　（5 5 ）确认客户是否接受变更的代价

　 让客户意识到变化是有代价的，和客户一起确定需求变化是否还在继续。比如变更没有问题，但要明确客户是否能接

　受由此带来的问题，如进度延迟、成本增加、效率降低等。一般来说，客户如果认为改变是必要的( ( 不是上级提出的) ) ，就会接受这些后果。通过与客户协商，开发团队即使没有回报，也不会招致公司和客户双方的投诉。

　如果客户认为更改是必要的，但可以推迟，双方将签署一份备忘录，留待以后解决。大多数情况下，如果客户认为可有可无，他会取消更改。这可以防止频繁的更改，并使客户意识到并不是所有的需求都需要更改。