就增加人手這個解決方法來看，首先得要解決溝通問題。溝通所增加的負擔由兩個部分組成，培訓和相互的交流。每個成員需要進行技術、專案目標以及總體策略上的培訓。這種培訓不能分解，因此這部分增加的工作量隨人員的數量呈線性變化 。 因為軟體開發本質上是一項系統工作——錯綜複雜關係下的一種實踐——溝通、交流的工作量非常大，它很快會消耗任務分解所節省下來的個人時間。從而，新增更多的人手，實際上是延長了，而不是縮短了時間進度。
書中所說的乙個專案的估算是十分重要的。在開始乙個專案的時候，我們總會對這個專案完成設定乙個預估的時間，為了在指定時間，完成專案，團隊只能無限突破各種的困難，並盡可能地提高工作效率。在闡述了第乙個謬誤後，作者又引出了第二個謬誤「人月」。從本書的題目就可以知道，「人月」一定是本書的重中之重。成本的確和開發產品的人數和時間有關，但是進度卻不是這樣。我現在明白「人月」中的月指的是工程專案中的花費時間。人數和時間的互換僅僅適用於以下情況：某個任務可以分解給參與人員，並且 他們 之間不需要 相 互的交流。 這在割小麥或收穫棉花的工作中是可行的；而在系統程式設計中近乎不可能。所以說，在系統程式設計中，人數與時間地互換是一種荒謬地觀點。作者舉出了乙個十分淺顯易懂地例子——無論多少個母親，孕育乙個生命都需要十個月。以為孕育生命這個程序來說，是絕對不可以分割給別人地，由於測試除錯地次序問題，大部分專案都具有這個特點。
這一章引發了乙個具有實際性的問題：如何在有意義的進度安排內建立大型的系統？大量的技術人員一湧而至還是則少數的精煉者獨當一面卻忽略了專案的截止時間？針對這種現象，又如何的選擇？如何的解決這一矛盾，從而保證最高效，最低成本的完成？
mills的給出了明確的答覆——明確的分工，手術團隊大大小小的成員各司其職，分工明確。mills建議大型專案分為小部分，每個小部分由乙個團隊解決，而團隊則是以外科手術團隊的方式來構建。外科手術團隊因為是由乙個人來完成問題的分解，其他人給予必要的支援的方式來運作。
人月神話閱讀筆記2
人月神話閱讀筆記之二 之前寫程式注重的只是個人，和團隊的合作機會也很少，及時合作機會但是自己注重的也是自己的進步和發展，和團隊之間的交流和溝通很少，是團隊的專案進行的並不是很好 看完這本書明白了很多，和團隊進行合作就要進行交流和分工 兩個方面 交流，以及交流的結果 組織。他們無法相互交談，從而無法合...
《人月神話》閱讀筆記（2）
在很多方面，管理乙個大型的計算機程式設計專案和其它行業的大型工程很相似 比大 多數程式設計師所認為的還要相似 在很多另外的方面，它又有差別 比大多數職業經理 所認為的差別還要大。這是 人月神話 第一版序言的第一段話，這段話可以說是對軟 件專案的 管理特徵進行了乙個總體的概括。過去幾十年的大型系統開發...
人月神話閱讀筆記（1）
第一章 焦油坑 程式設計產品是簡單程式通過通用化，測試，文件，維護等產生的。保證是乙個完整的程式 程式設計系統是簡單程式符合規範，功能上相互協作，並能與系統在互動上不出錯。保證能與系統配合 程式設計系統產品 程式設計系統 程式設計產品。程式設計系統產品才是大多數系統開發的目標。程式設計系統產品的成本...