本書第一章提到，過去幾十年的大型系統開發猶如乙個焦油坑，很多大型和強壯的動物在其中劇烈掙扎。各種問題糾結在一起，團隊的行動越來越慢。他們大多開發出了可執行的系統，但只有極少數的專案滿足了目標。
究其原因，首先，我們對估算技術缺乏有效的研究，總是假設「一切都將運作良好」，但事實往往不是這樣，在我們程式設計的時候也從中了解，不經測試一下子寫100或1000行**不出錯的概率幾乎為零，同樣在大型專案裡，或多或少包含了很多任務，某些任務間還具有前後的次序，從而一切正常的概率變得非常小，甚至接近於零。因此我們的樂觀主義並不應該是理所應當的，這要求我們對專案時間估算要更加謹慎。
我們採用的估算技術（使用工作量單位：人月）隱含地假設人和月可以互換，錯誤地將進度與工作量相互混淆，那也許真得就是乙個「人月神話」。人數和時間的互換，僅僅適用於任務可以任意分解的情況，這在系統程式設計中幾乎是不可能的，乙個軟體如果被分成若干個子程式，它們之間必定有關聯，有次序關係。於是在新增人手時，並不等於平均分配了時間，因為他們之間還要為了將各自模組組成軟體進行交流，在這種情況下，人員和時間的關係並不是線性關係，如圖所示。
對進度缺少跟蹤和監督，也是導致專案時間延長的原因之一。關於任務進度的安排，有如下經驗法則：
1/3 計畫
1/6 編碼
1/4 構件測試和早期系統測試
1/4 系統測試，所有的構件已完成
感謝作者分享的多年經驗
人月神話讀後感03
專案開發團隊要足夠簡潔。絕大多數大型程式設計系統的經驗顯示出，一擁而上的開發方法是高成本的 速度緩慢的 不充分的，開發出的是無法在概念上進行整合的產品。對於效率和概念的完整性來說，最好由少數幹練的人員來設計和開發，而對於大型系統，則需要大量的人手，以使產品能在時間上滿足要求。這兩方面的矛盾如何調節？...
人月神話讀後感03
今天讀完人月筆記，但是也只是粗略的閱讀過一遍，好書要細品，可能是我還沒有參與過一次真正的專案吧，書中其實很多東西我沒有太深的理解，很多都是僅限於我知道了，以後盡量注意，還沒有有著深刻的認知。下我理解的一部分，首先便是交流，書中也說 交流與交流的結果 組織，是成功的關鍵 交流是團隊必不可少，甚至可以說...
《人月神話》讀後感
不同的社會經驗，不同的思想狀態，對讀本書的心得也不一樣，我在此說說我的讀後感，書中有許多非常好的觀點，但我只把我感觸最深的寫下來。這確實是一本很值得多次閱讀的好書，每次閱讀可能都能從中得到一些提示。1.外科手術隊伍the surgical team 專案經理在專案的初期必須清楚的估計專案的人月運作模...