也谈随需应变——万变不离其宗

　　需求的频繁变化一直为软件人所诟病，或曰用户不可理喻，或者默默承受，练就一身超强的心理素质，反正用户要什么就做什么好了，实在费劲就走走商务关系把需求推回去算了。因此形成了一个怪现象，在项目初期投标标或者申请项目的时候，开发人员无所不能，什么都能做。

　　用户看到系统以后，发现很多地方跟他们想的不一样，提出各种修改意见，这时开发人员发现模块之间有着千丝万缕的联系，动动这个，就要修改一片东西，动动那个，似乎也修改不了。用户感觉系统并没有在招标时承诺的那样好，甚至有些地方完全没有满足要求，上当的感觉油然而生，拖延着不肯验收。没办法只好祭出镇山法宝——走商务关系。通过与用户处关系让用户觉得不验收都不好意思，再加上当初这也是他的选择啊，多少也要承担一点识人不明的责任吧。哎，认了吧，但在心里暗暗咬牙，奶奶个熊的，下次再也不找你们了。

　　有一个有趣的小例子。

　　话说有两个小村庄，村子里的青年男女经常搞搞对象，没有一起开个Party什么的。但是两个村子之间有一条小河，每次约会都要趟水过去，如果发了洪水，就过不去了，非常不方便，也非常危险。村长本着为人民服务的大无畏精神找到工程队，在河上架一座方便男女约会的桥。

　　事情一说，工程队的人马上就明白了，不就是造一座用来约会的桥么！嗯，这个我是行家，我们队里也有好多青年男女呢！问问他们就知道了，大伙七嘴八舌：约会的桥当然要浪漫一些了，在上面铺上地毯，插满鲜花。嘿嘿，再加上一些休息的凉棚，甚至还有人提出要搞个幸福时光小屋什么的。队长一一采纳，跟村长一说，村长也表示你们非常专业啊，考虑的很周到嘛！OK！研讨通过，马上动手，叮叮当当，用木板钉了一个木桥，架在河上，上面真的是姹紫嫣红，遍地鲜花，休息室、凉棚错落有致，蔚为壮观啊。

　　试运行吧。

　　投入使用不久，问题来了，由于休息室、凉棚太多，路就很窄了。走路的人经常打扰到窃窃私语的鸳鸯们。鸳鸯们感觉不方便，路人也觉得非常尴尬。村长只好找到工程队要求解决这个问题。工程队也没办法啊，还有尾款没结呢。再说也好办，又是一顿叮叮当当，把凉棚的位置调一调，幸福时光小屋弄得小一点，曲曲弯弯的总算有条小路可以走了。

　　又过了一段时间，村里有个胖子找到村长哭诉，因为太胖，幸福时光小屋也就只能装他一个，女朋友只好在外面呆着了。就因为这个原因，都吹了好几个女朋友了。村长一听这哪行，这不好心办坏事了么，找工程队去！工程队一看好吧，单独弄一件大一点的幸福时光小屋好了，单独给你用。叮叮当当……。 按下葫芦浮起了瓢，别人又不干了：凭什么单独给他弄个小屋，每次我们来还要自己找！

　　叮叮当当……。

　　……

　　如此不一而足，折腾了几次之后，木板上都没有下钉子的地方了。终于在工程队员们的耐心即将丧失的时候，一年的维护期也要完成了；尾款呢虽然没有完全结清，但是算起来将巴的也没有赔上；村长在吃了几次酒席，听了工程队长的诉苦之后，也终于不好意思再找工程队的麻烦，大家都松了一口气。就在这个时候，一场洪水冲垮了原本就已经被钉的千疮百孔的桥。

　　从上面的例子可以看出，工程队虽然也做到了随需应变，但是由于他们没有抓住核心需求而导致把工作重点放在了不重要的工作上面，核心功能上面反而没有多少考虑。从而活没少干，钱没赚着，还要承担桥塌了的责任。

　　这样的随需应变要不得！

　　那么怎么样才能随需应变呢？要想拥抱变化，随需应变，就首先要找到不变的东西。俗话说万变不离其宗，找到“宗”之后，即使是“万变”也不会脱离“宗”的约束的。“宗”是什么呢，“宗”是用户的核心要求，是事情的出发点和最终目标。

　　上面的例子当中，村长的需求是为了造一座方便约会的男女通过的桥，那么核心的需求是要做一座桥。不管桥的目的是什么，首先它是一座桥，这才是核心的功能，才是村长的核心目的，才是这件事情的“宗”。基于这个思路，关心桥本身的承重能力，最大车（人）流量，以及抗洪水的能力等等属于桥的一些参数，然后再考虑“万变”，拥抱用户的变化，为了浪漫，可以摆放一些鲜花，铺上地毯；为了美观可以再桥墩或者栏杆上面雕上图案。

　　这样既很好的满足了用户的要求，又为后面的造桥工作积累了经验和技术。当掌握了造桥的基本技能这个“宗”之后，自然就可以针对不同用户的不同要求造公路桥、造铁路桥、造观赏桥等等变化进行“万变”。