如何逃离垃圾客户（下）

转自: 西乔 项目经理 产品顾问 http://blog.xiqiao.info/2009/04/16/263

 

故事三：朋友介绍的好机会

C：高级程序员，5年代码工作经验。在职，工作清闲，偶尔接点私活。

外地人，在北京漂着，8K月薪税前，偶尔需要加班，有个职业普通的女朋友，买房甭想，打车掂量掂量。宅男，回家了就看看资料看看美剧，长时间持续的代码工作，视力一天不如一天，脖子和腰也经常不舒服。

C经常想，不知道有多少程序员过着像这样的生活，不好不坏，无力改变，也没有理由去改变。

好在他性格温和，人缘很好，经常会有朋友介绍一些私活给他，除了挣点钱，对生活也是一种填充。

C一个挺铁的哥们跳槽到一家传统行业的公司，公司需要开设电子商务的业务，就找到了C帮忙搭个系统，费用也不低，C欣然承应。

客户公司不大，对互联网有一定了解，由市场部门和C沟通接洽。 他们并没有太明确的想法，希望和现行跑的大部分网店差不多就行。C就用开源系统搭个一个，按照客户的要求建了分类，录入了一些测试数据。

客户总是不知道自己要的是什么，但是知道什么是自己要的。

有了可视的DEMO，客户也就有了想法。他们提出要根据自己的业务特色增加预订货物和预定管理的流程。

而此时C还没有和客户签订正式的合同，只明确了开发费用的总数，也没有具体写明任务清单。因为有朋友在这，这家公司做传统行业也有不少年，信誉上问题不大。所以C也比较放心。先花了一两周改造了开源程序的流程。

客户提出界面的风格和品牌形象不太匹配。C找了一堆开源皮肤，让客户挑一个。客户挑了几个分别换上试试。两周又过去了。

客户提出商品的缩略图尺寸不够大，图像质量不够好。C修改了GD库和图片压缩的参数。

客户又提出缩略图列表页 图片有横版有竖版不够整齐。C只好又修改了缩略图截取的程序。

此时已经过去了6周，C开始催促朋友，先把预付结了吧。朋友甚至有点惊讶：“还没把预付给你吗？我赶紧帮你催催。”

客户持续像挤牙膏一样地挤出需求。加个水印啦，添加一种排序关系啦，改下分页啦。 预付还是没有到位，补签合同显然也不太现实，朋友每周都在表示抱歉，表示一定帮忙落实费用，总是有些财务上的预算上的付款期上的理由。

C已经意识到自己已经掉进了一个大坑：项目时间持续流失，客户意见时常反复，需求零敲碎打但都不复杂，总体来看也并没有脱离当初定好的项目框架：利用现成的开源代码搭建一个客户需要的网店系统。可是到现在为止所耗费的工程时间和工作量已经足够自己重写一套了。

爆发的临界点终于到了。客户看了竞争对手的网店，发现了很多新功能，所用的开源系统是同一个，只不过使用了最新的3.0版本。 客户要求也对自己的系统进行升级。

• C性格再好也忍不住了：“我以前专门提醒过：已经对系统进行了那么多的定制化改造，如果升级，所有定制化需求都得全部重新改一遍。使用开源系统如果要升级就不能做太多改造，如果要定制化就得放弃升级！
• 客户：“当初也是你建议我们使用开源系统的.”
• C：“你们又想控制成本，又想节省时间，又不知道自己要什么，需求又总是反复，开源系统是最好的选择了。“
• 客户：“但是你看，现在很多我们需要的功能没有，这个问题总得解决吧……”
• C：“如果这个功能是需要的，在项目开发初期不提出？”
• 客户：“竞争对手有，我们没有，这个就是必需的。”

C十分气愤，客户也很不满，C的朋友夹在中间也非常尴尬。 费用一分钱还没拿到，而项目已经过去了2个半月了。

C对朋友忿忿地说：“唉，这事没法接着干了，我也不让你难做，费用结不下来就算了，以前就当白干了，就当我给你帮忙。”

朋友：“别别别，你这么说我太过意不去了，我再去和他们部门说说，他们啥都不懂，就是一堆草包。我当初给你介绍是好意，总不能到头来还让你吃亏。”

不知道朋友的协调起了作用，还是由于C撒手不干的强硬态度，客户支付了总报酬的50% 。

C看着拿到手里的钱，算算已经用掉的时间，摊到每个月的报酬甚至都没到4位数。

虽然C的态度开始强硬起来，但是对项目本身并没有任何改善。 项目还在像挤牙膏一样继续，棘手的问题依然存在，进度变得更加拖拉，C在看不到头的时间线上 烦恼地进行着无尽的改造……

———-涕泪交加的分隔线———–

1. 由朋友介绍来的项目，如果他并不参与项目并能起到决定性作用，要慎接。不然可能到头来生意和朋友都为难。
   
2. 然后状况下都要明确合同、预付、任务明细。不然你会加速步入沼泽。关系不能代替承诺，约定不能代替协议。轻视游戏规则的代价就是失去规则的保护。
   
3. 如果意识到合作方是垃圾客户，一定要不惜代价，立刻刹车，及时止损，不然你只会付出更多。
   
4. 一般情况下，追加性支付的费用只是在增加你及时止损的代价。不能改善任何问题。
   
5. 在开发项目中千万慎用开源代码，除非确定客户没啥定制化需求。特别要慎用多套开源代码的组合。我亲身经历过客户为了省钱省事，搞 了套dede+ecshop+disciz+WPmu的组合系统然后再改，结果花了大半年时间才最打通组合系统之间的各种关联、调用等。不光耗时和人力成 本超过了重新开发，多次上线跳票也害死了客户的市场与销售。

————————————————————————————————————————————————————————————————

故事四：大客户的诱惑

D: 项目经理 web技术服务外包公司的创始人，创办时间2年，开发团队规模6~7人，业内口碑良好，主要通过朋友推荐获得项目。

做外包项目的公司心头总是有一块软伤：收入来源不够稳定。解决方法当然是找几家长期合作的大客户，承接外围项目或者维护类工程，磨合成本低，价钱公道，合作风险低，作为客户案例拿出去多体面。

大网站、 知名品牌、 外企和政府都是作为大客户的理想人选。

D终于遇到了这么一次好机会，某国际知名品牌的web业务部找到了他。

他心里也很清楚，大客户一般自己的开发团队齐备。能外包出去的一般都是一些比较棘手、担责任、跨平台的活，或者人手不够，没人爱干的独立的外围项目。

D和甲方的相关部门见面谈了谈：D的公司的资质和口碑不错；甲方许诺只要干的好，明年我还有多少多少外包预算……，一拍两合。

合作这事和招聘差不多，首先要解决的是信息不对称的问题，信息渠道问题解决了，只要别太离谱，基本都能成，然后双方各自许诺一番，都怀抱着美好的愿景开始合作，……。

D先给甲方干了一次 跨平台的历史数据迁移的活，不错挺顺利，算是试用期OK。

接下来是为甲方新上线的一个产品系列做一套独立的宣传平台，前端 + cms + 专题。

首先需要打交道的是该产品系列的市场部门负责人，先得把产品端效果图定下来。

对方只提供了一份没有任何详细说明的PPT框架图。D只好反复碰需求，终于弄清楚了对方想做的是什么。D用专业的格式和表述性强的文字重写了规划，附上详细说明，流程图，框架图，任务清单，甘特图，预算清单。请对方负责人邮件确认同意。

程序和产品端开始并行开发了。

产品端部门的遭遇：

首页的UI demo稿发过去，第二天就收到了甲方的反馈邮件，从配色到间距到配图到文案，密密麻麻全是修改意见。

设计师隔天送上了修改好的首页。很快收到甲方的反馈邮件，依然密密麻麻全是修改意见，比如配图不恰当啦，LOGO的摆放位置不对啦，文案需要改字啦。

设计师隔天再次送上修改好的首页。很快收到甲方的反馈邮件，仍然还是修改意见，包括配图需要再更换，文案还是有文字变动啦。

只有等首页完全敲定了，设计师才敢开始第二批次页面的设计。

此后大概每批次页面设计会经过至少3轮的修改，大品牌嘛，总有无数的规范和细节要求，文案和配图斟酌了再斟酌。产品1是放在产品2的前面还是后面，产品3是被产品2挡住1/2还是1/3。
……

demo终于定稿。对方终于满意了。设计稿提交到品牌市场部总监那里。

一个不幸的消息传来~~ 大BOSS认为布局不够好，要求把三栏改为两栏。

D只能在自己办公室里拍着桌子大骂：“靠，原来你TM不是拍板的呀，那天天在那瞎使唤啥呢。”

———————————————

程序部门的遭遇：

程序部分的代码已经完成了，D交给甲方的IT部门，以便合并到对方的整个web系统中。

之前D和甲方的IT部门的接触并不多，他们没提出过什么问题，也没什么意见，就沟通过关于语言版本、数据结构要求等。等到系统一合并，各种各样的问题立刻冒了出来。用户通行证没法处理做、检索索引格式不规范、ID位数不统一 等等。

一个突然冒出来的管数据统计的大哥也发来一堆问题邮件：要求预埋log代码，要求增加统计相关的字段，log格式不规范……

距离约定项目上线剩下的时间不多了，D这时才刚刚被告知了许多应该在项目开始前就应该知会的事。

D在电话里愤怒地向甲方质疑这些问题。

但是看起来没有人该为此而负责任：

• 市场部门说：“我不是给了你IT部门的联系方式吗？你们是搞技术的，你们更应该知道沟通什么”
• IT部门说：“我们不是太清楚你们具体的开发需求什么，不然有些事情会提前提醒你们注意。”
• 数据统计说：“我们一直备有统计方面需求的规范文档，你应该提前联系我们。”

D又在自己办公室里拍着桌子大骂：“我怎么知道数据统计属于IT部门还是属于市场部门！！我怎么知道你们的垃圾编制！！ ”
……

冤归冤，活还是都得干完。D只好紧急组织了加班。

————————-

最冤的事其实还没到来。

产品整合、系统整合都没问题了。东西终于就可以上线了。市场人员已经在测试发布内容了。这时D接到了来自甲方的SA部门（网管）电话，说“安全性上有严重问题！！不解决这些问题，系统是绝对不会允许上线的。 ”

D收到邮件一看，都是些莫名其妙的安全问题。比如CMS系统的登录安全：有很多种解决方案，比如http验证，比如内网限制IP，但对方提出来的显然是最麻烦的一种解决方案。

还有一些安全性措施，从工期和实现根本是不现实的。更有一些完全是不必要的。

D和SA沟通后，对方根本不肯进行任何让步。

D只好和甲方的市场，IT部门进行沟通，声明上线的阻碍。他们显然也没什么办法，只能说尽量斡旋，让D尽量配合。

D尝试改了一些，提出了一些中间方案，都无法得到SA的认同。D很快意识到，自己实际上已经卷入了部门斗争，正在成为牺牲品……

SA还是不肯让步，上线眼看就要延误了，甲方的市场部门也在施加压力，要求提高配合度。

“MLGB，配合个毛，根本就是强人所难！根本就是在找茬！你们之间的鬼事凭什么要我们承担代价，凭什么要我们负责任，我们之前配合度不够高吗？你们大公司整天讲流程，要求流程，这就是你们按流程办出来的垃圾事？”

D一边在办公室里破口大骂，一边写了一份语气强硬的声明邮件，抄送给甲方所有相关负责人，逐条指出了SA邮件中的漏洞和问题，声明合作无法继续，不要尾款，退出项目，同时交付所有开发完毕的源码。

“去你的大公司，去你的外包预算，去你的明年的合作”

很快甲方发来了致歉的邮件。

SA也发来了可以妥协，什么事都好商量的解决方案。

而D，把它们都直接送进了垃圾邮件箱……