和你一起終身學習，這裡是羅輯思維。
最近，我們欄目的策劃人，王占景老師推薦我看了一部紀錄片，是講波音飛機是怎麼製造出來的。其中有一句話，給我印像很深。
這家飛機製造廠，其實就是一家總裝廠。飛機上的全部零部件都來自其他地方，比如座椅來自德國、機翼部件來自中國。你能想像出一架波音747飛機上總共有多少個零部件嗎？600萬個！
而且，這600萬個零部件，可不是像生產汽車那樣，靠機器人、流水線來自動裝配，它基本是靠工人手工組裝起來的。你可以想像，這600萬個零部件中，不管是一顆螺栓沒有擰緊，還是一顆螺絲釘掉進了引擎或油箱裡，一點點小問題，都會給將來的飛行帶來意想不到的災難。那部紀錄片講到這裡的時候，一位接受采訪的老師傅說了一句話，原文是英文，翻譯過來的意思就是，質量是質量，數量是數量，你不能用質量去代替數量。
什麼意思？
你想，如果說這架飛機由600萬個零部件組成，那就一個都不能少，你不能說我這599萬9999個零部件都是質量最上乘的，也全部精準組裝到位，但有一個零件不見了，你看能不能通融一下？肯定不行啊。它質量就是有重大隱患。
我父親也告訴過我一個類似的小故事。他年輕的時候，學過放電影。那個時候的電影放映機都是機械的，機械結構非常複雜。而放電影的人都要學怎麼拆卸和安裝放映機。有一次，他就拆了，也裝了，也能正常放映了，但是就是多出來一小碗螺絲。老師傅就白了他一眼，說，既然多出來了，就是多餘的，你就扔掉吧。這當然是擠兌他的話。雖然看起來運轉正常，但是因為這數量上出了問題，質量上一定有隱患。雖然眼下並不知道問題在哪裡。你看，質量是質量，數量是數量，你不能用質量去代替數量。
這句話之所以值得回味。
是因為它裡面有一個道理，就是：不同性質的事物之間是不能相互替代和轉換的。
用一個抽象的總體的指標，沒法理解一個複雜的事物。
可能有人覺得，這個道理實在是太普通了。
這還用說嗎？千里之堤潰於蟻穴，說的不就是數量和質量之間的不對稱嗎？
下象棋，你車馬炮俱全，但是還是可能被對方將死。
這說的也是數量和質量之間的不對稱啊。這有什麼不好理解的呢？
但是，這個道理並不像表面上看起來的那麼好懂。人類日常的很多誤區就是這麼來的。
比如，比較兩個國家的實力，我們喜歡用GDP數據或者是軍事裝備的數量來比較。
好像也能說明點問題。但是如果兩國真正發生對抗，你會發現，真正起作用的，不是這些表面上的數據，而是某個剛開始沒有被關注到的，關鍵點上的差別。
再比如，看一家公司的業務，我們喜歡用流量、收入、用戶數這些數量上的指標。但是一家公司成功我們回頭來看，真正能決定它未來的，也許是一個被忽略的關鍵因素。
你看，任何數量都不能替代關鍵位置上的質量。
這個原理對我們這代人來說越來越重要。
為啥？因為世界正在變得越來越複雜。
用簡單模型認識它，越來越無效。
舉個例子：在軟件項目管理中有一個詞叫“人月”，“人”就是一個人、兩個人的人，“月”就是一個月、兩個月的月。
所謂“人月”，就是一個人在一個月內所能完成的工作量。
假設某個項目預估需要12個人月，那麼你就算了，如果指派4個人來做這個項目，理論上需要3個月；而如果指派6個人來做這個項目，理論上則只需要2個月便可以完成。
你看，這就是用一個簡單的數量模型，來控制一個複雜工程。
很多公司在做軟件工程項目的時候，就是這麼計算人力和時間投入的。
但是，幹過軟件工程的人都知道，這麼算，是很荒謬的。
程序員的世界裡，有一本很經典的書，就叫《人月神話》，就是在駁斥這種算法。
這本書的作者是圖靈獎的得主布魯克斯。他的意思是，軟件開發，工程龐大，又非常複雜。我們人類對於這種項目，通常是分工合作，因為它促進效率，節省時間的。但是，隨著一個項目參與的人越來越多，分工越來越細，人和人之間需要的溝通量，也指數增長。很快你會發現，溝通花費的時間，漸漸地就比分工省下來的時間還要多。說白了，過了一個臨界點，人越多不是越幫忙，而是人越多越添亂。
一個人12個月能完成的事，不見得上12個人1個月就能完成，甚至12個月也未必能完成。
所以，《人月神話》這本書裡建議了一種組織方式，叫“外科手術式的隊伍”。
就像一台外科手術一樣，有一個主刀大夫，軟件項目也應該有一個首席程序員，其他人都是給他提供支持的。這樣，就既能獲得由少數頭腦產生的產品完整性，又能得到多位協助人員的總體生產率，還徹底地減少了溝通的工作量。
你看，關鍵人，關鍵支點，在復雜系統中的位置越來越重要了。無論是主刀大夫還是首席程序員。
理解了這一點，我們才能看懂這個世界上正在發生的很多事。
比如，我們過去理解一件事，通常願意把它抽象歸納成一些概念或者模型。但是現在這一招不太管用。真知灼見越來越在幹具體事的人的腦子裡，甚至都沒有被歸納和抽像出來。所以那些高頭講章的書本對我們理解這個世界，越來越沒用。看一百篇關於某家成功公司的文章，你還是不知道人家為什麼成功。
最近老喻寫了一篇文章。他說，很多人對自己一無所知的事情，產生了迷之自信。比如，去海底撈吃個飯，覺得，這不就是個火鍋嗎？我也能搞。看到一個微信公眾號火了，怎麼分析也覺得沒有什麼了不起的，我也能行。他幹，就偏偏不行。
這是一種奇怪的幻覺。不僅是普通人會有這種幻覺，大公司、成功者也一樣。
老喻就舉了一個例子：2010年，Facebook做了一個職業社交網站，這是衝著這個領域的老大領英來的。Facebook想的很簡單啊。我有的是流量，也不缺錢，光這個網站就拿到了近5000萬美金的投資，怎麼算賬都能贏。果然，通過導流，該個職業社交網站的用戶迅速增長到了2500萬。但是然後呢？過不了多久，Facebook就只好認輸，以200萬美金加上一點股份，就把這個網站處理掉了。
你看，Facebook，是社交網站，世界第一大，它做職業社交，簡直就是一牆之隔，居然就做不成。為啥？其實就是我們今天說的這個效應，他們相信人月神話，相信總體上的數量可以取代關鍵點上的質量。
類似的誤區，我們還可以看到很多。
比如，有些公司，他們真的認為一頭大象可以坐在它任何它想坐的地方，他們真的相信通過砸錢砸人就可以進入任何一個想染指的領域，但很多情況都會失敗。這是一種“人月神話”。
比如，一位父親在外面辛苦工作打拼，結果陪伴孩子的時間越來越少，但是他認為可以通過給孩子買更多東西來進行補償，這也是一種“人月神話”。你的數量解決不了關鍵點上的質量。
人月神話的本質是啥？
是我們在簡單社會養成的一種思維模式。
我們以為，數量優勢，即使不是絕對優勢，也至少是個全面優勢。
但是，進入現代複雜社會之後，這個邏輯不再成立。
問題不在於你是不是有優勢，而在於你是不是知道：
哪裡才是關鍵局部？什麼才是關鍵優勢？
好，這個話題就聊到這裡。明天是周末，羅胖精選再見。
羅胖精選-[學習]推薦閱讀:
NO.705 羅胖精選| 用有限信息也能找到真相
NO.706 羅胖精選| 如何讓優秀的員工穩定工作？
NO.726 羅胖精選| 找到你的旋轉飛輪
NO.730 羅胖精選| 高手是怎樣煉成的？
NO.732 羅胖精選 | 你相信“人月神話”嗎？
NO.735 羅胖精選| 你面對的是單純問題嗎？
NO.736 羅胖精選| 怎麼處理“棘手問題”？
NO.737 羅胖精選| 老闆去哪兒了？
NO.738 羅胖精選|法律思維有什麼不一樣？
NO.785 羅胖精選 | 什麼是自學的三境界？
《人月神話：軟體專案管理之道》這本書，
是 IBM 360 系統之父 Frederick P. Brooks, Jr 所著的一本討論軟體專案管理的經典書籍，其原名為《The Mythical Man-Mooth: Essays on Software Engineering》；這本書最早的版本是在 1975 年所發行的，而之後在 1995 年時，又另外發行了「20 周年紀念版」，算是根據後來的發展、意見，針對前一版再做補充說明。而 Heresy 這次所看的，則是由錢一一所譯的 20 周年紀念版的中文版本。
書名所謂的「人月」（man-month），一般是在做專案管理時，用來計算投入的人力時間的單位（或「人年」），一個人做一個月，就是一個人月。而由於這本書就是在探討專案管理的方法，所以用這樣的詞來作為書名，還算是滿貼切的。
而這本書的本文部分共有十九章，前十五章應該是初版時就有的章節，十六到十九章，應該是在「20 周年紀念版」才加入的內容。其章節名稱如下：
第 1 章 焦油坑（The Tar Pit）
第 2 章 人月神話（The Mythical Man-Month）
第 3 章 外科手術團隊（The Surgical Team）
第 4 章 專制、民主與系統設計（Aristocracy, Democracy, and System Design）
第 5 章 第二系統效應（The Second-System Effect）
第 6 章 意念的傳達（Passing the Word）
第 7 章 巴別塔為什麼失敗？（Why Did the Tower of Babel Fail?）
第 8 章 預估（Calling the shot）
第 9 章 地盡其利，物盡其用（Ten Pounds in a Five-Pound Sack）
第 10 章 文件假說（The Document Hypothesis）
第 11 章 失敗為成功之母（Plan to Throw One Away）
第 12 章 神兵利器（Sharp Tools）
第 13 章 化整為零（The Whole and the Parts）
第 14 章 釀成大災難（Hatching a Catastrophe）
第 15 章 一體兩面（The Other Face）
第 16 章 沒有銀彈：軟件工程的本質性與附屬性工作（No Silver Bullet – Essence and Accident in Software Engineering）
第 17 章 再論「沒有銀彈」（"No Silver Bullet" Refired）
第 18 章 《人月神話》的主張：是真是假？（Propositions of The Mythical Man-Month: True or False?）
第 19 章 《人月神話》二十年（The Mythical Man-Month after 20 Years）
由於這本書出版的時間算是有相當的年代了，所以其實在 Heresy 來看，書中有不少的描述，其實都已經過時、對於現在的資訊相關環境來說，算是部怎麼是用了；但是整體來說，這本書應該還是針對軟體開發的管理，有不小的幫助。而在 20 周年紀念版的第 18 章「《人月神話》的主張：是真是假？ 」，有將初版的十五章做條列式的摘要整理，如果想先大概了解書中大概的人，或許可以先跳到第十八章，把這些條目大概掃過一次。
而接下來的部分，則是 Heresy 個人針對各章節中，覺得比較重要的東西：
第一章 焦油坑
這部分是先在描述整個軟體開發的環境，主要是在描述一個正規的軟體開發團隊，和個人的程式開發的差異。
image大型系統的軟體開發基本上就像陷入焦油坑一樣，雖然個別的問題看來都好解決，但是卻又因為糾結在一起，導致不但專案難以前進，連要去理解問題都有問題。而這也是一般的「程式」和「軟體產品」、「軟體系統」，乃至於「軟體系統產品」的差別。
「程式」是要能變成「軟體產品」，要有通用性、完整的測試、齊全的文件以及可維護性，所以它的完成成本至少會是一個程式的三倍。而當程式要能變為「軟體系統」時，他必須要將多個程式做出完整明確的介面定義、使其可以交互運作；而軟體系統中的單一組件的成本，至少會是單獨程式的三倍，當組件的數量越多、成本也就越高。而更大的「軟體系統產品」，由於要兼顧「軟體產品」和「軟體系統」的事項，所以成本也就更高了～其所需的成本，至少會是單獨程式的九倍以上。而這也就是一個正規軟體開發團隊和個人寫程式的差別。
另外，在這章裡也描述了一些寫程式的樂趣和苦難，講的都算滿貼切的，不過由於 Heresy 覺得和軟體開發管理的關係並不大，所以就不提了。
第二章 人月神話
本章的章節名稱，就是書名的大標題，而內容，主要則是在探討「軟體專案為什麼不順利」。作者認為，專案會不順利，主要是由五個原因造成的：
過度樂觀
時程預估技術不成熟，而這些不成熟的技術都反映出一個假設：一切都會進行得很順利。
人月
成本會隨著人力和工時的成績而變，但工作的進度則不是，所以用人月來衡量工作規模的大小是危險的，使用人月的前提是在人力和工時可以互換的情況下；只有在工作可以被切分、而且投入的人彼此不用溝通，才有可能做到這樣的換算，當人數持續的增加，溝通的代價可能會完全抵銷掉因為增加人力帶來的好處。
無法做到「欲速則不達」的堅持
缺乏可供估計之用的資料、因此缺乏堅持的勇氣。
時程缺乏監控
另述。
發現時程延誤時，直覺反應就是增加人手，但是這是火上加油
「在一個時程已經落後的軟體專案中增加人手，只會讓他更加落後」。因為不但工作本身要重新切分，新進人員的訓練、新加入的交流，都會造成混亂和額外的工作量。
而作者在本章也有提出他以經驗法則決定的軟體專案時程規劃：
1/3：規劃
1/6：寫程式
1/4：組件測試和早期系統測試
1/4：系統測試、完成所有組件
第三章 外科手術團隊
這一章，主要是在討論程式開發團隊的組成架構。而根據作者所引述的資料，程式設計師的好壞差異相當大，其差異可以高達 10:1；再加上人越多，會增加大量的溝通成本，所以最好盡可能用最少的人來完成專案。根據經驗來看，使用一堆人來蠻幹，是最耗成本、最慢、最沒效率的方法；但是相對的，使用小團隊來開發真正大型的系統的話，速度又太慢了…
image為了解決這樣的問題，作者在這邊介紹了 Harlan Mills 所提出的方法。他建議大系統中的每個小部份分別交由一個團隊（十個人）來負責，而這個團隊的運作，則是以類似外科手術團隊的形式來進行，也就是由一位「首席程式設計師」來做主導、實作，而團隊中其他人則是扮演支援他的腳色（如右圖）。
這個「首席程式設計師」基本上就相當於外科手術團隊裡的外科醫生，他必須有相當的經驗、天分和能力，基本上負責所有程式相關的事情，有絕對的權力。
他的副手基本上可以做到首席能做到的事情，但是只是經驗不夠；除了可以提供意見給首席外，也會代替首席去開會、或是寫一些程式，但是他不對程式負責。而其他的人員則是負責處理其他的相關事務，盡量以提供首席一個良好、不會被其他雜務打擾的開發環境。
這樣一來，這個團隊的運作會是「同心一致」的，因為實際上所有的決策，都會是由首席程式設計師所決定，而其他的人都是以專業上的分工，來讓這個決策得以完成。這樣不但可以讓整個團隊的溝通簡單化、運作更有效率，更可以確保工作成果的概念整體性。
第四章 專制、民主與系統設計
這章的主題是「概念整體性」（conceptual integrity）。作者認為這是在系統設計時最重要的原則，一個強調整體概念性的系統不但開發得更快，測試也快；而要達到這個目的，就代表設計必須出自一個人的想法，或是極少數人的一致決定，也就是必須要是「專制」的。
而在要維持概念整體性的前提下，又需要多人合作開發時，有兩個技術可以使用，一個是上一章的「外科手術團隊」，另一個則是將工作分為「架構」（architecture）和「實作」（implementation）兩個部分；其中，架構是在說明做什麼，實作則是說明如何做。而將架構設計獨立於實作之外，不管對於大型專案或小型專案，都是取得概念完整性強而有力的方法；同時這樣的垂直分工，也會大幅減輕水平分工所產生的負擔，大幅簡化溝通，增進整體概念性。
另外作者在本章也提到了另外一個重要觀點，那就是在功能越來越多的情況下，只有當功能增強所節省的時間超過學習這項功能的耗費的時間時，這項功能的使用便利性才會提升；所以他的結論就是：「由於目的是使用便利性，所以『功能概念複雜度比』（ratio of function to conceptual complexity）才是系統設計的最終測試標準；好的設計不可單獨偏重功能性，也不可只偏重簡單性」。
關於[學習]推薦閱讀:
大學學費貴嗎? 如果一年要花8萬多美金！這樣的大學你會考慮要去上嗎?這兩所大學 全美最貴
最近，我們欄目的策劃人，王占景老師推薦我看了一部紀錄片，是講波音飛機是怎麼製造出來的。其中有一句話，給我印像很深。
這家飛機製造廠，其實就是一家總裝廠。飛機上的全部零部件都來自其他地方，比如座椅來自德國、機翼部件來自中國。你能想像出一架波音747飛機上總共有多少個零部件嗎？600萬個！
而且，這600萬個零部件，可不是像生產汽車那樣，靠機器人、流水線來自動裝配，它基本是靠工人手工組裝起來的。你可以想像，這600萬個零部件中，不管是一顆螺栓沒有擰緊，還是一顆螺絲釘掉進了引擎或油箱裡，一點點小問題，都會給將來的飛行帶來意想不到的災難。那部紀錄片講到這裡的時候，一位接受采訪的老師傅說了一句話，原文是英文，翻譯過來的意思就是，質量是質量，數量是數量，你不能用質量去代替數量。
什麼意思？
你想，如果說這架飛機由600萬個零部件組成，那就一個都不能少，你不能說我這599萬9999個零部件都是質量最上乘的，也全部精準組裝到位，但有一個零件不見了，你看能不能通融一下？肯定不行啊。它質量就是有重大隱患。
我父親也告訴過我一個類似的小故事。他年輕的時候，學過放電影。那個時候的電影放映機都是機械的，機械結構非常複雜。而放電影的人都要學怎麼拆卸和安裝放映機。有一次，他就拆了，也裝了，也能正常放映了，但是就是多出來一小碗螺絲。老師傅就白了他一眼，說，既然多出來了，就是多餘的，你就扔掉吧。這當然是擠兌他的話。雖然看起來運轉正常，但是因為這數量上出了問題，質量上一定有隱患。雖然眼下並不知道問題在哪裡。你看，質量是質量，數量是數量，你不能用質量去代替數量。
這句話之所以值得回味。
是因為它裡面有一個道理，就是：不同性質的事物之間是不能相互替代和轉換的。
用一個抽象的總體的指標，沒法理解一個複雜的事物。
可能有人覺得，這個道理實在是太普通了。
這還用說嗎？千里之堤潰於蟻穴，說的不就是數量和質量之間的不對稱嗎？
下象棋，你車馬炮俱全，但是還是可能被對方將死。
這說的也是數量和質量之間的不對稱啊。這有什麼不好理解的呢？
但是，這個道理並不像表面上看起來的那麼好懂。人類日常的很多誤區就是這麼來的。
比如，比較兩個國家的實力，我們喜歡用GDP數據或者是軍事裝備的數量來比較。
好像也能說明點問題。但是如果兩國真正發生對抗，你會發現，真正起作用的，不是這些表面上的數據，而是某個剛開始沒有被關注到的，關鍵點上的差別。
再比如，看一家公司的業務，我們喜歡用流量、收入、用戶數這些數量上的指標。但是一家公司成功我們回頭來看，真正能決定它未來的，也許是一個被忽略的關鍵因素。
你看，任何數量都不能替代關鍵位置上的質量。
這個原理對我們這代人來說越來越重要。
為啥？因為世界正在變得越來越複雜。
用簡單模型認識它，越來越無效。
舉個例子：在軟件項目管理中有一個詞叫“人月”，“人”就是一個人、兩個人的人，“月”就是一個月、兩個月的月。
所謂“人月”，就是一個人在一個月內所能完成的工作量。
假設某個項目預估需要12個人月，那麼你就算了，如果指派4個人來做這個項目，理論上需要3個月；而如果指派6個人來做這個項目，理論上則只需要2個月便可以完成。
你看，這就是用一個簡單的數量模型，來控制一個複雜工程。
很多公司在做軟件工程項目的時候，就是這麼計算人力和時間投入的。
但是，幹過軟件工程的人都知道，這麼算，是很荒謬的。
程序員的世界裡，有一本很經典的書，就叫《人月神話》，就是在駁斥這種算法。
這本書的作者是圖靈獎的得主布魯克斯。他的意思是，軟件開發，工程龐大，又非常複雜。我們人類對於這種項目，通常是分工合作，因為它促進效率，節省時間的。但是，隨著一個項目參與的人越來越多，分工越來越細，人和人之間需要的溝通量，也指數增長。很快你會發現，溝通花費的時間，漸漸地就比分工省下來的時間還要多。說白了，過了一個臨界點，人越多不是越幫忙，而是人越多越添亂。
一個人12個月能完成的事，不見得上12個人1個月就能完成，甚至12個月也未必能完成。
所以，《人月神話》這本書裡建議了一種組織方式，叫“外科手術式的隊伍”。
就像一台外科手術一樣，有一個主刀大夫，軟件項目也應該有一個首席程序員，其他人都是給他提供支持的。這樣，就既能獲得由少數頭腦產生的產品完整性，又能得到多位協助人員的總體生產率，還徹底地減少了溝通的工作量。
你看，關鍵人，關鍵支點，在復雜系統中的位置越來越重要了。無論是主刀大夫還是首席程序員。
理解了這一點，我們才能看懂這個世界上正在發生的很多事。
比如，我們過去理解一件事，通常願意把它抽象歸納成一些概念或者模型。但是現在這一招不太管用。真知灼見越來越在幹具體事的人的腦子裡，甚至都沒有被歸納和抽像出來。所以那些高頭講章的書本對我們理解這個世界，越來越沒用。看一百篇關於某家成功公司的文章，你還是不知道人家為什麼成功。
最近老喻寫了一篇文章。他說，很多人對自己一無所知的事情，產生了迷之自信。比如，去海底撈吃個飯，覺得，這不就是個火鍋嗎？我也能搞。看到一個微信公眾號火了，怎麼分析也覺得沒有什麼了不起的，我也能行。他幹，就偏偏不行。
這是一種奇怪的幻覺。不僅是普通人會有這種幻覺，大公司、成功者也一樣。
老喻就舉了一個例子：2010年，Facebook做了一個職業社交網站，這是衝著這個領域的老大領英來的。Facebook想的很簡單啊。我有的是流量，也不缺錢，光這個網站就拿到了近5000萬美金的投資，怎麼算賬都能贏。果然，通過導流，該個職業社交網站的用戶迅速增長到了2500萬。但是然後呢？過不了多久，Facebook就只好認輸，以200萬美金加上一點股份，就把這個網站處理掉了。
你看，Facebook，是社交網站，世界第一大，它做職業社交，簡直就是一牆之隔，居然就做不成。為啥？其實就是我們今天說的這個效應，他們相信人月神話，相信總體上的數量可以取代關鍵點上的質量。
類似的誤區，我們還可以看到很多。
比如，有些公司，他們真的認為一頭大象可以坐在它任何它想坐的地方，他們真的相信通過砸錢砸人就可以進入任何一個想染指的領域，但很多情況都會失敗。這是一種“人月神話”。
比如，一位父親在外面辛苦工作打拼，結果陪伴孩子的時間越來越少，但是他認為可以通過給孩子買更多東西來進行補償，這也是一種“人月神話”。你的數量解決不了關鍵點上的質量。
人月神話的本質是啥？
是我們在簡單社會養成的一種思維模式。
我們以為，數量優勢，即使不是絕對優勢，也至少是個全面優勢。
但是，進入現代複雜社會之後，這個邏輯不再成立。
問題不在於你是不是有優勢，而在於你是不是知道：
哪裡才是關鍵局部？什麼才是關鍵優勢？
好，這個話題就聊到這裡。明天是周末，羅胖精選再見。
羅胖精選-[學習]推薦閱讀:
NO.705 羅胖精選| 用有限信息也能找到真相
NO.706 羅胖精選| 如何讓優秀的員工穩定工作？
NO.726 羅胖精選| 找到你的旋轉飛輪
NO.730 羅胖精選| 高手是怎樣煉成的？
NO.732 羅胖精選 | 你相信“人月神話”嗎？
NO.735 羅胖精選| 你面對的是單純問題嗎？
NO.736 羅胖精選| 怎麼處理“棘手問題”？
NO.737 羅胖精選| 老闆去哪兒了？
NO.738 羅胖精選|法律思維有什麼不一樣？
NO.785 羅胖精選 | 什麼是自學的三境界？
《人月神話：軟體專案管理之道》這本書，
是 IBM 360 系統之父 Frederick P. Brooks, Jr 所著的一本討論軟體專案管理的經典書籍，其原名為《The Mythical Man-Mooth: Essays on Software Engineering》；這本書最早的版本是在 1975 年所發行的，而之後在 1995 年時，又另外發行了「20 周年紀念版」，算是根據後來的發展、意見，針對前一版再做補充說明。而 Heresy 這次所看的，則是由錢一一所譯的 20 周年紀念版的中文版本。
書名所謂的「人月」（man-month），一般是在做專案管理時，用來計算投入的人力時間的單位（或「人年」），一個人做一個月，就是一個人月。而由於這本書就是在探討專案管理的方法，所以用這樣的詞來作為書名，還算是滿貼切的。
而這本書的本文部分共有十九章，前十五章應該是初版時就有的章節，十六到十九章，應該是在「20 周年紀念版」才加入的內容。其章節名稱如下：
第 1 章 焦油坑（The Tar Pit）
第 2 章 人月神話（The Mythical Man-Month）
第 3 章 外科手術團隊（The Surgical Team）
第 4 章 專制、民主與系統設計（Aristocracy, Democracy, and System Design）
第 5 章 第二系統效應（The Second-System Effect）
第 6 章 意念的傳達（Passing the Word）
第 7 章 巴別塔為什麼失敗？（Why Did the Tower of Babel Fail?）
第 8 章 預估（Calling the shot）
第 9 章 地盡其利，物盡其用（Ten Pounds in a Five-Pound Sack）
第 10 章 文件假說（The Document Hypothesis）
第 11 章 失敗為成功之母（Plan to Throw One Away）
第 12 章 神兵利器（Sharp Tools）
第 13 章 化整為零（The Whole and the Parts）
第 14 章 釀成大災難（Hatching a Catastrophe）
第 15 章 一體兩面（The Other Face）
第 16 章 沒有銀彈：軟件工程的本質性與附屬性工作（No Silver Bullet – Essence and Accident in Software Engineering）
第 17 章 再論「沒有銀彈」（"No Silver Bullet" Refired）
第 18 章 《人月神話》的主張：是真是假？（Propositions of The Mythical Man-Month: True or False?）
第 19 章 《人月神話》二十年（The Mythical Man-Month after 20 Years）
由於這本書出版的時間算是有相當的年代了，所以其實在 Heresy 來看，書中有不少的描述，其實都已經過時、對於現在的資訊相關環境來說，算是部怎麼是用了；但是整體來說，這本書應該還是針對軟體開發的管理，有不小的幫助。而在 20 周年紀念版的第 18 章「《人月神話》的主張：是真是假？ 」，有將初版的十五章做條列式的摘要整理，如果想先大概了解書中大概的人，或許可以先跳到第十八章，把這些條目大概掃過一次。
而接下來的部分，則是 Heresy 個人針對各章節中，覺得比較重要的東西：
第一章 焦油坑
這部分是先在描述整個軟體開發的環境，主要是在描述一個正規的軟體開發團隊，和個人的程式開發的差異。
image大型系統的軟體開發基本上就像陷入焦油坑一樣，雖然個別的問題看來都好解決，但是卻又因為糾結在一起，導致不但專案難以前進，連要去理解問題都有問題。而這也是一般的「程式」和「軟體產品」、「軟體系統」，乃至於「軟體系統產品」的差別。
「程式」是要能變成「軟體產品」，要有通用性、完整的測試、齊全的文件以及可維護性，所以它的完成成本至少會是一個程式的三倍。而當程式要能變為「軟體系統」時，他必須要將多個程式做出完整明確的介面定義、使其可以交互運作；而軟體系統中的單一組件的成本，至少會是單獨程式的三倍，當組件的數量越多、成本也就越高。而更大的「軟體系統產品」，由於要兼顧「軟體產品」和「軟體系統」的事項，所以成本也就更高了～其所需的成本，至少會是單獨程式的九倍以上。而這也就是一個正規軟體開發團隊和個人寫程式的差別。
另外，在這章裡也描述了一些寫程式的樂趣和苦難，講的都算滿貼切的，不過由於 Heresy 覺得和軟體開發管理的關係並不大，所以就不提了。
第二章 人月神話
本章的章節名稱，就是書名的大標題，而內容，主要則是在探討「軟體專案為什麼不順利」。作者認為，專案會不順利，主要是由五個原因造成的：
過度樂觀
時程預估技術不成熟，而這些不成熟的技術都反映出一個假設：一切都會進行得很順利。
人月
成本會隨著人力和工時的成績而變，但工作的進度則不是，所以用人月來衡量工作規模的大小是危險的，使用人月的前提是在人力和工時可以互換的情況下；只有在工作可以被切分、而且投入的人彼此不用溝通，才有可能做到這樣的換算，當人數持續的增加，溝通的代價可能會完全抵銷掉因為增加人力帶來的好處。
無法做到「欲速則不達」的堅持
缺乏可供估計之用的資料、因此缺乏堅持的勇氣。
時程缺乏監控
另述。
發現時程延誤時，直覺反應就是增加人手，但是這是火上加油
「在一個時程已經落後的軟體專案中增加人手，只會讓他更加落後」。因為不但工作本身要重新切分，新進人員的訓練、新加入的交流，都會造成混亂和額外的工作量。
而作者在本章也有提出他以經驗法則決定的軟體專案時程規劃：
1/3：規劃
1/6：寫程式
1/4：組件測試和早期系統測試
1/4：系統測試、完成所有組件
第三章 外科手術團隊
這一章，主要是在討論程式開發團隊的組成架構。而根據作者所引述的資料，程式設計師的好壞差異相當大，其差異可以高達 10:1；再加上人越多，會增加大量的溝通成本，所以最好盡可能用最少的人來完成專案。根據經驗來看，使用一堆人來蠻幹，是最耗成本、最慢、最沒效率的方法；但是相對的，使用小團隊來開發真正大型的系統的話，速度又太慢了…
image為了解決這樣的問題，作者在這邊介紹了 Harlan Mills 所提出的方法。他建議大系統中的每個小部份分別交由一個團隊（十個人）來負責，而這個團隊的運作，則是以類似外科手術團隊的形式來進行，也就是由一位「首席程式設計師」來做主導、實作，而團隊中其他人則是扮演支援他的腳色（如右圖）。
這個「首席程式設計師」基本上就相當於外科手術團隊裡的外科醫生，他必須有相當的經驗、天分和能力，基本上負責所有程式相關的事情，有絕對的權力。
他的副手基本上可以做到首席能做到的事情，但是只是經驗不夠；除了可以提供意見給首席外，也會代替首席去開會、或是寫一些程式，但是他不對程式負責。而其他的人員則是負責處理其他的相關事務，盡量以提供首席一個良好、不會被其他雜務打擾的開發環境。
這樣一來，這個團隊的運作會是「同心一致」的，因為實際上所有的決策，都會是由首席程式設計師所決定，而其他的人都是以專業上的分工，來讓這個決策得以完成。這樣不但可以讓整個團隊的溝通簡單化、運作更有效率，更可以確保工作成果的概念整體性。
第四章 專制、民主與系統設計
這章的主題是「概念整體性」（conceptual integrity）。作者認為這是在系統設計時最重要的原則，一個強調整體概念性的系統不但開發得更快，測試也快；而要達到這個目的，就代表設計必須出自一個人的想法，或是極少數人的一致決定，也就是必須要是「專制」的。
而在要維持概念整體性的前提下，又需要多人合作開發時，有兩個技術可以使用，一個是上一章的「外科手術團隊」，另一個則是將工作分為「架構」（architecture）和「實作」（implementation）兩個部分；其中，架構是在說明做什麼，實作則是說明如何做。而將架構設計獨立於實作之外，不管對於大型專案或小型專案，都是取得概念完整性強而有力的方法；同時這樣的垂直分工，也會大幅減輕水平分工所產生的負擔，大幅簡化溝通，增進整體概念性。
另外作者在本章也提到了另外一個重要觀點，那就是在功能越來越多的情況下，只有當功能增強所節省的時間超過學習這項功能的耗費的時間時，這項功能的使用便利性才會提升；所以他的結論就是：「由於目的是使用便利性，所以『功能概念複雜度比』（ratio of function to conceptual complexity）才是系統設計的最終測試標準；好的設計不可單獨偏重功能性，也不可只偏重簡單性」。
關於[學習]推薦閱讀:
大學學費貴嗎? 如果一年要花8萬多美金！這樣的大學你會考慮要去上嗎?這兩所大學 全美最貴
投資理財相推薦閱讀:：
- 不管你是包租公還是自住客-你必需知道的房地產小常識-(貸款篇)估算屋主取得成本
- 不管你是包租公還是自住客-你必需知道的房地產小常識-(貸款篇)精華區老屋申貸較容易
- 不管你是包租公還是自住客-你必需知道的房地產小常識-(貸款篇)銀行鑑價未必等同買賣價
- 不管你是包租公還是自住客-你必需知道的房地產小常識-(貸款篇)留意老屋建築結構
- 不管你是包租公還是自住客-你必需知道的房地產小常識-務必親自到現場一探究竟
- 不管你是包租公還是自住客-你必需知道的房地產小常識-(貸款篇)銀行貸款用語;"成數"到底是什麼?
- 不管你是包租公還是自住客-你必需知道的房地產小常識-(貸款篇)老屋,中古屋貸款年限
- 竹北-興富發【水公園】買的起的水岸景觀宅
- 竹北大遠百商圈-佳泰世紀城 號稱竹北最強首購,2房只要528萬起....
- 【完整分析】富爸爸現金流遊戲心得及如何利用零成本做生意+從現金流遊戲來思考如何(不用錢)建立被動收入?
- 申辦房貸六個步驟和房貸審核標準及所需文件
- 最近看到的新聞 「租屋 買屋 你選哪一邊？」
- [竹北高鐵]新竹竹北建案-坤山禾和,施工進度
- 竹科COSTCO旁不到700萬的全新預售兩房，您有興趣嗎? 興富發關埔最新潛銷案
- 信用不良可貸款、信用瑕疵可貸款嗎? 貸款專家沒說的秘密 "貸款加油站"一次完整破解給你看!!!讓你不再為貸款傷腦筋
- 中古車貸 最高可貸權威150%
- 房貸流程實況
- 免費小工具-劃格局超好用的軟體
- 遇到"失業"你會害怕嗎?現金流遊戲完整說明及遊戲玩法+現金流遊戲下載繁體中文版,富爸爸現金流遊戲pc版 如果你還不知道這個秘密，那你注定要窮一輩子!!!
- 房地產相關契約範本-租屋契約範本
- 理財型房貸到底是什麼?
- 中古屋看屋日記-新竹-竹東-旭家一期
- [貸款小技巧之細說貸款名詞] 負債比的意義-
- 竹科COSTCO旁不到700萬的全新預售兩房，您有興趣嗎? 興富發關埔最新潛銷案
- 竹北看屋筆記-[竹北河岸第一排]竹北建案-文鼎美漾
- [台中看屋日記] 台中市西區精誠29街3樓
- 大河戀高樓視野3房
- 新竹昌益二重埔造鎮計劃【昌益星都心】 開始潛銷開賣了嗎?
- [竹北看屋筆記]「東陞墅日子」猜猜看，我是不是這間的女主人呢？
- 銀行貸款怎麼辦??讓貸款V怪客告訴你,該如何不被銀行婉拒!!
- 信用瑕疵到底能不能貸款 遲繳 控卡 強停到底有沒有銀行能貸款??
- 第一次驗屋學超多-嘉璟建設-竹北臻觀驗屋
- 其實小白並沒有你想像中這麼難貸款
- 信用卡一直繳最低會怎樣？普卡、金卡和白金卡又有什麼區別 弄懂信用卡賬單分期和現金分期，保證你再也不敢拖欠卡費！
- 銀行婉拒或退件之銀行貸款困難案件!
- 沒有工作沒有收入這樣還可以貸款嗎？現在有四招可以滿足你
- 徵信沒問題就能成功貸款嗎？為什麼信用不良或是信用瑕疵也能貸款？
- 下雨天南風天為什麼家中會出現牆壁流汗及地板潮濕嚴重情形呢?家中太潮濕有什麼壞處?該如何有效解決下雨天潮濕的情況呢?
- 找到二房東好物件前,最常經歷的５件事,其中第２項最常讓我欲哭無淚
- 房地產「租賃時代」到來，未來10年走勢？房產達人：房價下跌、租金持穩
- 新竹縣-竹東最佳旅遊景點TOP 10
- 青年房租補貼9月上路！單身、婚育，各縣市不同級距一次看清楚：最高可領5000元，只要符合1條件！婚育家庭租屋最高補助5千元
- 108年度低收入戶、中低收入戶審核標準 收入戶、中低收入戶申請時間及審核時間要多久呢? 申請收入戶、中低收入戶需要準備那些文件呢?
留言
張貼留言