客户协作 OVER 合同谈判

刚写的一篇blog: http://blog.nona.name/200703235.html 和徐x约好的命题作文，不过他还没写。

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

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

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

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

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

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

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

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

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

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

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

作为讲道理来说，很不错。
但是要说服客户接受“单价合同”，似乎更加困难。

固定价格合同，客户就有了一个“可以用来博弈的支点”。
如果是单价合同，大家都说不清楚究竟会干多久，花多少钱。

对于有年度预算的企业和政府机构来说，以单价为计算的合同很难签下来的。

完全同意，所以我上面写了一种改进的单价



但这种确实取决与你说的，“大家说不清楚会干多久”直接影响到最终结果。所以，要做的一件事是提高Project Estimate的能力

所谓“均衡”的意思就是谁偏离它谁就会受到惩罚。

事实上对双方最有利的是“长期合作”模式，双方都会为了“可预计的”未来利益而在本期作出让步。所以比较合适的是不要签一个大项目，而是签多个有延续性的小项目，而且要和同一个公司签。


所谓的单价合同在软件开发（包括咨询）领域恰恰是对客户最不利的，因为软件开发的人员质量差别太大，而且对团队要求高。
这种方式只适合客户本身非常有软件开发经验，某种程度上相当于人员外包。

文中提了咨询公司的例子，咨询公司的合同是以单价合同居多的，但是据我所见的咨询公司（以外资为主），其单价实在是高的离谱，做出来的结果也没有真正的体现客户利益，可执行性很差。

分析得很透彻，不过我始终认为这是软件工程学派的理论研究，在实际情况中完全不是这么回事。

其实一个项目对于甲方来说，其实都会有一个期望值，所以一个所谓的"单价合同"对于甲方而言，真正的用处并不是很大，如果你的项目总价超过了他的期望值，那么无论你提供如何优质的软件服务，无论如何挖掘客户价值，都是白搭。这是在中国，很多客户往往都没有形成一种长期的软件建设的概念，你和他说"单价合同"或者SLA都是废话，他们更倾向于乙方是无敌的，能够帮他解决任何问题。

中国市场还有一个特点，就是竞争的恶性循环。我是在一家比较大的外资咨询公司，我们公司出去和别人打单子，完全不能竞争，报出来的价格是别人的2，3倍，你再说你能挖掘最大的客户价值也没有用，价格上的巨大劣势决定了很多外包企业的发展道路是相当困难的，有些小公司，甚至为了拿到一个客户的单子，把价格报到几乎无法想象的地步。

当然我得说，在合同定下来的情况下，我们还是应该恰如其分的做好我们的工作，尽可能帮助客户完成他们的要求。

这个在中国很难做到的，其实敏捷原则中很多涉及到客户方的问题都是很难做的。包括前面庄提到的例子。

仔细分析敏捷方法（或者绝大多数方法学），可以看出主要是针对新开发项目或者定制项目,所谓的项目管理就是讲的这意思。

但是很多情况下，公司会有一个主要产品，几年内会在同一个产品的框架下进行少量的定制，客户提出的需求变更基本上不大，如果按照单价合同去计算，那是不可能的事情。所以一般来说还是按照产品的主要功能定价，但是如果产品销售量比较大，那些这些小需求的变更也是很难控制的。

另外，在这样的情况下，如何保持研发人员的士气以及设法不断提高研发人员的技术能力都是很大的考验。

我们基本上对数量不多的定制大功能，产品升级，新模块开发，和数量相当大，周期非常短的定制开发分开管理。但是要注意的是，公司发展到一定程度，第二种情况才是常态。或者最后把开发的部门分开，成立专门的研究院和开发部，但在开发部内部还是如此。


开发方法学的具体做法在整个软件公司的研发管理中是一个局部的概念，而方法学所代表的思想才是最应该贯穿并应用到整个研发管理去的。

potian说的有道理，仔细考察项目特性和业务特性，是制定开发过程和团队风格的最终原因，套用过程的方式即使在一切均合适的情况下也有可能因为其他的原因而失败。

关于产品化之后的实施和运营后的需求变更，一直是一个比较让人头疼的问题，很多大公司都为此不得不维护大量的版本。potian有什么经验？

你说的”改进的单价“在什么地方？没找到呀。

关于Project Estimate的问题，我觉得之所以需要开口合同，就是因为有很多东西无法在事先估计准确，比如需求，技术难度，开发速度等。而如果能够在项目开发前准确估算出”要干多久，花多少钱“，那么固定价格的合同也没有大问题。

所以要用户接受”开口合同“， 那就要用户接受一个事实，就是无法在项目开始时预知”要干多久，要花多少钱。“ 如果用户无法接受这一点，也就不可能接受开口合同。这和Project Estimate的能力无关。

“要干多久，要花多少钱”很容易确定
只要不确定“要干多少事”就行了
一个典型的测不准

是的，是的。只不过现在很多用户奢望“干多久，花多少钱，干多少事”都能在事先“测准”。当然，这不能怪客户。软件业为了自身的健康发展，应该担负起在这方面教育客户的责任。