具体描述
作者简介
弗雷德里克·布鲁克斯（Frederick P. Brooks, Jr.）是北卡罗莱纳大学Kenan-Flagler商学院的计算机科学教授。他曾荣获图灵奖，美国计算机协会（ACM）称赞他“对计算机体系结构、操作系统和软件工程做出了里程碑式的贡献。”
布鲁克斯被认为是IBM 360系统之父，他曾担任360系统的项目经理、360操作系统项目设计阶段的经理。因在这两个项目中的杰出贡献，布鲁克斯和Bob Evans、Erich Bloch在1985年获得美国国家技术奖（National Medal of Technology）。布鲁克斯早期还曾担任IBM公司Stretch和Harvest计算机的体系结构设计师。布鲁克斯创立了北卡罗莱纳大学的计算机科学系，在1964-1984年期间担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。他目前的教学和研究方向是计算机体系结构、分子模型绘图和虚拟环境设计。
UMLChina翻译组的成员汪颖（Adams Wang）翻译了这本《人月神话》。UMLChina是中文世界访问量最大的软件工程网站。译者汪颖毕业于华中理工大学，从事软件开发以及流程改进方面的工作。
目录信息
读后感
Amazing! A book first published in 1975, writing about IT related project management, is still reflecting the truth, the daily happenings nowadays. As you know the computer technology maybe the most rapidly changing one. There are few projects that start...
评分程序员，就像诗人一样，几乎仅仅工作在单纯的思考中。他们运用自己的想象，来建造自己的“城堡”。——这句话我非常喜欢，作为我blog的说明。 用了12个人月看完人月神话，断断续续。这本书的软件开发背景，和现在大部分程序员应用开发的背景大不相同，也和现在快速开发方法工...
评分如果你是技术出身的管理人员，看完了会有这样的感慨。。。丫什么都没说吧。。。:) 所以也没记住什么。。。唯一有些印象的是原版中反对封装，后来事实证明他错了。:)不过作者能坦率的承认也实在值得我们学习。 另外，而对于人月神话这个著名的命题，太理想化了。 很多时候，de...
评分最早看过，也是最喜欢的两本项目管理书籍之一。因为表达出严谨而正统的管理思路，被自己称为正规化项目管理教育经典。对自己影响最大的是书中提到的“外科手术”团队组成原则，团队组成人员的互补以及“民主集中”和“中央集权”的平衡把握，成为自己不断探索的目标！
用户评价
这部作品，在我看来，是为软件工程领域注入的一股清流，它不沉溺于技术的细节，却直指项目成功的核心驱动力——组织和管理。我尤其欣赏书中对于“测量”的探讨，以及如何避免过度依赖那些看似客观却可能具有误导性的指标。作者深刻地剖析了“有多少软件项目会成功？”这个问题，并将其归结于一系列根本性的挑战。读到这里，我仿佛看到了自己过往项目中的影子，那些看似小小的疏忽，最终是如何演变成巨大的隐患。《The Mythical Man-Month》让我开始重新审视“成功”的定义，它不只是功能上线，更是项目的可持续性、团队的健康度以及最终为用户带来的价值。书中对于“团队协作”的论述，更是让我对“大团队”的运作模式有了全新的认识。那种“人越多越好”的简单思维，在书中被无情地戳破。它让我明白，真正高效的团队，并非规模的庞大，而是成员之间的默契、沟通的顺畅以及目标的一致。这本书的语言风格，也让我觉得非常舒服，它没有枯燥的术语，也没有空洞的理论，而是用一种娓娓道来的方式，将深刻的道理传递给读者。
评分这本书带给我的震撼，远不止于理论的探讨，更在于它对现实世界复杂性的深刻洞察。我特别欣赏作者对于“系统概念”的强调，以及如何通过清晰的文档和抽象层次来应对日益增长的复杂性。在我的工作经验中，很多项目最终的失败，并非技术上的不可逾越，而是因为系统设计得过于臃肿，缺乏有效的分解和管理，最终导致团队成员难以理解和维护。作者在书中反复提及的“概念完整性”，成为了我后来思考系统架构时的重要指导原则。它促使我去思考，一个优秀的产品，不仅仅是功能的堆砌，更应该有一个统一、清晰、并且能够被团队成员共同理解的核心思想。同时，书中关于“动态”和“静态”的区分，也让我对软件生命周期有了更深刻的认识。那些看似微小的决策，在项目后期可能会引发雪球效应，导致巨大的代价。这种前瞻性的视角，是很多年轻的开发者，甚至是一些经验丰富的管理者，都容易忽略的。这本书让我明白，优秀的项目管理，不仅需要解决当下遇到的问题，更需要预见未来可能出现的挑战，并且提前做好准备。《The Mythical Man-Month》就像一本软件开发的“孙子兵法”，它教导我们如何在复杂的战场上，用智慧和策略取得胜利。
评分说实话，在翻开《The Mythical Man-Month》之前，我对于“人月”这个概念的理解，一直停留在字面意思。但读完之后，我才真正理解了这个看似简单的度量单位背后隐藏的巨大陷阱。作者用极其犀利和幽默的笔触，揭示了“人月神话”是如何误导了无数的项目管理者，导致他们低估了项目复杂性，并且错误的认为增加人力就能缩短开发周期。这让我回想起过去一些项目，在遇到延期时，领导层总是习惯性地增加人手，结果却导致沟通成本激增，团队效率不升反降，最后陷入更深的泥潭。这本书的价值在于，它不仅指出了问题，更重要的是，它提供了解决问题的思考框架。它让我认识到，项目管理并非简单的数学加减法，而是需要对团队动力学、沟通效率以及任务分解有深入的理解。书中关于“文档”的重要性，也让我对以往轻视文档的陋习深感愧疚。清晰、准确的文档，不仅是知识传递的桥梁，更是保证项目生命周期中，不同阶段、不同成员之间能够顺畅协作的基础。这本书真正做到了“授人以鱼不如授人以渔”，它提供的是一种思维方式，一种解决问题的能力。
评分《The Mythical Man-Month》这本书，在我阅读过程中，不断激发着我进行自我反思。那些关于“进度”与“产量”之间关系的论述，让我对过往的一些项目管理方式产生了深刻的怀疑。作者通过对“人月”这个单位的解构，揭示了一个普遍存在的误区：即认为增加人力就能等比例地缩短开发周期。这让我回忆起许多项目中，面对延期时，团队成员们如何在加倍的工作量和日益增长的沟通压力下疲于奔命，却依然无法按时交付。这本书不仅指出了问题的所在，更重要的是，它提供了一个更深刻的视角来理解软件开发的复杂性。我特别欣赏书中对“系统概念”和“概念完整性”的强调。它让我意识到，一个优秀的产品，不仅仅是功能的堆砌，更应该有一个清晰、统一、并且能够被团队成员共同理解的核心设计理念。这种理念的缺失，往往是导致项目后期出现混乱和难以维护的根源。《The Mythical Man-Month》让我明白，真正优秀的软件开发，需要的不仅仅是技术实力，更是一种对复杂性的敬畏，一种对组织和管理的深刻理解，以及一种对人性的洞察。它是一本值得反复品读，并从中汲取智慧的经典之作。
评分初读《The Mythical Man-Month》，我最大的感受便是它如同一位经验丰富的老友，在软件开发这个充满挑战的领域，娓娓道来那些令人醍醐灌顶的经验与教训。书中的每一个论点，都仿佛是无数个项目的血泪史凝结而成，触及了项目管理中最核心、最容易被忽视的环节。我尤其对“外科手术团队”的概念印象深刻，它打破了传统线性流水线式的思维，强调小而精的团队协作，以及明确的职责划分。这种模式，在我过往的开发经历中，是多么希望能够早点接触到！书中对于“沟通开销”的论述，更是直击要害，那些因为信息不对称、沟通不畅而导致的延误和返工，简直是每一个开发者都深有体会却又常常束手无策的难题。作者通过形象的比喻和生动的案例，将这些抽象的概念变得触手可及，让我仿佛亲身经历了一场场项目中的风雨。它不是一本教你“如何写代码”的书，但它教会你“如何更好地组织和管理写代码的人”，这才是真正决定项目成败的关键。读完这本书，我感觉自己对于软件工程的理解，上升到了一个全新的维度，那些曾经困扰我的迷雾，似乎都在这本书的指引下渐渐散去。它让我意识到，技术固然重要，但人性、组织和管理，同样是构建成功的软件不可或缺的基石。
评分把counter-intuitive的道理（The Tar Pit）讲得令人信服确实很厉害。但是具体到例子和执行上我就想说70年到的software engineering和现在的真的不是一回事了。
评分观察细致，分析准确。虽然现代的解决方法已经变化很大了，但问题并没有消失。
评分注重市场，注重专业，注重效率，注重钱刺激。要想搞好大陆的食品安全，and要想搞好翡翠湾，四个注重，不二法门。什么CSA等等等，说白了，丫们都是四个注重的局部异形罢了。鸟儿最恨人家忽悠！不忽悠能死啊？或曰：三千里浮花开在静谧如深海的肉身；落花里面的开花之轻，之痛；在玉的深处如瓷器般易碎。
评分注重市场，注重专业，注重效率，注重钱刺激。要想搞好大陆的食品安全，and要想搞好翡翠湾，四个注重，不二法门。什么CSA等等等，说白了，丫们都是四个注重的局部异形罢了。鸟儿最恨人家忽悠！不忽悠能死啊？或曰：三千里浮花开在静谧如深海的肉身；落花里面的开花之轻，之痛；在玉的深处如瓷器般易碎。
评分观察细致，分析准确。虽然现代的解决方法已经变化很大了，但问题并没有消失。
