客户协作 OVER 合同谈判

合同：固定价格合同卖方风险最高、成本加成（如按人天费用收费）买方风险最高。较好的一种合同方式是：固定价格＋奖励＋封顶。当实际成本低于固定价格时，乙方除利润外还获得约定比例的节约费用作为奖励，实际成本高于封顶时，乙方负利润。但不论那种合同都是建立在双方认同的估算基础上的。即使是按人天费用的方式做项目，也需要先确定范围，否则就不叫项目。

质量受影响的三要素：时间、成本、范围，其中一个变化了还想要维持预定的质量，那其他两个也得变

项目变更管理的流程、审批的角色应该作为合同的附件

这样乙方更加有动力虚报价格。


现在的情况就是这样的。


需要按人天费用的方式做项目的一个重要原因就是项目范围变化的可能性很大，固定价格合同会给甲乙双方都带来巨大风险。或者说，这种方式的合同的一大优势就是能更好地适应项目范围可能变化的项目。


对固定价格的合同来说这个不是问题。如何确认，追加由于需求变更带来的增加的开发费用才是问题。

1、单纯按人天收费，乙方更加有动力将一天的事情分两天做，甲方的风险那叫一个～大～
2、合同价格是建立在双方接受的估算基础上，估算怎么做？～参考合同附件之SOW
3、一般的项目，招标的过程中商务标会占很大的比例，乙方会漫天要价麽？
4、合同应该是就已知的明确的项目范围来签订的，未来要变，通过变更申请。如果合同是建立在未知的范围上，那么这是一个失败的合同，我不管作为甲方还是乙方都不会去签这样的合同。您说的这种固定价格合同给双方带来巨大的风险，应该是范围不定带来的风险，而在范围变化的情况下，甭管什么类型的合同风险都大。
5、如果有明确说明了变更流程和审批角色，怎会出现您说的问题？一般变更管理委员会是甲乙双方的高层组成，如果甲方要求增加需求，变更管理委员会中的乙方当然可以提出增加相应的费用，否则不批准该变更。

一般情况下，乙方为了提高用户满意度或者为了未来的合作，可能会默许一些小的改动不走变更不增加费用，这个就由项目经理控制了。

看来celine并没有理解Kent Beck为什么说要“拥抱变化”啊。

Internet时代，用户的商业环境会迅速变化，用户的运作模式和流程会变化，用户对软件系统的的理解会不断深入，这些都会导致需求的变化，甚至项目范围的变化。因此并不是说开始一个“范围未知”的项目，而是项目的范围发生变化的可能性会很大。

变化确实会给项目带来很大的风险，但只要这种变化能给用户带来更大的商业价值，那么软件开发团队能做的就是尽量减少风险，而不是拒绝变化。敏捷开发方法就是要减少由于变化带来的风险。传统的软件工程是把变化当成一种例外，应该要尽量减少。而敏捷方法是把变化当成常态。

你看XP强调需求变更管理吗？XP有设置变更管理委员会吗？没有。因为可以说XP整个过程就是在应对变更。其它敏捷方法也差不多。


理论上是这样的。但实际中这方面扯皮的事情多了。最后还是看甲乙方谁更强势。

用最少的人，做最多的事，果然是乙方永恒不变的追求。

甲方的最高目标是用IT系统支撑自己变化的业务，乙方的最高目标是让IT项目成功。IT项目成功的一大保证是稳定的需求，需求永远是项目的第一风险。但是对于很多企业来说，需求稳定带来的项目成功，对于甲方是没有意义的，稳定的需求意味着业务无法支撑，意味着商业利益的损失。
其实甲方商业利益的损失最终也会造成乙方的麻烦，没有甲方会在这种情况下交付剩余的工程款。
现在的IT项目开发已经不再特别强调重造客户的业务流程（或者说重造流程的目的已经变化了，不再强调新流程的稳定性），稳定的业务流程只对项目有意义，对商业是没有意义的。倒不如IT直接把目标和企业利益一致起来。反正目标是一个运动物体，因此计算他的位置就不是一件重要的事情了，重要的锁定他的本质特征。

冰云 写道：

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

===============================

纳什均衡是一个高度简化的理论模型，它的前提条件是博弈双方面临的问题相同或类似，双方对外界的影响能力类似，双方受到的外界约束类似，并且只考虑短期利益的得失。
所以我想纳什均衡不适合甲方乙方签合同这种情况。

1. 甲乙双方的力量并不均衡，国内甲方在项目回款时间上的决定性力量远大于乙方，除非乙方是IBM之类公司。
2. 双 方受到的约束也完全不同。如果乙方被退单，一般来说在业界内的名誉损失远大于实际利益损失，而甲方只是再找另外一个乙方继续做，搞不好还可以利用以前的乙 方遗留的资源。只有少数甲方迫切需要马上上线或必须一次成功的项目（国庆、春节献礼项目比较多），甲方才受到和乙方类似的约束。
3. 甲 乙双方的合作基本上都不会是一锤子买卖，如果很随意就准备坑害对方，那后面的单子就不好做了。就好像囚徒困境里面的囚徒，如果两个囚徒知道对方报复心非常 强，并且已经有以往的类似案例，搞不好几年后出狱就要把出卖他的人砍了，那他们还会不会都招供呢。两个人肯定心里都要考虑一番，是不是值得为了短期内（5 年）不坐牢，冒5年后把命丢了的风险。

纳什均衡倒比较适合一个甲方进行招标，多个乙方进行博弈的情况。此时是多个乙方之间的博弈，而甲方就是囚徒困境里面的警察，负责制定规则。

前一段时间在infoQ上看到的一个敏捷开发的例子《什么是“成功项目”：谈谈软件的价值》，和另一个商业案例《进退两难——一个项目经理的日记》， 感觉敏捷方法论中对“客户”这个关键因素的描述有些太理想，合作肯定是要合作，沟通也要加强，但客户毕竟是客户，在现有商业规则的约束下，谈判的重要性肯 定是不言而喻的。clamp兄说的签多个小合同的方式，但每个合同内还是需要谈判，这种方式似乎就是现在大项目签合同的通行模式了，合同总是一期一期地 签，或者一期一期地执行。这种方式也是软件业向其他行业借鉴的结果。

不知在其他行业是否有甲方乙方密切合作，将合同与谈判的作用弱化的情况。

这是极限编程里说的思想吗？
不反对楼主说的主题，不过那个例子中的项目经理并没做错什么。
即使签了楼主说的合同，也应当先在开发队伍内部讨论这个创意，这个年轻的程序员未必了解他这个创意会造成多大范围的影响。
至于

不管是敌对还是合作关系都是要进行谈判，而且按照楼主的合同方式更要进行谈判，频繁的谈判。

谈判与交流的出发点不同。。。

谈判也不表示出于敌对的心态，合作双方谈判是个很正常的过程。
客户提出加个功能，一"交流"你就同意做了?
你提出要花多少时间，然后一“交流”，客户就接受了？
即使双方关系很好，也一致认同合作而不是敌对，这时候仍然是个谈判的过程。