客户需求变更

// Updated on 2009-2-22.加了tag 谁动了我的代码
还在大学的时候就知道IT业的客户经常变更需求，然后随之而来的就是工程师们狂改代码。现在在公司接触到的第一个项目，客户是美国的企业，客户方有两个人，一个管技术，一个管业务。做了一个月，才知道美国人也经常换需求，而且有时候根本不知道自己到底需要什么，管技术的和管业务的互相没有太考虑对方，技术的不太懂业务，所以设计的架构满足不了业务的需求；业务的不懂技术，以为移个按钮改个逻辑就马上可以实现（面向过程语言）。结果就导致需求一变再变，架构也一变再变（-_-!）。私底下我已经开始将其称为变形金刚。

于是乎。。。。。。

while((next电话会议 != null) & (Project != Release)) {
在与变形金刚的电话会议中，我们往往会讨论因为上次的设计带来的issue。然后，变形金刚一般会针对你提成的问题解决你的问题，一般不会考虑对之前的设计带来什么影响，也不考虑future。于是这次电话会议结束之后，回去发现对过去和将来又会造成issue，于是下次的电话会议再问变形金刚怎么解决这些新issue。
}

其实变形金刚无处不在，美国有，中国也有。美国的变形金刚再怎么变，擎天柱可能始终是卡车，而中国的擎天柱就有可能在你不经意之间变成红蜘蛛战斗机。所以我们唯有减少抱怨，分析下遇到这种问题怎么办，因为要为遇到中国的变形金刚做准备。

变形金刚变形一般可能会出现一些特征（我目前遇到的）：
1. 客户方不了解需求。
客户方通常不只一个人，至少有两方，一个技术，一个业务。技术和业务都了解一些对方的工作，但没有仔细了解，也没有时间了解（否则为什么外包），于是技术的把架构设计出来，准确的说是架构大框架，不是所有的架构细节。于是我们提成业务的一个功能该架构不好实现，就开始等客户的feedback。有时候技术业务会在电话里面互相讨论需求到底是什么样。

2. 电话会议不平等。
不是说地位不平等，而是准备不平等。我们电话会议之前都是准备充分了，而客户电话会议前往往没什么准备，所以遇到一个问题会感觉到很突然，于是会临时想或者技术业务客户互相讨论，然后又不好意思让我们在电话那头等很长时间，于是就会在匆忙间做出一个决定，以后错了大不了再发issue，再改。这就是甲方乙方对待事情的态度不一样，这点可以理解，毕竟对方是给钱的。

3. 只解决当前问题。
当你提出一个issue的时候，他们就事论事，不考虑（也没时间）现在的变更对以前和未来会造成什么影响。所以他们的feedback通常会解决那个issue，但是很有可能和以前的rules冲突，也有可能对未来造成大大小小的影响。于是会再出issue，于是直接看上面的while循环。

我目前遇到的主要这3个问题，其实这里面折射更多的问题，就不一一展开。

这3个问题都可以理解，毕竟对方是客户，customer is god。他给钱你就是因为他觉得麻烦，他认为你专业，所以想让你帮他承受麻烦。所以不能对客户要求太高，就像我们不能对上帝要求太高一样，如果他们的责任心做事和我们一样，那他们自己就做了。但是哲学告诉我们事物是互相影响的，生产力可以决定生产关系，生产关系也可以反作用于生产力。客户可以决定项目的工程师们，工程师们也可以反作用于客户。最直接的可以反映这一点的就是，任何需求变更都会带来时间成本，我们的客户恰好是按时间算钱的，所以客户更改需求不但要承受工期带来的延长成本，还有看得见的白花花的美元成本。

所以遇见客户需求的变更，我们也要Change with speed.
1. 技术方面
技术方面是我们最应该主动控制的方面，因为我们就是干这个的。首先架构设计合理，按照软件工程的思路做成可扩展性强可维护性强的软件。Coding方面，尽量使用面向对象OO的观念去编程，封装继承多态。如果你的项目是面向过程，至少可以多用用封装吧。好的编程思想会让你在变形金刚变形的时候坦然处之。

2. 电话会议前的准备。
电话会议前可多做做准备，将以前做过的在脑子里理一遍，最好记住issue所涉及的关键点。这样如果客户“就事论事”在提出issue的时候，可以马上回复告诉他这解决方案与之前提出的rules冲突或者与未来的功能点造成影响。当然这点做到很不容易，因为是电话会议，所以反应以及表达都要快而且扼要。不过要注意，适可而止，不然客户会在你这里感受到强烈的“挫折感”而郁闷之极。

3. 电话会议后的准备
电话会议时按照第二条所说会有些难度，那么可以在电话会议后，将本次电话会议做出的重大决策记录成document，发送给团队成员问有没有重大issue，然后连同issue发送给客户，将本来应该在电话会议时快速反应说出的话而没有说的话连同决策内容一起发过去，邮件为FYI（For your information）级别，主要是让客户Confirm一下，也作为未来如果出现重大issue而block项目进度的时候跟客户谈判的依据。
“你们的进度怎么又拖后了？？”
“不好意思，这是上次根据您要求的变化现在带来的后果（有邮件为证），我们正在积极处理善后工作，不过时间不得不延期，请您理解”

4. Set the right expectation
这是我的Tech-Lead教给我们的，就是设置合理的期望值。有时候客户要改变需求的时候，你要适当的给客户一点"punishment"，比如安排plan时设置一定的时间buffer，一来是给自己降低risk，二来让客户知道每次的变化都是有cost的，而且越到后期cost越大，改动架构cost更大。不要让客户觉得任何改变对你来说都是分分钟的小case，尽管有时候确实如此。否则会让客户养成“乱改需求”的不好的习惯，而且客户在改变的时候考虑得也不会太周全谨慎，反正你可以“分分钟”搞定。
这是一般的情况，紧急情况另当别论。

这是取自于目前项目的体会，但不仅限于这个项目。

下面分享一个真实的小故事，我们的Director以前当Tech-Lead的时候经历的一件事：

当Director带领的团队用java构建客户的某个系统到最后快Release的时候，客户突然有一天对他说：“恩，微软的人找到我们，准备跟我们公司合作一起开创美好的未来，但是有个要求让我们的这个系统采用.Net平台，所以，所以，你们能不能换换？”-_-!

That`s all。

 

本文链接: http://blog.boluotou.com/Developer/2008/11/Requirement_Change/