如果你特别关注将人的智慧转移为磁盘上的数据，把这作为软件开发团队的中心活动，那么恭喜你，你有了一个正确的观点，可以据此来监控和领导软件开发。大多数软件开发经理或领导者并没有站在全局角度来看待所承担的任务，他们认为自己的工作要么是设计，要么是编码，要么是测试，要么是写文档，要么是营销软件，要么是以某种方式“管理”软件开发过程。
这种误解的常见结果是延误。在软件开发过程中抱有无论什么错误思想，结果几乎总是造成延误。通常延误的时间相当长，远远超过最初的估计日期。是的，这种错误估计往往演变为所谓雾件（vaporware）的滑稽笑柄，如果不是付出了沉重的代价——希望的破灭、金钱和人力的浪费，社会生产力下降等，雾件这个词可以说是很幽默的。
| 如果想要按时交付优秀软件，每个人的大脑都必须融入到项目中。 |
软件开发管理的真正任务是调动尽可能多的智力，将它们投入到产品创建的活动中。智力的形式可以是抽象的人员素质，例如创造力、聪明才智、理性、效率和雅致。智力还具有其他一些非物质的特性，例如适时上市以及满足客户需求。关键是，为了建立知识产权，必须有创造者的智力参与，而这种参与在任何软件开发工作中都是最难完全落实的事情。虽然按时交付软件并不简单，但无论对于个人还是集体来说，这都是一项直截了当的要求。要创造优秀软件则需要富有集体智慧的团队，而且只有他们才能办得到。
假设企业有足够的财力作为后盾，那么剩下的真正至关重要的因素就是团队是否凝聚了集体智慧。本书中的所有概念和经验法则对于善于思考的人们来说都是显而易见的。实际上，这些都是常识。它们大体上只讲了三项当务之急的事情：让人们开始思考、人们应该思考些什么，以及如何让人们更有效地思考。如果读者曾经在富有集体智慧的软件开发团队中工作过，恐怕自己也能总结出不少这样的原则。
那么，问题何在？如果按时交付优秀的软件只是取决于一些常识，又为何如此罕见呢？
考虑一下人类工作的主流模式。在大多数企业中，人们主要把资源投入到两个领域中，一个是智力活动，另一个是常规机械工作。我们可以把这两个领域看做设计和生产，或者工程设计和施工。就目前来看，企业资源（人员和资金）的最大部分通常被投入到机械工作中。汽车、建筑或高速路等工作固然包含智力内容，但工程设计上的投资在总投资中所占比例是微不足道的，尽管这部分投资具有至关重要的意义。
现在思考一下，你会如何组织一家主要从事机械工作的企业？机械工作最大的价值源于效率，因此所有元素的组织都要从效率出发。装配线是20世纪的主要工业流程，亨利·福特作为装配线的“发明者”确立了他的历史地位。装配线在一端进料，在另一端产出有形产品，它的特点是千篇一律，而且单调乏味，但具有极高的效率。装配线的进料和管理采用等级组织方式，企业中的每个人只承担一个很小且狭窄的职责。
软件开发的组织方式就完全不是这么回事了。软件开发的目标产品是知识产权，而不是有形产品，因此机械工作部分所占比例很少。
运营一家生产套装软件的工厂当然并不简单，但可能不比运营一家生产其他稍显复杂的消费品（例如面向大众市场的相机）的工厂更复杂。运营套装软件工厂的真正复杂性无疑来自“主版本”可用性的不确定性，主版本是指已完成的、等待复制的软件。完成智力内容（即已完成的软件）以后，事情的进展就相当顺利了。
软件生产的不确定性和复杂性严重依赖于智力活动。企业的重心要从机械工作领域转移到智力活动剧增的陌生而坎坷的世界，传统的组织结构和习惯无力应对这种转变。
复杂缜密的思想是智力产品的原材料，但大部分商业企业实际上并不鼓励思考。我们必须对企业进行一些重塑，或者用现代商业说法是“改造”它。我们必须找出人们为什么不思考的所有原因，并消除它们，不是开除人，而是清除那些原因。
本书将尝试展现成功软件企业的组织形式，这种形式无法被整齐地拆分为不同的职能单元。进度具有不确定性，产品经理必须掌握管理这种不确定性的种种要点，同样重要的是，开发人员也必须完全理解这些不确定性的重要性。而且，除非每个团队成员都有一个整体远景，否则其贡献必然会局限于仅仅执行经理或“宏程序员”为其分派的任务。这对人员潜力是一种浪费。如果想要按时交付优秀的软件，那么每个人的大脑都必须融入到项目中。让每个人的大脑融入项目并一直保持专注，这是经理的主要职责，也是贯穿本书的主题。