为什么会有评估偏差？ 　　

　　1.需求中甲乙双方都没有考虑到的问题是在开发阶段发现的，不解决就无法继续开发。 　　

　　2.对于甲方在需求阶段已经考虑的问题，由于乙方对业务的不完全了解，造成乙方的评估偏差。 　　

　　以上两个问题是普遍存在的，在固定价格的合作模式下很难满足其中任何一个。在我们经历过的项目中，经常会同时存在两个问题。按照固定价格合作模式的逻辑，价格和交货期都是包定的，出了问题，乙方只能承担损失。 　　

　　乙方在签署本合同前也清楚这些风险。为了规避风险，它只能在评估中增加缓冲。即便如此，合同签订后需求的沟通也变得非常困难，双方都很谨慎。定价合作本质上是一种零和博弈。甲乙双方都想赢，所以矛盾冲突难以避免。看似省钱的定价合作、纠纷冲突，导致实际成本大幅上升。 　　

　　采用按照实际工作时间收费的合作模式（ODC或TM），可以解决这个问题.在这种合作模式下，采用敏捷开发模式，代码开发和需求开发(设计)工作同步进行。有明确范围的开发工作也可以评估和规划，但是需求的沟通和设计放在开发过程中，让客户密切参与，和开发团队一起做出更好更有价值的需求。 　　

　　按照实际工作时间计费模式，甲方是否承担更大的风险？表面上看可以，但从价值创造的角度来看，在固定价格项目中，甲方需求越完善，乙方创造的价值越少；甲方需求不完善，乙方无法做出准确评估。甲乙双方在平等基础上建立的真正的合作关系，是让软件（外包）开发过程产生最大价值的前提。要建立真正的合作关系，双方就必须拥有一致的目标：交付最有价值的软件。 　　

　　“评估与实际结算的价格偏差”，不一定是坏事 　　

　　“评估价格偏离实际结算”是一个问题，因为在合作过程中很容易成为暗礁。但如果价值最大化，评估与实际结算的偏差不一定是问题，甚至不是好现象。在实际的开发过程中，随着开发的深入，往往会发现更有价值、更有用的需求，甚至可能会彻底推翻原来的需求。问题是，只有按照原来的要求去开发，才能保证评测和实际工作时间吻合。新发现的需求就是附加值。如果工程价格已经被锁定，我们只能把这些“价值”当成“风险”，放弃这些诉求；现实中我们经常会发现，原来的需求在项目进行到一半的时候不得不推翻重做，这不一定是坏事，但是在固定价格模式2下就很难了。甲方验收过的项目，很多都没有实际投入使用过，总体要求偏差很大。这些偏差被发现是一件好事。如果双方不能及时做出改变，只能产生一堆毫无价值的代码。 　　

　　按照实际工作时间收费的服务只有在双方建立起信任的前提下才能开展，而这种紧密的合作关系一旦建立，就可以促使甲乙双方以价值为导向，及时改变需求，做出真正的好软件。 　　

　　本文来自网络，如有侵权联系，立即删除。