远离客户陷阱小故事 转

出处： http://ilovecode.cnblogs.com

做项目做产品可以有3个境界：1 挣钱的，2 做品牌的，3 很酷的。有的人从境界1做到3，有得人从3做到1。
      我是从1做到3，因为有了钱，你才能远离垃圾项目和不专业的客户。
      无论你是单打独斗兼职之余接个小项目，还是已经成立了公司签合同盖大红章接外包项目，初期阶段都遇到过垃圾项目和垃圾客户。你有可能拿到了搭上了无数个不眠之夜，只获得了少的可怜的报酬，受了一肚子气还不落好，客户正和你在心里互相怒骂。也有可能一分钱都没拿到，受骗感和屈辱感正驱使你要去百度贴吧上声讨那个客户公司。更有可能把你的一帮弟兄们一块拉进了一个大坑，你人生中最重要的资源之一正在廉价地流失。
垃圾项目是一个必经阶段：

• 考验你团队是否能同甘共苦肝胆相照
• 磨练你的耐心和自我控制力；
• 让你学习代码规范、架构规划、分工设计、进度设计、质量控制等预防规避机制；
• 帮助你健全任务计划、进度反馈、测试文档、邮件、合同、备忘录等重要文档规范

下一步你要做的就是一看见垃圾项目和垃圾客户，就跑得越远越好！！
下面我来讲一些可能大家都经历过的故事：
故事1 你得尊重我们
      朋友A：一个小建站公司的创始人，优秀的WEBUI设计师，公司正起步阶段。
      A偏重设计，主要接一些公司宣传类型的小站。纯界面类的活，后台拿现成开源的程序那么一套，他做设计又驾轻就熟。遇到一个做少儿智商启蒙培训类的公司做宣传站。一切谈妥，A说把公司LOGO发来吧。客户告之还没设计出来，你就先做吧。
朋友A按照少年儿童花朵般的特征选用了湖蓝和嫩绿的基调配色，这可是2.0流行色，又大方有时髦儿。大大的焦点图，这可是2.0的流行做法，视觉重心稳定，结构分明，有设计感。
      做完客户表示挺满意。下面就该把客户的LOGO和要用焦点图替换上去啦。
      好嘛 LOGO是大红色的旭日升起状，下面写着3字 “红太阳”。
      焦点图客户有指导意见了：5张图对吧，得放我们领导的照片，签名还有题词。
      拿来一看，全是大爷大妈腆着肚子，指点江山的照片。
      朋友A顶着得尊重客户的想法硬给换上了。
      结果就是页面怎么看也不好看了，能好看得了吗。客户不满意了，于是提供指导意见要求改动改动。这一改动完蛋了，越来越别扭。上线日期已经到了，页面正在变得越来越难看，朋友A正在变得越来越悲痛，客户正在变得越来越愤怒。上线前页面勉强丢到了线上。客户很不满意地付了钱，朋友A飞也似地逃走了，一个月后客户的网站另请人完成了页面的改版。朋友A上去看了一眼以后再没勇气看第二眼。他把这个case永远地从客户案例列表中删掉了。
故事2 我们要做成一个伟大的项目
      朋友B：SOHO，一个6~7人规模的web项目开发团队的领头人，项目经理，产品端经验丰富。
      B以为遇到了一个天赐良机，坐在他对面的这个人充满了激情野心与斗志，他健谈，机智，敏锐，富有感染力，他善于规划，他尊重人才，他对互联网每种盈利模式都熟知，他轻描淡写地说着手里拿到的强大资源。B的眼睛也闪闪发光：“关键是这个人器重我，器重我的团队，而且报酬也不错。”
B带领团队已经成功做了几个不大不小的项目，团队成员都不错，都能各挡一面。B的每个项目都签定合同，50%预付，50%尾款，最大程度上保障团队成员的利益。
客户说，你现在起就是我最重要的合作伙伴，我们要做成一个伟大的项目。
他们的合作正式开始了。
      客户已经有了一份详细的项目规划，虽然看起来不太专业和靠谱，不过总比没有强。而且项目本身也不是很复杂，功能模块不多。
      年轻而有活力的团队成员已经开始着手规划系统技术架构和数据库结构，每个人都准备借此机会大干一把，创造出一个鸡冻人心的产品。
      但这个时候B遇到了一点比较郁闷的小挫折，精力旺盛的客户每天都会在很晚的时候上线来和他讨论应该起什么域名，域名一直没有确定，大家也知道现在好的域名太少了。拼音不行不够国际化，带数字的不行不够专业，太长了不行记忆成本太高，生造词不行容易流失新用户，太古板不行不像2.0。
      域名问题折腾了B半个多月，买了许多个备用域名，终于确定了一个。有了域名该起网站名称了，起了网站名称就需要设计LOGO了。在用中文名还是英文名的问题上、LOGO和名片的设计上又折腾了很久。
      科学的分工和任务并行规划并没有让这个小小挫折对整体项目进度造成太大影响。
      但是产品端上的细节问题引发了越来越多的阵地战。比如积分机制，登录框的放置，首页第一屏的取舍之类的啦。客户对他所不了解的技术方面没有质疑，但是在他所有能理解能看见的地方有着极强的控制欲和偏执。
      虽然大部分产品问题，客户最后还是听从了B的专业意见，但产品端迟迟不能定稿以及B作为项目经理角色在拉锯战上花费的精力已经对整体开发进度造成了延误。
产品端终于定稿，项目进入前端和程序的整合阶段，客户的精力转向去谈资源和市场。
      一天，客户要求面谈某个重要的事情：“我新谈下来一批视频的独家资源，是来自***机构，有多么****，谈下来的难度有多****，我觉得放到我们现在的网站上很不错，好处有****，现在网站运营的不足有****，市场开拓难度有****，所以我们现在需要加一个视频频道。”
B开始觉得大事不好：“您想做成什么样的？”
      客户说：“我觉得优酷那样的不错，能做成优酷那样的吗？”
      ……可行性的拉锯战……
      ……实现度拉锯战……
      ……工期的拉锯战……
      ……插入开发计划时间点的拉锯战……
      B擦着汗说：“那费用呢，我们需要增加一点开发费用。”
      客户：“当初你们开价的时候我可一点都没压价，我希望我们能抛开短视以项目为重，我们是准备长期合作的，你是我最重要的合作伙伴，我以后不会亏待你们，我现在的预算计划是****，我的初期投资准备花在*****，已经有人在给我投资****，谈妥后给你们的投入是****  …………。”
B妥协了。
      于是恶梦开始了。
      客户开始不断要求增加新的功能点或频道，以配合他手里掌握的资源和不断拓展的市场需求。
      上线时间延迟；客户对进度持续施加压力；团队成员疲惫、挫败、不满；系统架构严重偏离初期设计，临时性处理和补丁越来越多，进度和质量控制体系全面进入混乱阶段。
      B开始在需求问题上急刹车，对客户强硬。客户不满情绪积累，定下项目上线的deathline。
      正常的BUG调试阶段从最初计划的1个月被压缩到1周。内测版就像一艘四处漏水的大船，团队成员在长期的连续加班中疲惫和抵触，客户看到内测版大发雷霆。
又经历了痛苦的2个月，项目终于上线可用。
残酷的结局：

• B和团队成员经历了痛苦的大半年，付出的工作量远远大于所得到的报酬。
• 客户宣传自己掌握的资源并没有到位，许多功能和频道闲置后又暂时隐藏。
• 客户请来另一个的技术顾问对系统架构大加指责，合作彻底破裂。
• 项目上线后半年不到，客户废弃了这个项目，转向另一个自己感兴趣有资源的领域。
• 精心的付出和最初产品理想的破灭，以及B的数次失误，导致B在这个项目失败后失去了一部分团队成员

 

故事三：朋友介绍的好机会 
      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，把它们都直接送进了垃圾邮件箱……