（商业读书会第八期的题目：A Rush to Failure |HBR）

首先这是一个破除迷思的案例：据说某些特定领域（例如航天、军事、通信）仍然适于用瀑布方法开发软件应用而不适用敏捷方法，据说一个重要的原因是这些领域中软件的可靠性要求是如此之高以至于必须首先做好一切设计然后编码然后进行长时间的测试。但这个案例告诉我们：即使在航天领域，瀑布方法也不工作。

不过再去长篇累牍谈论敏捷已经没什么意思了。越是要求高可靠性，越是不能在生产环境下失败，你就越是需要尽早验证、尽早失败。这是一个如此显而易见的道理，只不过在90年代之前人们没有足够丰富的计算能力将其变成现实。就连航天领域也会追求速度，但速度和质量并不必须是互斥的，“可工作的软件 重于 求全责备的文档”讲的就是这件事。

相比之下，文章末尾处关于合同的对话更有意思。当然这也可以归结为“客户合作 重于 合同谈判”，但在我看来，这更多的是一个社会视角（而非软件开发视角）的问题——我听过客户这样说：“我们会尽力与你们合作，我们的共同目标是履行合同。”这是将企业间的合作完全视为经济活动所带来的必然结果：在项目进展中我会尽力跟你合作，但这并不妨碍我在合同谈判时尽力占你的便宜，因为“合作”被视为个人的态度，而“谈判”才是企业间的关系。

老师讲到另一个客户跟外包商（如果一定要用这个词的话）合作的方式是完全不同的。这个客户在合同谈判时努力讨价还价，然后在敲定价格之前问：“你们确定这个价格能保证足够的利润？你们确定不会难做？”得到肯定的答复后他才放心签合同。他们派人到中国外包商的办公室一起工作，来自两个公司的人融成同一支团队；他们不仅关心进度而且关心外包商的人员培养，乃至帮助建设基础设施和买书。这都是基于一个朴素的道理：找到共赢的方式，然后让上下游企业都变强，那么所有人都会因此而获利。

所以就像德鲁克说的：企业要赚钱，这是不言自明的事；惟其为消费者、为社会做出了什么贡献，才是定义一家企业的方式。构建和维护一个共生共赢的生态系统，清晰自己在其中的定位，帮助生态系统中的其他玩家（甚至竞争对手）共同成长。这样超越经济合作的生态系统将使得“合同谈判”最终成为一项无关紧要的例行程序，因为双方都知道对方会全力以赴而不需合同的约束。