《软件工程之美》有感–需求变更

常见需求变更解决方案：
1、增强需求变更流程，让需求变更规范起来
简单来说，就是通过严格的流程，来避免一些没有意义的变更，从而达到管理需求变更的目的
2、快速迭代，缩短版本周期
将大的功能拆分，每个版本周期仅实现一部分功能需求，周期较短，这样需求发送变更时，就可以快速响应

但以上方案并不是一成不变的，不同的项目环境也许要采用不同的方案。所以我们要追本溯源，研究问题背后的原因，研究理论背后的来龙去脉。

为什么建筑工程中少有需求变更/strong>

要解决需求变更的问题，你首先要知道，软件开发行业中的需求变更是怎么来的。

拿软件工程和建筑工程进行对比，你可以思考一下，同样是工程，建筑项目也是有需求
变更的，但却不会像软件项目这么频繁和失控。为什么呢/p>

总结一下，这里有两个主要原因:需求的确定性和需求变更的成本。

原因一:需求的确定性

建筑需求是很具象的，而软件工程的需求是抽象的。所以建筑项目里面，无论是提出需求还是变更需求，客户和施工方都明确地知道他们想要什么。

软件需求则经常是抽象、模糊、不精确的，模糊不清的需求导致在软件开发有了雏形后，才慢慢想清楚真正的需求是什么，从而导致需求变更。

举个例子，客户最开始对软件界面的颜色是没有任何要求的，当第一版本的软件给客户看的时候，客户觉得白色背景太难看了，希望换成蓝色的;第二版本换成蓝色后，客户现在已经觉得黄色更好看，希望改成黄色背景;第三版本的时候，产品经理担心客户还想换颜色，就直接做成了换皮肤功能，用户可以自己选择颜色，客户还是不满意，问能不能把背景换成图片…

是不是很熟悉似的事情其实经常发生在我们日常的工作场景里。

原因二:需求变更的成本

建筑项目里面的需求变更，我们都很容易和成本挂钩，因为这些东西已经是生活常识了。而与此相对的是，很多人，包括很多老板都对软件项目需求变更导致的成本增加缺少系统认识。

举个例子，装修房子的时候，如果墙面已经刷成白色了，但是客户想都刷成蓝色，那么他会很清楚，这涉及一系列成本:需要重新购买涂料、需要找人重新粉刷。

但换成一个软件项目，客户想把界面的白色背景换成蓝色的，他会觉得这是很简单也是理所当然的，甚至产品经理也会这么想，他会对程序员这么说:“不就是换个颜色吗行代码的事，客户让换就换了嘛!”

但是实际上，软件项目的需求变更，哪怕是换一个背景颜色，同样是要涉及成本的:需要修改所有涉及背景颜色的代码，需要更新相关测试代码，还需要对涉及的界面重新测试。

你可以说这成本是架构设计水平不到家导致的，但是如果设计时就考虑到要有支持换背景颜色的功能，那么开发的工作量从一开始就上去了，成本同样是提升了。

如何解决需求变更问题/strong>

• 提升需求确定性，把需求分析做好，减少需求变更;
• 提高需求变更的成本，让客户或者产品经理不能太容易就变更需求，这样就可以达到减少需求 变更的目的

但在实施的时候，我们会发现一个问题，假如一味提高需求变更的成本，会让客户满意度下降，也造成了产品经理和开发人员之间的对立，不利于项目协作。

所以我们从另一个角度思考:需求变更之所以让你痛苦不堪，也是因为需求变更让项目成员付出了高昂的代价，例如返工、加班，如果我们可以低成本地响应需求变更，那么一样可以达到管理需求变更的效果。

所以解决方案上可以再加上一条:

• 降低响应需求变更的成本，可以方便快捷地响应需求变更。

• 规范变更流程，提升客户变更成本。

• 用原型设计低成本响应需求变更;做好需求分析和确认，减少需求变更。

• 通过灵活的架构和强大的配置，低成本响应客户需求变更。

来源：鬼布