客户协作 over 合同谈判

客户协作 Customer collaboration OVER 合同谈判 contract negotiation

最近有人和我谈起他们的项目管理。他是一个项目经理，负责项目的进度跟踪和与客户的沟通。他能够很好的保持客户关系。他的团队中有一个年轻的程序员，工作充满热情，喜欢思考，喜欢用新技术，也很勇于指出问题。

有一天，这个年轻的程序员在客户处外勤，跟客户交流的时候，讨论到了系统某一块儿的功能。年轻的程序员基于他的工作热情，向客户提出，如果这么这么 做，那可能会给你带来更好的功能。客户听了挺高兴，觉得可行，这小伙说的不错。于是就反映到了项目经理处，说这小伙干的不赖，表扬表扬。这项目经理听到客 户的表扬，也附和的说，他确实很上进，回头我再给他当众表扬一下。

项目经理回到了公司，就把这程序员单独叫来聊了一下，他说，你给客户提建议，这样多思考挺好的，不过，咱们给客户开发，要一单一单的做。你说的那个 功能我早就想到了，但我没提，主要是考虑这个功能实现起来很容易，我们可以放在下一期，我们引导客户一下，让他们提出，我们再把它说的复杂艰巨点，这样咱 们很容易就能完成任务，下一期时间更充裕，而且还能收更多的钱。所以以后有想法咱们内部讨论，先别跟客户说。程序员点头称是。

这样的事情在很多公司都很常见。他们把客户视作敌方阵营，利用自己对IT知识优势了解，努力在一些地方上欺瞒和糊弄客户。

与客户成为敌对的关系，就难免要进行谈判。客户希望用低廉的价格买到他希望的功能，或者说，在一定价格内实现更多的功能。而公司希望提高价格，降低成本。两方表面上达成共识，实际上都在暗地博弈，要在边边角角上沾点小便宜。而这种博弈结果，就是双方都不能达到最好的情况。就像著名的囚徒困境，结局就是纳什均衡(Nash equilibrium)，或非合作均衡。

软件开发的最终目的是要给用户交付价值，要达到客户的商业目标，从而完成公司目标。而为了实现客户和公司的双赢，咨询公司采用了加深客户协作的方式 来达成目标。咨询师会和客户一起工作，了解和认识客户，提出针对性的建议，帮助客户发现和识别业务价值，改进目前的系统。咨询师会站在和客户同一方的阵 营，和客户一起思考、学习和成长。虽然说起来很粗泛，但我所认识的每个咨询师确实都在认认真真的为客户考虑。

另一个会产生非合作均衡现象的是按时收费的单价合同和固定价格固定范围合同的问题。一般PM书籍上都会讲FFP合同对买方的风险比较低，而单价合同对于买方风险可高可低，取决于内容和项目性质。

如果签订固定价格合同，通常的，由于价格固定，客户会倾向于在这个价格内挤入更多的需求，有些人甚至不顾质量而要求更多的特性，反正完成不了都是开 发方的责任。而相对的，开发公司会希望在这里面减少成本，或者是人，或者是需求范围，甚至是不惜牺牲质量。最终两方博弈的结果就是项目出了问题。

这种情况下，更好的办法是单价合同，或者具体说，就是确定阶段时间内的开发力量，但不确定开发范围的收费方式。按照客户需求的优先级来开发，双方合 作，尽最大的努力，频繁交付。这种做法的好处是，客户可以控制项目的长短。可以不停的做下去，也可以立即随时终止。由于双方的协作，开发公司也会按照自己 的能力，尽最大可能来保证质量和进度。另一种改进过的单价合同，是基于开发方对项目的理解和估算，报出一个固定价格。在合作共赢的前提下，双方信任并接受 这个契约。这种情况好像更加适合国内的甲方。

前些天，一个原来的同事电话我，她以前是负责销售的，现在自己开了家公司。她雇佣了一个公司给她开发软件，开发了两个多月了还没见到是什么样子。眼 看就要到交付期限了，她想去看看，就问我应该怎么样去中期查验这软件。我告诉她，要怎么怎么样才能看出这系统到底能不能做完，怎么看出到底做的质量如何等 等。

瞧瞧，怎么样，客户也不是很好糊弄的嘛。你糊弄客户，焉知客户不会另请人来对付你？所以，在商业的博弈中，合作才能双赢。这就是为什么客户协作 over 合同谈判的原因了。