客户需求变更

// 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。

突然发现

突然发现上个星期没有写博客。
突然发现现在的博客都是周记。
突然发现我现在开始踢足球了。
突然发现我的眼镜开始隐形了。
突然发现时间管理开始奏效了。

上个星期没有写博客。我问自己,难道每个星期非得写博客?为什么?这固然是一个好习惯,记录生活,总结生活。但是转念一想,博客是取自与生活的体验和感悟,所以有体验和感悟的时候写,没有的时候不写。爱咋样咋样吧。

现在的博客都是周记。之前我就不想写成日记或者周记,我想去评论新闻,评论周边的事情,对周边的人事物进行思考,通过博客将自己的观点表达出来,现在回顾以前的日志,都是周记。可能是因为工作的原因,周一周五上班,周六周天休息。上班的时候太充实太丰富,休息没什么事干,于是就把充实的东西写下来。看来以后要写点重点的东西。

我现在开始踢足球了。也许是工作了,也许在室内待多了,也许是周围的人从喜欢打篮球的同学到喜欢踢足球的同事,也许是想在绿茵场释放自己的压力,也许。。。不管也许什么,这个星期终于穿着新球鞋开始了第一次尝试。位置是守门员,因为根本不会踢球,所以只好用手。

我的眼镜开始隐形了。参考上条,因为踢足球的原因所以买隐形。这也是个不错的理由让我开始了另外一种适应。因为有些重要的场合还是隐形好点。

时间管理奏效了。时间管理的概念从上次training中提到过,于是开始执行,发现真的不错。这个星期的体会是可以在coding和Annual Party这两种不同类型的task中处理得比较好了,至少比以前好。

不多说了,再写又变成周记。

技术部的故事2

时间过得真快,刚刚不久前结束了中秋Party,马上群硕武汉Annual Party 2008又要来了。这次我们的CEO Leonard(刘英武)要过来,所以公司早早的做好了准备。

上次中秋节Party的时候,我策划了《技术部的故事》 [详细],反响还不错,于是这期顺势推出《技术部的故事2》,这个周末终于将剧本框架写出来了。只是,这次可能不能直接参与《技术部的故事2》的表演了,因为除了公司保留节目Model show以外,我还要“挑战主持人”,所以要培养下一代演员了。^_^旧的不去,新的不来。

项目方面coding也正式开始了。因为Requirement analysis的关系,我们的Schedule delay了两天。所以星期六早上加了两个小时班,把delay挽回来了。这样下个星期在项目方面可以稍微不那么紧,不过在Annual Party方面的计划和执行要出来了。

CEO Leonard在星期三的时候来到武汉,我有幸被邀请参与了这次的Training。收获最大的是”Management of uncertainty and ambiguilty”,因为现实中我们要对不确定性和模糊性的东西去管理,而不是想一味的避免或者消除它们。我就一直很在意这些uncertainty,在项目中就期望一开始把所有的uncertainty都消除,这样做起来就很少的risk。但在现实中不可能,哪怕一开始都消除了,期间客户改需求一样会出现。所以想把不确定性消除是徒劳而浪费时间的。我们要学会的是当uncertainty出现的时候怎么去快速的handle它,以及避免一些技术risk的出现。

Happy next week!