不能像订购日用品一样来订购软件。你不能够仅仅写下一份关于你想要的软件的描述，然后就让人在固定的时间内以固定的价格去开发它。所有用这种方式来对待软件 项目的尝试都以失败而告终。有时，失败是惨重的。

　　告诉开发团队想要的东西，然后期望开发团队消失一段时间后就能够交付一个满足需要的系统来，这对于公司的 管理者来说是具有诱惑力的。然而，这种操作模式将导致低劣的质量和失败。

　　成功的项目需要有序、频繁的客户反馈。不是依赖于合同或者关于工作的陈述，而是让软件的客户和开发团队密切地在一起工作，并尽量经常地提供反馈。

　　一个指明了需求、进度以及项目成本的合同存在根本上的缺陷。在大多数的情况下，合同中指明的条款远在项目完成之前就变得没有意义。那些为开发团队和客户的协同工作方式提供指导的合同才是最好的合同。

　　我在1994 年为一个大型的、需要多年完 成的、有50 万行代码的项目达成的合同，可以作为一个成功合同的样例。作为开发团队的我们，每个月的报酬相对是比较低的。大部分的报酬要在我们交付了某 些大的功能块后才支付。那些功能块没有在合同中详细地指明。合同中仅仅声称在一个功能块通过了客户的验收测试时才支付该功能块的报酬。那些验收测试的细节 也没有在合同中指明。

　　在这个项目开发期间，我们和客户紧密地在一起工作。几乎每个周五，我们都会把软件提交给客户。到下一周的周一或者周二，客户会给我们 一份关于软件的变更列表。我们会把这些变更放在一起排定优先级，然后把它们安排在随后几周的工作中。客户和我们如此紧密地在一起工作，以至于验收测试根本就不是问题。因为他们周复一周地观察着每个功能块的演进，所以他们知道何时这个功能块能够满足他们的需要。

　　这个项目的需求基本处于一个持续变化的 状态。大的变更是很平常的。在这期间，也会出现整个功能块被减掉，而加进来另外一些功能块。然而，合同和项目都经受住了这些变更，并获得成功。成功的关键 在于和客户之间真诚的协作，并且合同指导了这种协作，而不是试图去规定项目范围的细节和固定成本下的进度。