在本书伊始，我提到过联邦调查局的“哨兵”项目：某家承包商花费了数亿美元，开发的软件却没法用。超支的一大原因是变更需求引起的费用。无论是开发计算机软件、设计飞机，还是修建大楼，几乎所有外包项目都是如此。事实上，很多政府项目的承包商都是先以较低的价格投标，然后通过向政府收取变更需求费用实现赢利的，这已经成为一种商业模式。当承包商签下一个耗时数年的大项目时，会以精美的甘特图列出所有需求，发包单位很难不说：“嗯，这样就行了。”接下来，承包商就会说：“我们答应会做这个，还有那个。如果你们变更需求，我们会额外收费。”这种事后加钱的收费方式是超支的主要原因，以至于各大企业与机构不得不为此专门设置“需求变更控制委员会”。从成本的角度来看，这样做是有道理的。限制变更需求的次数，你就能控制由此产生的成本。

但这些开发人员却没有意识到控制需求变更无异于否定客户的真正需求。他们努力限制成本的同时，也限制了学习、创新及创意。如果你开始执行一个项目后不久便发现真正有价值的功能，也就是能够传递80%价值的那20%的功能，并不在你列出的功能之中，那么，传统的项目管理方法不但会妨碍你变更固有的需求，还会妨碍你以更快的速度创造价值。

此外，严格控制成本的措施根本行不通。即使“需求变更控制委员会”努力控制需求的变更，但很多时候，变更需求的必要性非常大，不变更，项目便不会有任何价值，以至于“需求变更控制委员会”不得不答应，从而增加了项目的成本。类似的需求变更会一而再、再而三地出现，过不了多久，项目经费就会超支数百万美元，而且还会延期一年、两年，甚至五年。

正是由于这个原因，我才提出了“免费变更需求”的观点。在一个标准的固定价格合同中，列出你期望的所有功能，然后专门添加一款关于免费变更需求的条文。比如，如果你要制造一辆坦克车，你需要的功能可能包括：每小时能跑75英里、发射速度能达到每分钟10发、有4个座位、有空调等。你可以把自己觉得有必要的需求都列出来。制造商看过需求描述之后会说：我会把制造引擎算成100点，装填装置算成50点，座位算成5点，诸如此类，由上至下评估。最后，每项功能都会评估出一个固定的点数。根据合同，客户必须与产品负责人密切合作，在每个冲刺阶段中，他们都可以完全变更优先顺序，任何在待办事项清单中的项目或功能都可以移到任何其他地方。至于新发现的功能？没问题，只要从原本可开发的项目中扣除同等点数的功能即可。你们现在想把激光制导系统加进去？好，这个项目相当于50点，那就从待办事项清单中移除一个50点的功能来抵消。

少数公司已经把这种理念运用到了新境界，为客户提供高价值的功能。几年前，我听说过一家采用Scrum方法的软件开发公司的故事，他们取得了一份价值1000万美元的合同，为一家建筑公司编写一款软件。双方约定20个月后交付产品。但Scrum公司在合同中插入了一个条款：如果建筑公司想要在任何时间终止合同，只需支付剩余合同价值的20%。基本上，只要软件公司做出建设公司需要的软件，建筑公司就能要求软件公司不必再继续开发了。

这家软件开发公司把冲刺周期设定为一个月。在第一个月结束后，客户告知开发商新的开发方向，以期创造更多价值。第二个月结束后同样如此。第三个月结束后，客户终止合同，收下软件，并投入使用。他们已经得到自己需要的价值了。

现在来做一点简单的数学计算，看看双方如何获益。在合同刚开始的3个月内，客户支付给这家Scrum公司150万美元。为了提前终止合同，他们还必须额外支付剩余的850万美元中的20%，也就是170万美元。他们总共支付了320万美元，得到的是自己原本认为价值1000万美元的软件，而且还提前17个月拿到了产品。

同时，赢家不只是建筑公司。软件开发公司也是赢家。该公司原本预期的赢利率是15%，但是在前3个月里只花费了130万美元开发软件，却收到了320万美元的报酬，从而使得获利率从15%提高到了60%，提高了3倍。开发人员提前收工，又可以竞标别的项目了。这不仅仅是一门好生意，还是一个能够让人早点退休的策略。

他们之所以能做到这一点，是因为他们采用了Scrum方法。开发团队是多功能团队，能够加快工作速度，以更快的速度传递出更多价值。每一个冲刺阶段结束后，他们都会推出具备新功能的产品。这种产品是可以使用的，而且立即就可以投入使用。在每一个冲刺阶段结束后，产品负责人都能根据顾客反馈的意见重新安排待办事项的优先顺序。只要为客户创造了足够的价值，所有人都可以收工了。通过这种方式，Scrum把所有人的利益凝聚在了一起，包括开发团队成员、Scrum主管、产品负责人、客户以及公司的利益。每个人都会朝着同样的目标而努力。这个目标就是尽快创造出切切实实的价值。我非常推崇互利共赢的做法。我认为，以较低的成本制造较好的产品，并赚到更多的钱，是一桩非常不错的买卖。