当客户强烈要求改正这些缺陷时，企业软件开发组织根本不能从中受益。即便客户愿意支付改正缺陷的费用，我们也可能会由于事先没有任何应对措施的原因，以大大超出成本的投入来满足客户的要求。所以，真正站在客户的立场上来考虑软件开发成本，是解决需求问题的最佳方法。这就是上面所说的第一个关键。第二个关键更加具有挑战性。企业软件开发项目的成本绝大部分被用于软件实现。而只有好的实现（灵活性和扩展性），才能降低项目成本。敏捷方法经常抨击过度设计，自己却走向另一个极端。在敏捷方法看来，最理想的情况是正好完成客户的要求，不要过剩的软件设计能力。

这种想法听上去很有道理事实上是行不通的。行不通的理由是，假设你具备过度设计的能力，所谓“不要过剩的软件设计能力”，也许有一定的合理性（前提是你的设计能力已经达到了较高的水准），可是，如果你根本不具备过度设计的能力，所谓“不要过剩的软件设计能力”，就成了糟糕设计的托词了。而大多数的软件开发组织，都不具备过度设计能力。以一个软件开发老手的眼光来看，要求对需求的变化做出预判，这会使某些人关注程序的结构，提升他们的设计能力，最终使企业受益；相反，不考虑需求变化，不管你是否承认，某些人会变成“设计白痴”。他们寄希望于重构，可是往往无力重构，最终只能把责任推到历史的身上。

总而言之，在追求准确表达需求的过程中，企业软件开发组织要克服对需求不断修正的排斥心理。我们要学会站在客户的立场，帮助客户完成设想中的完整故事。我们要在完整故事的基础，去优化和精简软件系统的功能。成本永远不是拒绝解决需求问题的理由。场景故事点评：宗方是保险领域的专家，在一些细节问题上，他的理解是非常敏锐的，例如，由于渠道定义过于灵活，支持佣金调整的工作量会很大。但是，他的需求分析工作存在着两个方面的问题：第一个问题是，他没有考虑客户真正的需要；第二个问题是，他没有尝试去寻找表达需求的方法，这使需求讨论会议变得非常低效。孔如之恰恰相反，他没有保险领域的知识，但是他在思考表达需求的方法。我们会在后面的案例分析中进一步点评。