在软件开发行业中坚决不能忽视的问题。就是如何面对经常变化的业务需求。客户总是喜欢在软件开发项目进行过程中修改需求或者增加新需求。诚然在软件开发项目一开始的阶段，客户不清楚自己到底需要怎么样一个系统，往往在软件开发项目进行中突然明白或者说清楚自己真正想要个什么样的系统。所以这些在软件开发项目过程中提出来的变化需求也并不是客户在无理取闹，反而对客户来说比在软件开发项目开始阶段那些双方互相确定的需求更加有意义和重要。

变化就意味着风险。我们当然要把这个问题当作软件开发项目中风险的一种来处理。那常规的处理方法也就这么几个。风险的量化，风险的监控什么的。实际上判定一种风险对我们的影响程度究竟有多大的时候，我们往往只需要问自己一个问题就可以：新需求发生或者老需求变化时候，我们是否已经习惯处理这样类似的突发事件?

其实当我们面对一个变化的需求或者新需求时候，可以看看我们是采取上面五种情况里那一种来解决。我认为如果能用前面三种情况解决，基本上我们就可以答应客户去做或者更改需求。如果是后两种，最好还是慎重点为好，特别是最后一种，虽然态度是不错的，但态度有时候并不决定一切。好心办坏事的事情屡见不鲜。

但是就算这样，并不能算结束了。其次我们还要评估一下需要增加或者修改的需求对客户的重要性问题。对于客户那边的业务人员来说，这样一个需求在他们眼里是怎么样的也决定了我们是否答应他们做这个需求。

如果系统中没有这样一个功能，业务人员是否会注意？或者他们会注意到没有这么一个功能但觉得并不影响他们使用系统。又或者是一小部分或者一大部分甚至整个系统都需要依赖这个功能，没有它影响很大？这个也是我们在评估的时候需要考虑到的。

还有一点就是如果我们这个软件开发项目团队没有人会完成或者修改这个需求所需要的技术怎么办？这样一个需求所需要用的技术是否是我们需要一段培训时间才能掌握的？或者有可能我们会，但是掌握的不太熟练，需要用一段时间才能达到熟练水平。当然也有可能我们已经很熟练了。或者对我们来说这完全是小菜一碟。

所以当我们面临这样一个崭新的或者变化的需求，我们要从过去的风险解决经验，对客户业务人员的重要性和技术团队使用技术水平这三方面来评估。

我以前也是经常这么做的，说老实话我觉的还凑合，基本上不会让客户说闲话。而且有时候我们要顶住客户的无理需求时候，拿这三个做理由往往都能让他们无话可说。毕竟我们讲的出道理为什么不答应做这个新需求。