为什么会有评估偏差？

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

2、需求阶段甲方已经考虑到的问题，因乙方对业务的理解不全面，导致乙方评估偏差。

以上两个问题都比较常见，在固定价格合作模式下，遇到这两个问题的任何一个都很难办。在我们经历过的项目里，两个问题经常同时存在。按照固定价格合作模式的逻辑，价格和交付日期都是打包固定的，出了问题只能由乙方承担损失。

乙方在合同签订前也很清楚这些风险，为了规避风险，只能在评估里增加Buffer。尽管如此，需求的沟通在合同签订后，还是变得很困难，双方都小心翼翼。固定价格合作本质上是零和游戏，甲、乙双方都想赢，矛盾和冲突就难以避免。看似省钱的固定价格合作，争执和冲突让实际成本大幅上升。

采用按照实际工作时间收费的合作模式（ODC或T&M），可以解决这个问题。在这种合作模式下，采用敏捷开发模式，代码开发与需求开发（设计）工作同步进行，范围清晰的开发工作一样可以有评估和计划，只是把需求的沟通和设计都放在开发过程里，客户可以紧密参与，与开发团队一同做出更好，更有价值的需求。

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

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

“评估与实际结算的价格偏差”，之所以是个问题，是因为它容易成为合作过程中的暗礁。但如果换成价值最大化的角度，评估与实际结算的偏差并不一定是问题，甚至是个好现象。

实际开发过程中，随着开发的深入，经常会发现更有价值、更好用的需求，甚至有可能完全推翻原需求。问题是只有按照原需求开发，才能保证评估与实际工作时间吻合。新发现的需求就是增加的价值，如果项目价格已经锁死，我们只能把这些“价值”视为“风险”，从而放弃这些需求；现实中我们还经常遇到项目做了一半，才发现原需求要被推翻重做，也不一定是坏事，但在固定价格模式下就难办了。

很多甲方已经验收的项目，实际上却从未上线使用过，一般需求都出现了较大的偏差，这些偏差被发现原本是好事，如果双方不能及时做出改变，就只能制造出一堆没有价值的代码。

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