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

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

　　什么是需求变更?

　　(1)什么是需求分析?

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

　　需求分析是一个复杂的问题。作为软件开发人员，一定了解软件工程学，而这门科学的第一步就是需求分析。打开任何一本软件工程的书籍，翻看目录就知道需求分析的地位。软件需求分析是整个软件开发最关键的一个输入。和传统的生产企业相比较，软件需求具有模糊性、不确定性、变化性和主观性的特点，它不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的。因此，软件需求是软件项目最难把握的问题。

　　简单的说：需求分析是指理解客户需求，就软件功能与客户达成一致，估计软件风险和评估项目成本代价，最终形成开发计划的一个复杂过程。需求分析主要包括：业务需求、客户需求和功能需求三个部分。业务需求意为客户对产品的目标或者要求，客户需求意为客户在使用产品过程中需要完成的一系列任务，功能需求则指定了产品系统必须提供的功能。

　　(2)什么是需求变更?

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

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

　　需求变更无可避免

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

　　(1)三极世界和需求变更的必然性

　　需求、客户、开发人员是一个三极世界。这三极的沟通是很不容易的。客户向我们滔滔不绝地描述需求，开发者听得头晕脑胀，但又不得不根据这些来理解需求。有的时候我们也会派好几拨人轮番折腾客户，这样客户也晕头转向，巴不得赶快需求调研结束。这样的需求调研像透过布满小水珠的玻璃看世界一样，即使能够看清轮廓，但细节的丢失在所难免。

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

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

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

[1] [2] [3] 下一页