作为项目经理如何和大客户沟通打交道

本文转自：http://www.spasvo.com/news/html/2012108103800.html

我在《如何逃离垃圾客户》的故事4“大客户的诱惑” 里讲述了一个严重失败的合作案例。估计很多想干外包或者想兼职接单的人看完都受不了：“什么客户都可能是垃圾，干项目随时可能遇上各种鬼事，单子还怎么接， 外包还怎么干?”

　　霍炬老师很早以前就教育过我：项目经理需要干的3件事——控制、调配和缓冲。

　　控制：控制客户与突发事件。

　　调配：调配 时间、资源、需求之间的三角关系。

　　缓冲：分解压力，在需求方和工程师之间充当沟通桥梁(这两种人虽然都会说中国话，但在对方听起来基本是两种语言。)

　　如果你不能学会控制客户，处理好甲方和乙方之间的关系，其实任何项目都有可能变成垃圾项目。

　　几个首先的原则：

　　不要忽悠甲方。无论是为了拿下项目还是获得更多预算。这样做好比为了立战功，对朝廷说我有5W雄兵，派我去吧。实际你只有2W人，结果到了战场一看敌军10W人，到时你就歇菜了。

　　如果只能忽悠才能拿下项目，你必须对手里的每一种资源都有完全的控制，且提前准备好有备用措施。比如不能有一部分源码除了王二，你队伍里就没其它人会改，比如得有一个高手(5~10倍效率于普通程序员)能帮你快速扫荡，比如最好有个顾问能于危难之时伸手解救你已深陷某bug数天之久的工程师。

　　把公司对公司 控制为 单人对单人的交流。你派出项目经理(客户专员)，要求甲方派出项目负责人。双方的代表都必须能对沟通结果负责。

　　不要把甲方放在对立面。你为他着想，他才能为你着想。你真诚地对他，他才能真诚地对你。

　　状况1：甲方无法提出详细而确切的需求。也无法提供完备的需求文档。

　　此状况及解决贴士请参见我另一篇Blog：《项目如何开始：怎样和客户一起搞定需求》

　　状况2：要求比稿;

　　经常有客户范儿很大，够充牛逼，在签订正式开发协议前要求你参与比稿：“我们这个项目招标，有几家外包方都联系我们想做，我们也需要考核商定一下，你们先出个方案让我们看下。”

　　应对：我的个人原则是，不接需要比稿的项目。在对等的受法律保护的合作关系之前，要求外包方单方面付出是非常不公平的，这样的客户一般也缺乏对外包合作方的起码尊重。所以项目接下来基本后患无穷。

　　但是很多时候，大规模的项目、部分行业有行业传统，或者官僚机构的项目，比稿再所难免。是否参加比稿就要看你觉得值不值，1要确定自己是不是陪绑的，竞争是否公平。2 要尽量清楚对手的实力。3 这个项目的利润回报是否够高，以足够抵消风险。

　　大部分时候，需要比稿的项目，动机纯正、负责人心里没底、真正为了比较方案挑出好合作方的情况是很少的。大家在中国生活了那么多年，也应该知道招标比稿都是些什么猫腻。很多状况下是已经内定，拿比稿堵别人的嘴;或者集中多份方案拼出一个最终稿来，给他们想给的人做。

　　如果已经决定参加比稿，就得好好做。也分是全本方案还是提纲方案。全本方案的我没遇到过，风险太大。提纲性方案的，有一个招，给客户展示一下你们曾经做过的全本案例，告诉客户你们会在一份真正可用的方案里提供多少多少专业性支持或设计，但全本需要**成本**时间。所以现阶段只能可以提供提纲性方案。 如果你们的全本方案做得够专业，客户心里会有数。

　　状况3：要求提供1份以上的方案(设计)

　　做方案和设计的经常会遇到这种情况，“做2~3稿logo吧。”“出2种颜色的版面吧。”“再提供1个方案吧。”

　　设计者一般会这样想，“logo反正我一般都要设计2~3稿的。”“不就叠加个颜色调整图层，换换颜色嘛。” “不就把方案删删改改嘛。”所以客户的第一次要求总是很容易被满足。

　　但是很快设计师们就发现自己掉进了难言的沼泽：

　　logo挑了一稿又挑了一稿，客户已经挑花了眼，主意越来越多，指挥越来越具体。

　　2个颜色的版面很难被最终确定，于是都被要求被暂时保留，分别先做版面中的其它修改调整，改好了再说。

　　多版本的方案让项目条件越变越多，规划越来越复杂，最后大家心里都没谱了。

　　应对：如果你为客户设计logo，自己做了4个版本，不要把这4个都拿给客户。挑选一个最适合客户需求的。

　　(小贴士：

　　不要挑选你最喜欢的，或是最漂亮的。切记是最符合客户需求的。

　　所以之前要详细征求客户需求，咨询行业背景、业务背景、战略和品牌文化，再加上你的专业判断。

　　如果你前期功课没做好，无论你做几个客户都不会满意的。

　　如果客户无法回答你的问题，拿出一些成功案例，请客户参考挑选后把属性加以组合。

　　如果你是设计师，有一套具有典型性、分类全面、属性差异明显的案例库是非常重要的，可以帮助客户说出他们无法用语言描述的想法。)

       草稿的数量并不会让客户(老板)对你的勤勉印象深刻，反而会觉得分摊到每稿的成本很低。把多个草稿交给客户定夺也是你不够专业的表现，如果需求明确，最适合的永远only one，而你在这个时刻应该运用专业能力选择判断。你把这事交给了你的客户去干，其结果就是客户质疑你的判断和理解需求的能力，从而无形中剥夺掉了你对设计的控制权。剩下的事，你也能想得到了。

　　我见过做logo，给客户提供了3稿，结果客户一下子有主意了，一会加个彩虹，一会做个太阳，最后反反复复做了7、8稿，客户还没满意，活活挑花了眼。

　　而多个配色版本这事，也和上面同理。一个配色就是一个需求 ，不要因为改起来很简单就随便答应。如果走严格的外包流程，多一个配色就是多一份需求，多一份需求就要追加一份费用的。而且做一点微小改动后复制一个版本的要求，最容易出现的后续状况是两个版本会在一段时间内并存，而且两个版本需要同时开发、变更、改bug。这样下来维护成本不是乘2而是乘4。这是程序开发上经常会遇到的大坑之一，技术型项目经理一定要注意。

　　做多个方案这种事就更离谱了。只有在出现不同条件和项目背景的状况下才可能要求做多个方案。一般会遇到的就是分别做低预算、中预算和全预算的方案，或者做3个月能完成项目、半年能完成、全年能完成的方案。

 　　如果你是雇员，一定要强烈提醒你的老板，不同的条件配置不能混用。

　　如果你是外包方，还是要记住，需求对应费用，不要以为这就是是删删改改的数字游戏。

　　状况4：反复改稿;反复纠缠于细节

　　状况：产品端人员经常会遇到客户要求反复改稿，并且十分纠结于细节。

　　比如一个首页改了4、5稿，做了两礼拜还没做好。打翻重做都有2、3回了。 产品A是放在产品B的前面还是后面，产品C是挡住产品B的1/3还是1/2。客户提供的文案或者翻译不停在修动，今天删行字，明天加行字，每次都得改完文件，导出，请对方审核。明明是对方的失误，耽误的确是你的时间，最后你还得为整体项目进度延误付出代价。

　　应对：这种状况首先得由项目经理做好预防。文章开头说过了，调配职责，是调配 时间、资源、需求之间的关系。(资源代表钱和人力)这三者之间是互相钳制的。需求膨胀，就需要更多的资源或时间;想要缩短时间，就得压缩需求或者补充资源;想控制成本，就得压缩需求或同意更长的项目周期。(注意：根据人月定律，人工/单位时间 和 钱是不能绝对换算的。延长开发人员的工作时间也只能让情况更加恶化，项目经理一定要慎重在这两者之间的调配。)

　　1。项目经理再和客户签订预算的时候，就应该尊崇这种换算原则下的 付酬及核算方法。(以后我会专门写blog讨论如何制订预算)以单位人工*时间来计费。这样由于客户原因导致的单位人工工作时间增加，可以得到费用上的合理补偿

　　2。开发协议附件要附上项目时间线，里面明确标清几个阶段的时间里程碑。比如需求完成的里程碑、界面完成的、前端切图的、系统架构的、基础开发的、整合的、内部测试的、bug调试的。如果某个里程碑未按时完成，是由于甲方问题导致的，需要标清责任，并在当时向客户声明可能造成整体项目延误的风险，如果非常严重的甚至可以要求甲方赔偿(因为乙方外包公司的时间一样很值钱。)

　　3。开发协议上要声明甲方对设计稿提出修改意见的轮数，一般是2轮。2轮修改已经意味着最多3稿，什么样的问题基本都能在3稿中改定，什么样的分歧也都能在3稿内统一。超过这个改稿数需要追加费用。这样可以促使甲方全面集中地一批提出修改意见，而不是想到哪说到哪。(我曾经遇到一个客户，一晚上给我发了20封邮件，每封邮件里提1~2条建议，邮件前后还有反复以及 “以此邮件为准之类”的话。MD，后来发展到只要他想起来什么地方要修改就给我打个电话，在第一阶段内测的时候，我曾经在一顿饭中接了他5个电话。)

　　4 。开发协议上要指定几个关键节点的审核确认制。比如首页和全局风格确定了，需要签字确认一次，保证这是最终意见。全部UI设计完了，需要签字确认一次，保证不再修改，不然前端切图的同事就没法干了。