对于“软件的价值”，不同的人也会有不同的定义。不过作为付钱购买软件的客户，他对于软件价值的定义是一目了然的：软件能够为他的业务提供多少价值，他能够从使用软件中创造多少价值，这就是软件的价值。
站在很多软件企业的立场上，项目 A 是一个理想的成功项目：按时间、按成本完成预先约定的任务。请注意，我用了“理想的”这个词，稍后我还会解释这个有趣的词，因为实际上的软件项目往往没有那么理想。
而如果换一个角度，站在客户的立场上呢?也许付钱购买软件的客户会有一些不同的想法。项目 B 从开始之后一个月便交付了第一个可工作的版本，从那时起客户就开始使用这个软件的部分功能，并且不断地把自己使用的感受反馈给开发团队。在真实的业务运营过程中，客户甚至发现了一种新的盈利模式，并进行了一次大规模的业务调整，这次调整的结果也直观地体现在软件项目中。虽然项目B的整体交付速率低于项目 A，但它提供的所有功能都是客户真正需要的，它们为客户提供实实在在的价值——更不用说，客户提前好几个月就开始使用这个软件。
1、软件价值源自使用
这正是为什么很多客户青睐“项目 B”的原因——我并不打算声称所有客户都有同样的观点，稍后我也会举出反例，但至少支持这一观点的客户不在少数。因为他们处在一个残酷而快速变化的商业环境中：他们的供应商在变化，他们的客户在变化，他们所处的经济环境和政策环境也在变化。这一切的变化迫使他们的业务也要随之变化。更要命的是，今天这个经济全球化的时代是一个“快鱼吃慢鱼”的时代，客户迫切希望新的软件系统为他们带来竞争优势——哪怕这个软件系统尚未完成，只要能够投入使用。最后，客户对于新的软件系统究竟应该是什么样子并没有百分之百的把握，他们的想法往往要在真正使用软件之后才会浮现成型。几方面的因素加在一起，使得这些客户更愿意尽快开始使用软件、提出反馈、并不断完善软件，而不是提出一组需求、然后坐等几个月之后原封不动地拿到这些功能。
一个真实的案例
在 ThoughtWorks 的一个项目中，开发者们在项目开始之后一个月内就发布了第一个版本——只有一些简单的数据采集功能。在发布展示会上，发生了这样的对话……
开发者：这是我们的第一个功能。我们从文本文件、Excel 数据表和遗留数据库采集数据，现在我们的数据库中有这些数据……(展示数据库结构)
客户：唔……有意思。要是你能做这样一个查询(写出查询要求)，得到的结果可能会有用。
开发者：可是我们的界面上没有地方做这样的查询操作。
客户：啊，我不需要操作界面，只要每天深夜做一次查询，把报表发到我的信箱就可以了。
开发者：这样吗……另一个问题是，这需要花我们几天时间。
客户：不要紧，把别的任务往后放几天好了，我很想看到这份报表。
开发者：那好吧，下周我们就会开始提供这个报表。
猜猜结果怎么样?一周之后客户就开始每天接收这份报表，并根据报表内容做一些分析和决策。仅仅几个月之后，这份报表给客户带来的收益就已经超过了整个项目的投资——这时项目其他部分的开发甚至还没有完成。
想想这个客户会怎么定义一个“成功的软件项目”?好吧，也许这个项目超过了预期的时间，也许投入了更多的人力，但这些并不意味着“项目失败”——只是付出更高的成本。关键在于，他投入的这些成本能够带来多大的收益，他的投资回报率是否划算。对于这个客户而言，如果项目能够随时给他提供可用的、能