本文转自JavaEye的“黑暗浪子”的帖子，原文链接见此如何处理软件项目中发生的需求变化。
看完后觉得有感触，最近负责的一个项目就碰到这种情况，由于对技术风险的初始估计不足，给后期带来了不小的压力。虽然最终顺利完成，但付出的时间和精力比预期的要远远大得多。看了这篇文章后，我意识到我至少范了里面提到的第一点忌讳和第三点忌讳。血的教训啊！以后千万不能在没有仔细评估的情况轻易答应客户的需求变更。
===================================================================
在IT行业中，有一个不能忽视的问题。这个问题就是如何面对那些经常在发生变化的业务需求。做IT项目，客户老是喜欢在项目进行过程中修改需求或者增加新需求。诚然，在项目一开始的阶段，客户不清楚自己到底需要怎么样一个系统，往往在项目进行中突然明白或者说清楚自己真正想要个什么样的系统。所以这些在项目过程中提出来的变化需求也并不是客户在无理取闹，反而对客户来说比在项目开始阶段那些双方互相确定的需求更加有意义和重要。
就我以前的经验和思路，我对这个问题的解决思路基本上是这样的。
首先，变化就意味着风险。我们当然要把这个问题当作项目中风险的一种来处理。那常规的处理方法也就这么几个。风险的量化，风险的监控什么的。实际上判定一种风险对我们的影响程度究竟有多大的时候，我们往往只需要问自己一个问题就可以：新需求发生或者老需求变化时候，我们是否已经习惯处理这样类似的突发事件?我总结了一下，我们以前处理的时候无非也就是这样五种情况。
1． 我们以前解决过，这对我们没什么，很正常的事情。(作战能力强的团队都有资格这么说)
2． 我们没解决过，但公司里其他项目组，产品组好像解决过。有专门的解决方案文档可以查阅。（向公司内部寻找帮助是个好办法，但在中国行不通，我就看见过有人可以解决但就故意不配合你，让你自己解决去，而不给予任何帮助。）
3． 公司里没有这样的解决方案的资料，但是有很多第三方的资源可以利用。（做JAVA的人好像都喜欢，的确我也听说这样一句话：“内事不决问老婆，外事不决问google”）
4． 好像听说过有人解决过，不过记不清楚了。（等于没说，其实就是没办法解决问题）
5． 的确之前没有解决过这样的问题。但可以试一下，可以作点有开创性的工作应该会有成就感。（以积极的态度来看待自己从来没有经历过的工作）
其实当我们面对一个变化的需求或者新需求时候，可以看看我们是采取上面五种情况里那一种来解决。我认为如果能用前面三种情况解决，基本上我们就可以答应客户去做或者更改需求。如果是后两种，最好还是慎重点为好，特别是最后一种，虽然态度是不错的，但态度有时候并不决定一切。好心办坏事的事情屡见不鲜。
但是就算这样，并不能算结束了。其次我们还要评估一下需要增加或者修改的需求对客户的重要性问题。对于客户那边的业务人员来说，这样一个需求在他们眼里是怎么样的也决定了我们是否答应他们做这个需求。
如果系统中没有这样一个功能，业务人员是否会注意？或者他们会注意到没有这么一个功能但觉得并不影响他们使用系统。又或者是一小部分或者一大部分甚至整个系统都需要依赖这个功能，没有它影响很大？这个也是我们在评估的时候需要考虑到的。
还有一点就是如果我们这个项目团队没有人会完成或者修改这个需求所需要的技术怎么办？因为我是做JAVA的，JAVA的东西是在是太多了，就我看见的技术人员，没有一个人是十八般兵器样样皆精的。所以这也是需要考虑的。这样一个需求所需要用的技术是否是我们需要一段培训时间才能掌握的？或者有可能我们会，但是掌握的不太熟练，需要用一段时间才能达到熟练水平。当然也有可能我们已经很熟练了。或者对我们来说这完全是小菜一碟。
所以当我们面临这样一个崭新的或者变化的需求，我们要从过去的风险解决经验，对客户业务人员的重要性和技术团队使用技术水平这三方面来评估。
我以前也是经常这么做的，说老实话我觉的还凑合，基本上不会让客户说闲话。而且有时候我们要顶住客户的无理需求时候，拿这三个做理由往往都能让他们无话可说。毕竟我们讲的出道理为什么不答应做这个新需求。
-------------------------------------------------------------
生活就像打牌，不是要抓一手好牌，而是要尽力打好一手烂牌。
posted on 2009-06-02 09:40
Paul Lin 阅读(341)
评论(0) 编辑 收藏 所属分类:
软件过程与软件方法