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

本文转自：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设计完了，需要签字确认一次，保证不再修改，不然前端切图的同事就没法干了。

　　协议这样写：条款*、工程审核及工程验收

　　1. 收到预付款项之后，乙方设计组完成主要页面UI demo的设计开发

　　甲方针对DEMO页面进行审议，提出修改意见。乙方进行DEMO页面的修改，甲再次审议。提出意见，乙方再次修改。甲方需集中在两轮内，全面、统一、明确地提出审议意见。由甲方所提供文案、图片、其它资料变动所带来的修改，乙方可以免费在两轮中提供支持。超出两轮改稿范围的工作，属于维护性工作。请参见《项目维护协议》。或(将不予支持)

　　2 确认UI demo达到要求，甲方需对DEMO页面签字确认修改。

　　签字确认后，进入前端切图环节。甲方如果对页面有其他变动较大的修改要求(更改页面标准色、设计风格、页面布局)，将视为二次设计，乙方可收取二次设计费用。

　　5 。对于甲方提供的文案、图片、资料所带来的麻烦，在协议中提取声明。参见上一段和下一段

　　协议这样写：条款*、甲方责任

　　1. 甲方需对网上内容提出具体要求，若在所规定的时间，甲方不能够及时确认开发设计的内容，所造成的项目进度的延误，乙方不负任何责任。

　　2. 甲方需要为乙方工作人员了解具体业务提供详细的文字、图片等资料。若在所规定的时间，甲方不能够及时提供相关资料内容，所造成的项目进度的延误，乙方不承担责任。

　　有了上述5项预防性措施，你剩下的很多事就好做了。

　　客户反复改稿，反复纠缠于细节，一般不是恶意，大部分都是工作方法和缺乏大局观的问题。

　　所以在客户反复折腾，浪费时间的时候，你得告诉他们得付出什么样的代价，同时你能提供明确的依据和协议的保护

　　约束客户的审核行为。审核行为必须成批次，意见统一、明确、全面。

　　帮助客户建立正确的工作方法。最简单的做法就是提供一个审核意见的模版，让客户按葫芦画瓢地填写。另外一定要教会客户使用截图软件(QQ里的截图就行)，这样可以省许多口舌。审核意见模版下载

　　ppt版本下载 (用于产品端，优势，可放置大面积截图)

　　excel版本下载(用于产品端及 程序、功能测试反馈。优势，条理性强，可过滤排序)

　　客户自己提供的资料变动，一次两次可以帮忙，多了就是维护性工作，得和开发阶段明确分开。

　　还有一个问题，客户很多时候不知道你需要什么资料，或者资料准备不及时。在项目正式开始之前，要按需要的紧急程度，向客户提供 所需资料的清单，然后用不同颜色标清需求紧急程度，分别最晚什么时候要求提供。 这一点很重要，很多资料的缺失将直接影响到你设计和客户需求的匹配。包括logo、标准色、产品图、客户要求放置的大图、客户品牌历史使用的装饰性元素、文案字数等。

 　　12 Comments »

　　项目刚刚开始的时期，项目经理做的主要事情是搜集客户需求，这是一个项目经理非常头疼的阶段，合作的磨合刚刚开始，需求问题上的失误又会导致无穷的后患。

　　三种客户类型：

　　1 的确很专业。能提供基本可用的文档，能给出要求规范，能向你提出有价值的疑问和担心。能快速回答你的问题

　　2 以为自己很专业。 给的文档基本没法用。没法提供规范和标准，喜欢指指点点和挑毛病。只会向你提傻逼问题。基本回答不了你的问题。

　　3 啥都不懂。 不给文档。能给你几个参考范例(打开数个网站，告诉你我要做成和它们一样的。)只能等着你来问100个问题。。。

　　四种合作方式：

　　1 创始人直接和你接洽： 交流结果的协商余地很大，需求不易反复，细节不会被过分追究。更容易统一想法，执行力高，你能对项目和产品产生更大的影响。但往往甲方会过于急进。

　　2 项目代表和你接洽： 这是非常理想的状况了。甲方有一个产品经理或IT经理能作为代表，负责汇总甲方的所有需求和标准和你沟通，他有过与外包方合作的经验，知道危险的环节所在，能承担翻译和桥梁的角色，帮助你阻挡和说服不恰当的需求。能集中地承担责任，也会积极地和你一起规避项目失败的风险。非常lucky!

　　3 专业部门和你接洽： IT部门或技术部门的某个高级别工程师负责和你沟通，你们会比较有共同语言，甚至惺惺相惜。技术方面的合作会很顺利，但是涉及到产品和需求，他们无法帮你挡住来自市场或内容部门的麻烦。合作开始后，很有可能在技术思路上产生分歧;如果在程序部分耽误了太多时间，而产品端被忽视，你有可能受到其它部门及上层的质疑。

　　4 市场部门(内容部门)和你接洽： 最好你先去烧烧香，准备好最坏打算。专业和思考模式的差异会导致你们关心的问题完全不一样。你首要满足了他们关心的地方后，切记留出不少时间来解决那些他们看不见但实际上非常重要的问题。另外你需要做更多的事，写更多的文档，主动和专业部门联系，力争和决策层有沟通。

　　如果你面临了第3和第4种状况，

　　请先熟悉一下甲方的组织机构。例如一般 内容型、媒体、渠道、宣传类项目的开发：

　　需求 和 市场部门 沟通

　　功能 和 内容部门 沟通

　　软硬广告位或专题 等 和 销售部门 沟通(如果是改版类，广告位合同可能提前半年签订，一定要和销售协调好)

　　技术、系统、安全、统计问题等 和IT、网管、数据统计部门 沟通

　　某些问题 需要和 总裁助理、行政 等官僚部门沟通。

　　部分特别的内容 需要和 创意、美工、文案部门 沟通

　　当以后确定需求的时候，如果发现这些部门的人没有参与，请提前与之沟通。

　　第1和第2种状况可跳过上述步骤。

　　八步流程:

　　第一步：听听客户想要什么。

　　以及预计工期和预算(这两件事上一点都不要腼腆，这是关系项目成败最重要的元素)。

　　第二步：提问。

　　1. 项目的目的是什么。(品牌、渠道、流量、广告费、用户数、VC、其它商业模式)

　　2. 甲方的优势和资源是什么。(钱，内容资源，人力大战，传统行业优势)

　　3. 尽量提供可视的参照及借鉴对象 。(应用上有没有可解决的。界面上比较喜欢哪个站点的设计。交互上有没有可参考的对象)

　　4. 其它工程的细节问题。比如(工期上的上下限是什么?是否会需要与现有系统整合、是否需要数据迁移?是否会需要甲方的工程师合作?是否有开发平台的限制?是否有代码规范及标准?最终需要哪些开发文档和源码 )

　　第三步：取得共识。

　　与甲方取得共识非常重要，保证你所理解的那他们所理解是同一个东西。这一步需要你根据掌握的情况列出提纲，画出草图或框架图。有参考对象的，标注上，哪个部分会比较像某某。 然后请甲方确认， 这个框架是他们想要的。

　　第四步：给出工程时间轴。

　　到了这一环节，就需要你的项目经理组织所有团队成员坐下来讨论，先划分功能模块，然后讨论每个功能模块的可行性、难度、花费时间、bug发生率、测试耗时。再讨论一头一尾 系统搭建和系统整合的所需时间。

　　项目经理对工程耗时和可行性完全心里有数后，画出工程的时间轴。包括并行状况，里程碑节点、测试期、缓冲期等(如何画工程时间轴，甘特图，我以后会专门写一篇)。

　　时间轴要实事求是，并且预留好充分的缓冲期(工程师估时*2*110%)。

　　第五步：需求做减法。

　　大部分情况下，时间轴表现的状况都会超出客户的预期。

　　如果客户对工期没有要求，也要提醒客户考虑 项目可行性风险、市场等候成本、市场或战略变化导致的浪费。

　　韩磊有一篇《大褂还是内裤》的blog很形象地描述过这个问题。

　　所以要和甲方一起尽量对需求做减法。把整体需求拆成2~3期，落实只开发最基础和最必要的一期需求。

　　这时签订正式开发协议。不要忘了计算 需求文档和产品方案 的费用。

　　第六步：撰写详细的需求文档。

　　《框架图》下载西乔的模版。可视化表现产品的框架、布局、细节、部分交互。

　　《流程图》》下载西乔的模版。理出产品的逻辑关系。

　　《功能需求文档》》下载西乔的模版。 罗列 功能、应用、交互上细节，分离基础件，作为开发分工和系统及数据构造的 基础文档。

　　第七步：商讨需求文档

　　尽量召集甲方所有相关部门的负责人 一起召开这次会议，商讨需求文档。

　　在阅读到你的需求文档之前，可能甲方的大部分人都对产品没有可视和具象的理解。也从未关注到细节和逻辑关系。所以需要产品经理从全局角度和逻辑线索讲解文档。

　　更可能发生的状况是，没有人坚持看完或仔细看过你写的文档。

　　所以这次会议是一场耐心和体力的考研。 文档作者需要 分别向各个部门指出他们需要关注和拍板的地方，听取他们的建议，将任何变动要求都分类记录。 安抚情绪。解答困惑。控制需求变动。

　　第八步：定稿需求文档

　　分职能(部门)类建立表格文档。将会议协商中所有 分歧性意见和变动意见 都逐条写下。抄送所有相关负责人。并要求他们纠正分歧和确认变动。

　　所有会议中可能被提出但是未出现在此邮件文档中的 意见，不会列入需求文档中。当然允许可以书面反馈补充。

　　根据确认过的反馈回复，修改需求文档。直到需求文档定稿。

　　协商讨论和文档修改可能经过2~3轮。所以需要项目经理提前提醒客户注意，”搜集需求和文档定稿”的时间线里程碑。如果这个阶段耗时过久，会严重延误整个项目进度。要求客户尽量集中地谨慎地提出建议和修改。

　　三种武器：

　　需求问卷：

　　无论是面对专业还是不专业的客户，交流中都有很多没考虑到的遗漏点，这些他们看不到的点往往是最关键的点，也有可能是被客户故意规避掉的点。

　　此时撰写一份需求问卷非常有效。 问卷里提出重要的全局性的问题，需要客户逐条书面回答。

　　某些问题可以提供多个选项答案，及补充区域。

　　某些问题 需要确凿的态度，Yes或NO。

　　不要提出需要客户写一大段表述性文字的问题。 需求问卷精简扼要，有针对性，重要，

　　不要浪费客户的时间，不要把写字的工作量丢给客户。

　　书面确认：

　　书面确认 一方面包括 ：所有讨论结果、建议 和变更 都要有书面文字备查。电话和开会上说说的这些口头表达都没有效应。这一点一开始你就要声明，甚至有必要写在合同里。

　　另一方面包括：你要尽量提供书面的可视化的东西 来让甲方确认。甲方很难完备或是提供适合工程使用的文档。所以千万不要在项目初期的需求文档上省懒。

　　邮件抄送：

　　邮件抄送一种明确职责的方法。对方可能不看你的邮件，但代表你告之过。尽可能地抄送重要邮件给战略层，可以能避免一些重大问题的出现。

　　结语：

　　到此看起来，搜集和确定需求真是一件耗时耗力的工程。

　　其实在理想的工程项目时间分配中，1/3的时间用于确定所有需求和开发文档。 1/2的时间用于测试，解决bug，安全测试、压力测试等。真正用于开发的只应该占1/6。 当然web项目的开发肯定达不到这个理想状况。

　　但是也由此可见需求阶段的重要性和工作量。这一阶段省一分力或有一分遗漏，到了项目后期可能需要十分力来弥补。

　　四 16

　　如何逃离垃圾客户(下)项目管理

　　Tags: 项目管理， 失败案例， 控制客户， 故事

　　20 Comments »

　　《如何逃离垃圾客户(上)》

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

　　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在看不到头的时间线上 烦恼地进行着无尽的改造……

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

　　由朋友介绍来的项目，如果他并不参与项目并能起到决定性作用，要慎接。不然可能到头来生意和朋友都为难。

　　然后状况下都要明确合同、预付、任务明细。不然你会加速步入沼泽。关系不能代替承诺，约定不能代替协议。轻视游戏规则的代价就是失去规则的保护。

　　如果意识到合作方是垃圾客户，一定要不惜代价，立刻刹车，及时止损，不然你只会付出更多。

　　一般情况下，追加性支付的费用只是在增加你及时止损的代价。不能改善任何问题。

　　在开发项目中千万慎用开源代码，除非确定客户没啥定制化需求。特别要慎用多套开源代码的组合。我亲身经历过客户为了省钱省事，搞了套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，把它们都直接送进了垃圾邮件箱……

　　三 19

　　愤怒的用户项目管理

　　Tags: 登录， Flickr， YAHOO， 失败案例

　　16 Comments »

　　我作为用户第一次受到了严重的挫败。

　　我已经很久没有使用flickr了，而且换了机器。今天我想传照片了，得登录。

　　我的用户名一般就是那么2个常用词和2组数字的组合。即使忘记用户名，2*2，一般4次我也就搞定了。

　　我点击flickr上的“登入”，来到了一个看起来和flickr没有任何关系的页面。从url到文字到界面，我想起我在flickr注册时的遭遇，预感坏运气已经盯上我了。

 　　flickr，yahoo，user experience

　　我尝试了一个用户名，提示 ID 或 密碼無效。我只好再试了一个。试完4个，发现没有一个能登录。我怀疑自己是不是使用了另一个密码。于是我换了密码，分别又组合输入了4次。提示界面一成不变： ID 或 密碼無效。 ID 或 密碼無效。 ID 或 密碼無效。 ID 或 密碼無效。

 　　ID 或密碼無效。 請用你全個的 Yahoo! ID 再試一次，並輸入下圖中顯示的文字。

　　我痛恨这个提示，为什么不告诉我是 用户名无效 还是密码不对 呢!!!我怎么知道我在哪出了错。

　　我只得退而求其次，试用yahoo公司提供的找回密码功能。很多网站的密码找回功能都是雷区，找回方法千奇百怪，闲人千万免入呀。

　　登录框下面有一行链接：忘記你的 ID 和密碼? ，点击进入：第一个需要填的就是Yahoo!ID。

　　我忘记了我的ID，但是找回ID的第一步是 向yahoo提供我的ID!!

　　找回ID的第一步是 向yahoo提供我的ID

　　我只好开始新一轮的猜测之旅。被验证码挫败次数不限。

　　终于有一个用户名A让我进入了下一步

　　结果一： 能看明白的童鞋，上帝保佑你们。　　返回上一步，随机概率可得到结果二： 填写备用关联邮箱。(备注：真的是随机概率，我反复试了若干次)

我再次尝试了我的3个常用邮箱后，成功升级进入下一关。

　　下一步：填写生日，国家和邮编。(无截图)

　　3个选项无必选提示，不过我已经很害怕验证码了，还是都填上。

　　邮编我填写了北京市的100000。

　　提交，提示信息不匹配。

　　前两个不可能出错，莫非我填写了我所在街道的邮编?

　　提交：提示信息不匹配。

　　这时我看到了一个若隐若现的AJAX提示，大意是：邮编信息是新的信息字段，可能有些用户没有该信息。

　　这估计是说不填也可以。

　　我空着邮编这一项，再次提交。

　　恶梦来到啦：

　　基于安全考量，这个账户被暂时锁定。

　　账户锁定将在约二十四小时后解除。在这期间，锁定时间将不会在你每次尝试登入时自动重新设定。锁定解锁后，你可以尝试重新取得你的密码。

 　　这下我彻底歇菜了。我甚至开始点击愚昧的密码和安全说明，甚至进入了寻求帮助和使用说明这种毫无用处的傻逼页面。我甚至抄起电话向BF大声控诉了一番: Flickr怎么卖了了这么一家SB的公司!

　　最后的机会了。。我开始在我的历史邮件堆里搜索：“flickr”。 想看看是否能找到发给关联邮箱的邮件。

　　没有~~~

　　最后一搏了，我在历史邮件堆里搜索：”yahoo“。(MD，我居然要靠搜yahoo才能找回我的flickr用户名)

　　我终于在无数的结果邮件里找到关联邮件，在最下方的一行小字链接中找到了我的用户名。。。。。。

　　最令人瞠目结舌的事发生了。用户名正是我第一个尝试的组合，但是后缀是yahoo.cn。

　　而我一直在用***@yahoo.com做登录尝试。

　　没有任何提示。没有任何引导，登录框旁边甚至没有说明输入不同的后缀会导致什么后果，yahoo的全球多个用户库根本不共享数据。

　　作为yahoo的用户一定要记住提供服务商是yahoo.com， yahoo.cn还是yahoo.com.cn。如果你不把后缀记清楚贴在冰箱门上，你就会像我一样倒霉地浪费一个小时，甚至连晚饭都气得不想吃。

　　另外。我成功使用用户名A进入的那个找回密码，也不是我所使用的用户名。我居然还导致另一个无辜用户的帐户被冻结了24小时。。。。

　　yahoo的ucd部门曾经是我非常尊敬的部门。相信每一个做产品的人都受益过他们的文档和框架图。

　　但是一个大公司的官僚和人浮于事，居然使一个拥有全球最大产品研发部门的公司做出了如此令用户愤怒的产品流程，而且这一流程开始于 用户参与交互的起点：登录!!!