客户协作 OVER 合同谈判刚写的一篇blog: http://blog.nona.name/200703235.html 和徐x约好的命题作文，不过
客户协作 OVER 合同谈判
刚写的一篇blog: http://blog.nona.name/200703235.html 和徐x约好的命题作文，不过他还没写。
最近有人和我谈起他们的项目管理。他是一个项目经理，负责项目的进度跟踪和与客户的沟通。他能够很好的保持客户关系。他的团队中有一个年轻的程序员，工作充满热情，喜欢思考，喜欢用新技术，也很勇于指出问题。
有一天，这个年轻的程序员在客户处外勤，跟客户交流的时候，讨论到了系统某一块儿的功能。年轻的程序员基于他的工作热情，向客户提出，如果这么这么 做，那可能会给你带来更好的功能。客户听了挺高兴，觉得可行，这小伙说的不错。于是就反映到了项目经理处，说这小伙干的不赖，表扬表扬。这项目经理听到客 户的表扬，也附和的说，他确实很上进，回头我再给他当众表扬一下。
项目经理回到了公司，就把这程序员单独叫来聊了一下，他说，你给客户提建议，这样多思考挺好的，不过，咱们给客户开发，要一单一单的做。你说的那个 功能我早就想到了，但我没提，主要是考虑这个功能实现起来很容易，我们可以放在下一期，我们引导客户一下，让他们提出，我们再把它说的复杂艰巨点，这样咱 们很容易就能完成任务，下一期时间更充裕，而且还能收更多的钱。所以以后有想法咱们内部讨论，先别跟客户说。程序员点头称是。
这样的事情在很多公司都很常见。他们把客户视作敌方阵营，利用自己对IT知识优势了解，努力在一些地方上欺瞒和糊弄客户。
与客户成为敌对的关系，就难免要进行谈判。客户希望用低廉的价格买到他希望的功能，或者说，在一定价格内实现更多的功能。而公司希望提高价格，降低成本。两方表面上达成共识，实际上都在暗地博弈，要在边边角角上沾点小便宜。而这种博弈结果，就是双方都不能达到最好的情况。就像著名的囚徒困境，结局就是纳什均衡(Nash equilibrium)，或非合作均衡。
软件开发的最终目的是要给用户交付价值，要达到客户的商业目标，从而完成公司目标。而为了实现客户和公司的双赢，咨询公司采用了加深客户协作的方式 来达成目标。咨询师会和客户一起工作，了解和认识客户，提出针对性的建议，帮助客户发现和识别业务价值，改进目前的系统。咨询师会站在和客户同一方的阵 营，和客户一起思考、学习和成长。虽然说起来很粗泛，但我所认识的每个咨询师确实都在认认真真的为客户考虑。
另一个会产生非合作均衡现象的是按时收费的单价合同和固定价格固定范围合同的问题。一般PM书籍上都会讲FFP合同对买方的风险比较低，而单价合同对于买方风险可高可低，取决于内容和项目性质。
如果签订固定价格合同，通常的，由于价格固定，客户会倾向于在这个价格内挤入更多的需求，有些人甚至不顾质量而要求更多的特性，反正完成不了都是开 发方的责任。而相对的，开发公司会希望在这里面减少成本，或者是人，或者是需求范围，甚至是不惜牺牲质量。最终两方博弈的结果就是项目出了问题。
这种情况下，更好的办法是单价合同，或者具体说，就是确定阶段时间内的开发力量，但不确定开发范围的收费方式。按照客户需求的优先级来开发，双方合 作，尽最大的努力，频繁交付。这种做法的好处是，客户可以控制项目的长短。可以不停的做下去，也可以立即随时终止。由于双方的协作，开发公司也会按照自己 的能力，尽最大可能来保证质量和进度。另一种改进过的单价合同，是基于开发方对项目的理解和估算，报出一个固定价格。在合作共赢的前提下，双方信任并接受 这个契约。这种情况好像更加适合国内的甲方。
前些天，一个原来的同事电话我，她以前是负责销售的，现在自己开了家公司。她雇佣了一个公司给她开发软件，开发了两个多月了还没见到是什么样子。眼 看就要到交付期限了，她想去看看，就问我应该怎么样去中期查验这软件。我告诉她，要怎么怎么样才能看出这系统到底能不能做完，怎么看出到底做的质量如何等 等。
瞧瞧，怎么样，客户也不是很好糊弄的嘛。你糊弄客户，焉知客户不会另请人来对付你？所以，在商业的博弈中，合作才能双赢。这就是为什么客户协作 over 合同谈判的原因了。
21 楼 celine 2007-04-02 合同：固定价格合同卖方风险最高、成本加成（如按人天费用收费）买方风险最高。较好的一种合同方式是：固定价格＋奖励＋封顶。当实际成本低于固定价格时，乙方除利润外还获得约定比例的节约费用作为奖励，实际成本高于封顶时，乙方负利润。但不论那种合同都是建立在双方认同的估算基础上的。即使是按人天费用的方式做项目，也需要先确定范围，否则就不叫项目。
质量受影响的三要素：时间、成本、范围，其中一个变化了还想要维持预定的质量，那其他两个也得变
项目变更管理的流程、审批的角色应该作为合同的附件
22 楼 BirdGu 2007-04-02 引用当实际成本低于固定价格时，乙方除利润外还获得约定比例的节约费用作为奖励，
这样乙方更加有动力虚报价格。
引用实际成本高于封顶时，乙方负利润。
现在的情况就是这样的。
引用即使是按人天费用的方式做项目，也需要先确定范围，
需要按人天费用的方式做项目的一个重要原因就是项目范围变化的可能性很大，固定价格合同会给甲乙双方都带来巨大风险。或者说，这种方式的合同的一大优势就是能更好地适应项目范围可能变化的项目。
引用项目变更管理的流程、审批的角色应该作为合同的附件
对固定价格的合同来说这个不是问题。如何确认，追加由于需求变更带来的增加的开发费用才是问题。 23 楼 celine 2007-04-02 BirdGu 写道引用当实际成本低于固定价格时，乙方除利润外还获得约定比例的节约费用作为奖励，
这样乙方更加有动力虚报价格。
引用实际成本高于封顶时，乙方负利润。
现在的情况就是这样的。
引用即使是按人天费用的方式做项目，也需要先确定范围，
需要按人天费用的方式做项目的一个重要原因就是项目范围变化的可能性很大，固定价格合同会给甲乙双方都带来巨大风险。或者说，这种方式的合同的一大优势就是能更好地适应项目范围可能变化的项目。
引用项目变更管理的流程、审批的角色应该作为合同的附件
对固定价格的合同来说这个不是问题。如何确认，追加由于需求变更带来的增加的开发费用才是问题。
1、单纯按人天收费，乙方更加有动力将一天的事情分两天做，甲方的风险那叫一个～大～
2、合同价格是建立在双方接受的估算基础上，估算怎么做？～参考合同附件之SOW
3、一般的项目，招标的过程中商务标会占很大的比例，乙方会漫天要价麽？
4、合同应该是就已知的明确的项目范围来签订的，未来要变，通过变更申请。如果合同是建立在未知的范围上，那么这是一个失败的合同，我不管作为甲方还是乙方都不会去签这样的合同。您说的这种固定价格合同给双方带来巨大的风险，应该是范围不定带来的风险，而在范围变化的情况下，甭管什么类型的合同风险都大。
5、如果有明确说明了变更流程和审批角色，怎会出现您说的问题？一般变更管理委员会是甲乙双方的高层组成，如果甲方要求增加需求，变更管理委员会中的乙方当然可以提出增加相应的费用，否则不批准该变更。
一般情况下，乙方为了提高用户满意度或者为了未来的合作，可能会默许一些小的改动不走变更不增加费用，这个就由项目经理控制了。
24 楼 BirdGu 2007-04-02 看来celine并没有理解Kent Beck为什么说要“拥抱变化”啊。
Internet时代，用户的商业环境会迅速变化，用户的运作模式和流程会变化，用户对软件系统的的理解会不断深入，这些都会导致需求的变化，甚至项目范围的变化。因此并不是说开始一个“范围未知”的项目，而是项目的范围发生变化的可能性会很大。
变化确实会给项目带来很大的风险，但只要这种变化能给用户带来更大的商业价值，那么软件开发团队能做的就是尽量减少风险，而不是拒绝变化。敏捷开发方法就是要减少由于变化带来的风险。传统的软件工程是把变化当成一种例外，应该要尽量减少。而敏捷方法是把变化当成常态。
你看XP强调需求变更管理吗？XP有设置变更管理委员会吗？没有。因为可以说XP整个过程就是在应对变更。其它敏捷方法也差不多。
引用如果有明确说明了变更流程和审批角色，怎会出现您说的问题？一般变更管理委员会是甲乙双方的高层组成，如果甲方要求增加需求，变更管理委员会中的乙方当然可以提出增加相应的费用，否则不批准该变更。
理论上是这样的。但实际中这方面扯皮的事情多了。最后还是看甲乙方谁更强势。
25 楼 yiding_he 2007-04-09 用最少的人，做最多的事，果然是乙方永恒不变的追求。 26 楼 lane_cn 2007-04-10 甲方的最高目标是用IT系统支撑自己变化的业务，乙方的最高目标是让IT项目成功。IT项目成功的一大保证是稳定的需求，需求永远是项目的第一风险。但是对于很多企业来说，需求稳定带来的项目成功，对于甲方是没有意义的，稳定的需求意味着业务无法支撑，意味着商业利益的损失。
其实甲方商业利益的损失最终也会造成乙方的麻烦，没有甲方会在这种情况下交付剩余的工程款。
现在的IT项目开发已经不再特别强调重造客户的业务流程（或者说重造流程的目的已经变化了，不再强调新流程的稳定性），稳定的业务流程只对项目有意义，对商业是没有意义的。倒不如IT直接把目标和企业利益一致起来。反正目标是一个运动物体，因此计算他的位置就不是一件重要的事情了，重要的锁定他的本质特征。 27 楼 snomile 2007-04-27 <br/>
冰云 写道：<br/>
<br/>
与客户成为敌对的关系，就难免要进行谈判。客户希望用低廉的价格买到他希望的功能，或者说，在一定价格内实现更多的功能。而公司希望提高价格，降低成本。两方表面上达成共识，实际上都在暗地<a href='http://bk.baidu.com/view/18930.htm' target='_blank'>博弈</a>，要在边边角角上沾点小便宜。而这种博弈结果，就是双方都不能达到最好的情况。就像著名的<a href='http://bk.baidu.com/view/316629.htm' target='_blank'>囚徒困境</a>，结局就是<a href='http://bk.baidu.com/view/28460.htm' target='_blank'>纳什均衡</a>(Nash equilibrium)，或非合作均衡。<br/>
<br/>
===============================<br/>
<br/>
纳什均衡是一个高度简化的理论模型，它的前提条件是博弈双方面临的问题相同或类似，双方对外界的影响能力类似，双方受到的外界约束类似，并且只考虑短期利益的得失。<br/>
所以我想纳什均衡不适合甲方乙方签合同这种情况。<br/>
<ol>
<li>甲乙双方的力量并不均衡，国内甲方在项目回款时间上的决定性力量远大于乙方，除非乙方是IBM之类公司。</li>
<li>双 方受到的约束也完全不同。如果乙方被退单，一般来说在业界内的名誉损失远大于实际利益损失，而甲方只是再找另外一个乙方继续做，搞不好还可以利用以前的乙 方遗留的资源。只有少数甲方迫切需要马上上线或必须一次成功的项目（国庆、春节献礼项目比较多），甲方才受到和乙方类似的约束。</li>
<li>甲 乙双方的合作基本上都不会是一锤子买卖，如果很随意就准备坑害对方，那后面的单子就不好做了。就好像囚徒困境里面的囚徒，如果两个囚徒知道对方报复心非常 强，并且已经有以往的类似案例，搞不好几年后出狱就要把出卖他的人砍了，那他们还会不会都招供呢。两个人肯定心里都要考虑一番，是不是值得为了短期内（5 年）不坐牢，冒5年后把命丢了的风险。</li>
</ol>
纳什均衡倒比较适合一个甲方进行招标，多个乙方进行博弈的情况。此时是多个乙方之间的博弈，而甲方就是囚徒困境里面的警察，负责制定规则。<br/>
<br/>
前一段时间在infoQ上看到的一个敏捷开发的例子<a href='http://www.infoq.com/cn/articles/Agile-Unleashes-Software-Value'>《什么是“成功项目”：谈谈软件的价值》</a>，和另一个商业案例《<a href='http://blog.csdn.net/zhengyun_ustc/archive/2005/01/18/258246.aspx'>进退两难——一个项目经理的日记</a>》， 感觉敏捷方法论中对“客户”这个关键因素的描述有些太理想，合作肯定是要合作，沟通也要加强，但客户毕竟是客户，在现有商业规则的约束下，谈判的重要性肯 定是不言而喻的。clamp兄说的签多个小合同的方式，但每个合同内还是需要谈判，这种方式似乎就是现在大项目签合同的通行模式了，合同总是一期一期地 签，或者一期一期地执行。这种方式也是软件业向其他行业借鉴的结果。<br/>
<br/>
不知在其他行业是否有甲方乙方密切合作，将合同与谈判的作用弱化的情况。 28 楼 诺铁 2007-04-27 这是极限编程里说的思想吗？
不反对楼主说的主题，不过那个例子中的项目经理并没做错什么。
即使签了楼主说的合同，也应当先在开发队伍内部讨论这个创意，这个年轻的程序员未必了解他这个创意会造成多大范围的影响。
至于
引用
与客户成为敌对的关系，就难免要进行谈判。
不管是敌对还是合作关系都是要进行谈判，而且按照楼主的合同方式更要进行谈判，频繁的谈判。 29 楼 抛出异常的爱 2007-04-27 诺铁 写道这是极限编程里说的思想吗？
不反对楼主说的主题，不过那个例子中的项目经理并没做错什么。
即使签了楼主说的合同，也应当先在开发队伍内部讨论这个创意，这个年轻的程序员未必了解他这个创意会造成多大范围的影响。
至于
引用
与客户成为敌对的关系，就难免要进行谈判。
不管是敌对还是合作关系都是要进行谈判，而且按照楼主的合同方式更要进行谈判，频繁的谈判。谈判与交流的出发点不同。。。 30 楼 诺铁 2007-04-27 谈判也不表示出于敌对的心态，合作双方谈判是个很正常的过程。
客户提出加个功能，一"交流"你就同意做了?
你提出要花多少时间，然后一“交流”，客户就接受了？
即使双方关系很好，也一致认同合作而不是敌对，这时候仍然是个谈判的过程。 31 楼 lsdayy 2007-04-28 作完需求调研后再签合同，可以较好的计算工作量。 32 楼 yangbo9229 2007-04-30 lsdayy 写道作完需求调研后再签合同，可以较好的计算工作量。
需要调研部分应该属于项目周期内的要做的事情,如果没有签合同就做调研,试问这部分的费用应该如何算? 33 楼 nbsp 2007-05-11 yangbo9229 写道lsdayy 写道作完需求调研后再签合同，可以较好的计算工作量。
需要调研部分应该属于项目周期内的要做的事情,如果没有签合同就做调研,试问这部分的费用应该如何算?做个初步需求，确定未来系统的大概边界，什么该做的、什么不该做的，签个开发协议什么的。先小人后君子，我们小公司大体都是这样子的，不知道你们公司现在的开发协议过程是怎么安排的？能不能介绍下。 34 楼 BirdGu 2007-05-11 nbsp 写道yangbo9229 写道lsdayy 写道作完需求调研后再签合同，可以较好的计算工作量。
需要调研部分应该属于项目周期内的要做的事情,如果没有签合同就做调研,试问这部分的费用应该如何算?做个初步需求，确定未来系统的大概边界，什么该做的、什么不该做的，签个开发协议什么的。先小人后君子，我们小公司大体都是这样子的，不知道你们公司现在的开发协议过程是怎么安排的？能不能介绍下。
粗糙的调研，得到的估算结果也一定是粗糙的。 35 楼 laochake 2007-05-11 BirdGu 写道nbsp 写道yangbo9229 写道lsdayy 写道作完需求调研后再签合同，可以较好的计算工作量。
需要调研部分应该属于项目周期内的要做的事情,如果没有签合同就做调研,试问这部分的费用应该如何算?做个初步需求，确定未来系统的大概边界，什么该做的、什么不该做的，签个开发协议什么的。先小人后君子，我们小公司大体都是这样子的，不知道你们公司现在的开发协议过程是怎么安排的？能不能介绍下。
粗糙的调研，得到的估算结果也一定是粗糙的。
我们公司现在就是这样，运气好的话，能大捞一笔，运气差的话赔死你。 36 楼 yangbo9229 2007-05-14 你们这样的计算工作量方式仅仅是建立在经验的基础上,存在的风险很大.
37 楼 nbsp 2007-05-14 yangbo9229 写道你们这样的计算工作量方式仅仅是建立在经验的基础上,存在的风险很大.
有没有更好的办法、更科学的办法来计算工作量，给介绍一下？ 38 楼 clamp 2007-05-14 nbsp 写道yangbo9229 写道你们这样的计算工作量方式仅仅是建立在经验的基础上,存在的风险很大.
有没有更好的办法、更科学的办法来计算工作量，给介绍一下？
http://clamp.iteye.com/category/6077
我的一些思考，供参考。 39 楼 nbsp 2007-05-17 clamp 写道nbsp 写道yangbo9229 写道你们这样的计算工作量方式仅仅是建立在经验的基础上,存在的风险很大.
有没有更好的办法、更科学的办法来计算工作量，给介绍一下？
http://clamp.iteye.com/category/6077
我的一些思考，供参考。
我粗粗看了一些您的观点，但是没有什么感觉（不好意思），我已经把其中一些内容下载了，以后再细细琢磨下。 40 楼 kabbesy 2007-07-26 <font>
<p><font>软件合同也是合同，按计价方式分类，有：固定总价合同，成本加酬金合同，单价合同，计量估价合同。冰云原文主要提到的是1、3。其中“改良的单价合同”看描述，应该还是固定总价。只不过固定的人性化一些，双方合作更亲密些。</font></p>
<p><font>固定总价合同作为最常见的计价方式，是有其合理性的：风险可控，投入可预期。<br/>
成本加酬金合同很不错，但人为因素太高。在中国，人们还只习惯于对产品定价；还不习惯对满意程度的酬金进行定价。<br/>
单价合同非常敏捷，短周期交付，甚至于短周期支付。但这对甲方要求实在太高了，如何有效对各个功能定价并且拿出大把时间来跟着一起敏捷，相信是大部分甲方信息部门做不到的。<br/>
计量估价合同是固定总价合同中的一个改良，它将依据更多的细节目标，对总价进行一个相对精确的预估。相对于那些拍脑袋拍出来或者打单子砍出来的固定总价合同，计量估价貌似先进不少。</font></p>
<p><font>但问题是：我认为，<strong>计价方式并不是这个问题的关键</strong>。</font></p>
<p><font>企业选择控制风险，而不选择追求敏捷带来的利益最大化，是存在其合理性的。对于大部分企业而言，信息化系统本身只是一个支撑系统，而非生产系统。它的收益也多体现在自动计算能力带来的成本降低上，如典型的OA和MIS。这样“只有投入没有产出”的东西，除非有着很好的先期咨询，否则万难将甲方对项目的重视程度提高。企业作为经营实体，最需要的是投资100万，收益200万；而不是投资100万做个系统，再抽调200个员工参加一周的培训，最后在5年内可以给企业节省30万纸张费用，并且将工作效率从现在提高到XX，从而造成300万的潜在盈利。除非XX的提升太明显，否则核算收益率时，5年内员工工作效率的提升，多半摊销不到OA系统上面来。</font></p>
<p><font>要解决合同计价方式，关键还是在咨询阶段让甲方提高对IT项目的重视程度。只有真正重视了，才有机会让客户也敏捷起来。这时候，想选什么计价方式，都好办了。<br/>
</font></p>
</font>
