需求总是变化，程序总在修改

当程序员学会编程序之后，开始慢慢地进入项目开发的状况。随着项目开发越来越多，编程也变得熟练起来，程序员渐渐地把学习和工作的重心转移到客户的需求上来。通过与用户进行交流，对用户需求有了由浅入深的感觉，并且越来越感觉到了用户需求和编程之间的密切关系后，如果对需求理解比较深而且理解比较正确，程序编起来就感到特别顺畅，反之，编起来总是担心程序编的对不对。程序员慢慢地就形成了由用户来验证程序正确性的习惯了。即使自己编写的程序很正确，心里还是没有什么信心。

这些仅仅是一个开始，让程序员感到头痛的是，明明上午说好了这样做的需求，到了下午又要改成那样做了。这样编好的程序又要修改或是重写了。这种情况在项目的开发阶段程序员还可以忍受，很多情况下项目到了测试阶段甚至是上线阶段的时候，用户还会提出功能变更的要求。另外，项目投产运行后，用户还会有变更维护的需求。

面对用户需求的不断变更，程序员倍感头痛但也无可奈何，抱怨归抱怨，还是只能按照用户的要求去做。因为用户需求始终掌握着程序员程序的生杀大权。很多软件公司、项目经理、程序员面对不断变化的用户需求，想尽各种办法，希望需求能够稳定下来，需求能够不变。他们想通过用户需求书，通过用户对需求书的确认，通过增加需求变更手续环节和增加需求变更的费用来约束用户对需求的变更。但是，实际收效甚微，很难有不变的用户需求书。用户需求不断改变不是什么个案，而是一个普遍现象。

1.用户需求不断变化是一种客观规律

很多程序员想当然地认为，用户需求是不应该变的。如果这种观念正确的话，那么在现实中，程序员看到过有多少不变的用户需求？可以说，项目越大，用户需求变化的概率就越大。至于很小的程序、不复杂的程序，用户需求不变是有可能的。但是，用户需求变化是很正常的事情。
用户需求不断变更应该是一种规律，它是和企业经营不断发展而导致企业信息化发展相一致的。由于市场竞争和企业发展的需要，企业经营必须随时进行调整和变革，以适应这种变化。而企业信息化则是这些调整和变革的集中反映。例如，2003年中国人民银行提出反洗钱的要求，作为金融机构的银行必须接受央行的监管，就必须开展反洗钱工作，从而导致银行业各种反洗钱系统的开发。如果一个企业的经营方式没有太大的变化，这表明企业发展已经很正常、很健康了，而这种现状一定是原先信息化带来的结果，而当初的信息化一定是在一种不断修正中成熟的，由此也可以想象其用户需求变化之多、之快了；而到目前阶段，企业经营走向正常那就可能不用再进行软件开发了。如果一个企业的经营方式发生了变化，那就必须采用信息化的形式来实现这个变化，而这个变化是一个过程，信息化一定不会等到这个变化完成之后才开始。比如，当初银行有网上银行的设想时，银行不可能一下就能考虑到这种方式的方方面面，它需要走一步看一步，通过前进来修正前进中的问题。所以银行业的网上系统是一个不断完善的过程。我们可以回头看看，当初网上银行是什么样，然后看看现在网上银行是什么样，那就会知道，网上银行业一定是一个不断完善的过程。因此，在企业信息化过程中就会面对用户需求的不断变更。

2.程序员要调整心态面对这些变化

既然用户需求不断变化是一种客观规律，那么程序员在心态上就要进行调整，将用户需求不能变化调整为用户需求一定会变化，树立起“变正常，不变不正常”的观点。有了这样的心态，我们就不会去抱怨用户需求了，就会对用户需求的变更有更多的理解。有时候，我们希望用户需求变更，如果现在不变更将来还是要变更的，而往后变更的代价要比现在变更的代价大得多。举例来说，如果一个用户在系统开发期内提出一个需求变更，程序员就可以在开发期内解决；如果用户在系统上线后提出同样的需求变更，那这个变更可能对其他程序产生重大影响，甚至对现有系统架构产生影响。更有可能发生的是，当初编这段程序的程序员已经离开了，现在又要有一个新人来实现这个需求。可想而知，后一种变更的代价的确太大了。所以，用户提出需求变更对程序员来说不是一件坏事，而是一件好事。

3.程序员要积极主动地面对需求变化

（1）理解用户需求
程序员编写程序时，理解用户的需求很重要。有的程序员凭需求书或自己的想象去理解用户需求，然后就开始编写程序了，编写完之后，经用户检查才发现需求理解错误，程序只好重新修改。这种情况不在少数，推翻原来程序重新编写的事情常有发生。因此，程序员要能正确理解客户需求，少走弯路。我的经验是增加一个验证需求的环节，以避免这种现象的出现。比如，拿到需求书后，可以向项目组的其他程序员讲述自己的理解，听听别人的看法，如果别人不能认同，就有可能说明自己的理解有问题。又比如，我们可以把自己的理解和用户当面进行交流，得到确认后，再去编程。

（2）正确对待需求书
 很多人对用户需求书比较迷信，认为那就是需求的最终版本，不可更改，一切要按需求书来编程。这种一是一、二是二的看法，想法太理想、太天真，可以说这样的程序员还处于“学生气”状态。需求书固然是用户需求的书面表示，是开发项目程序编写的依据，但是，要知道需求书也是人写的，只要是人写的，这个需求书就会反映出作者对业务的理解能力和业务水平以及表达能力。而这些往往和最终理想的用户需求是有偏差的。另外，需求书的编写也是需要时间的，有的需求书写得匆忙，论证不够，不妥之处必定存在。在现实中，用户只是提出一个大概的业务功能要求，具体用户需求书都是由程序员来完成，最后由用户确认。这说明需求书并不一个绝对的东西。在现实中，最终的系统功能与最初的需求书中的功能往往相差很大，最终的系统功能要大大多于需求书的功能。我的意思是，程序员不可迷信需求书，要根据项目的设计目标来分析需求书中的逻辑性。

（3）不要急于编程
程序员一般性格比较急，用户一提出修改，往往马上会按用户的要求去改程序。虽然一般情况下用户要求的时间比较紧，但程序员还是不要急于编程为好。因为用户提出的修改意见不一定全是想得比较周全的。在现实中，程序员刚刚按用户需求改好了，这个时候用户又提出新的要求了，这种现象并不少见。因此，我的建议是，用户提出需求变更以后，要先和其沟通，看看是否真的需要变更，如果真的需要变更，则要和用户交流一下变更后可能出现的各种情况，让用户认可。此时可以建议用户再想一想，再看一看，还有什么要改动的地方。等到用户实在提不出新要求了，再考虑编程。还有一种情况，那就是将用户变更的需求放到一边，等到若干个变更需求都确定的时候，再去编程。这样做的好处在于避免单个需求编程和急促编程带来的重新编程的后果，可以从整体上考虑编程的效果。

（4）用技术应付需求变化
很多情况下，程序员抱怨用户需求变化太快，自己跟不上他们的变化，而且前面的编程工作白费，令人沮丧。但是，程序员是否考虑过用户需求变更一定要更改程序吗？如果回答“是”，那说明程序员的技术水平还有待提高。如果项目一开始就对用户需求分析比较充分，软件架构设计比较合理，功能模块设计比较清晰，那么到了用户提出需求变更时，这种变更也是小范围的和有限度的，大部分可以通过参数化的方式来解决，也可以通过外挂功能的方式来解决。比如，原来用户提出打印两张报表，现在又提出打印3张报表。如果程序员对打印报表有足够经验的话，在开始设计的时候，就已经考虑到报表可能不止两张，已经考虑报表产生可以通过外挂方式来实现主程序的不更改。如果程序员只是一张一张地处理报表，整个程序没有架构，那么增加到的3张表将会使程序很长很乱，如果用户增加到30张、300张那又如何处理呢？所以，我们说，不好的技术可以解决一个需求，而好的技术可以解决一类需求。随着程序员开发经验的增加和技术水平的提高，用户需求变更将不再是一个令人头痛的问题。

（5）向用户提出建议
很多程序员也看到，很多时候用户提出的需求都是粗线条的，考虑并不周全，这就需要程序员根据自己的经验提出合理的建议，让需求完善起来，否则，最终用户还会回到这个建议上。例如，用户要求查询数据，并把查询结果给显示出来。其实有关数据查询和结果处理有很多种方案可供选择。但是，用户当时只会考到到查询和显示这些主要的功能。如果程序员能够和用户进行沟通，建议查询时要有权限控制，显示时可以增加导出为Excel文件等，我想用户是会很欢迎这些建议的。如果程序员不这样做，到后来，用户肯定会提出增加查询权限、增加Excel文件导出功能的。到这个时候再修改程序，肯定不如开始设计的时候就有这些功能省事。为用户着想，也是为自己着想。很多时候，用户是不完美的，程序员也是不完美的，但是，若两者结合，就有可能完美起来。

很多情况下，你不喜欢的东西就可能包含着对你有用的东西。用户需求不断变化，程序不断修改，程序员会感到厌烦和无奈。但是，当程序员静下心来，真正去分析和解决这些问题的时候，程序员可能会发现用户需求背后无限的学习空间；就可能发现用户需求背后的软件价值和市场价值所在；就可能发现自己技术的薄弱之处和改进之处；就可能感觉到技术对解决需求的巨大魅力；就可能感觉到自己的能力和价值所在。程序员通过编写程序走向技术成熟，程序员通过用户需求感受价值获取的市场。当我们不可能要求别人改变的时候，我们只能改变自己以适应别人。