領頭羊只能有乙個，其他人輔助它來完成任務。沒有高低貴賤，只是分工不同。
開篇就直接點出這一章節的主要思想，我們在工作中、組建團隊時不要始終如一的****團隊的人員的數量，有時候人員數量越多反而會拖累整個團隊的進度，如現實中大公司有著很多的部門，當其中某個團隊專案中牽扯到其他部門時，可能會導致整個專案的進度受阻，這時什麼原因了？1. 溝通不暢！當部門與部門溝通時所涉及的人員時非常多的，而召集這些人員在同一時間參加會議是比較麻煩的，需要協調每個人的時間，這麼多的人員在同一會議中溝通其實並不是特別的順暢。2. 部門利益不同。每乙個部門的 領導者說關注點主重要的可能是自己部門的利益，其次才會關注整個公司的利益，這就導致了當乙個專案牽扯到自己部門時，考慮的不是該專案是不是能夠給公司帶來利益，而是該專案是不是能夠給自己部門帶來利益。如果是只是乙個小團隊那麼這樣的事情是不會發生的。
以上一些原因有一部分是公司制度的原因，但大多數都是我們在組建團隊時沒有認真的區分人員。這一章中明確的指出：「最好的和最差的表現在生產率上平均為 10:1，在執行速度和空間上具有 5:1 的驚人差異！簡言之，$20,000/年的程式設計師的生產率可能是 ￥10,000/年程式設計師的 10 倍。得出的結論很簡單：如果乙個 200 人的專案中，有 25 個最能幹和最有開發經驗的專案經理，那麼開除剩下的 175 名程式設計師，讓專案經理來程式設計開發。」
當乙個團隊中每個人的能力都很強那麼這個隊伍幾乎就成了神話般的精英小隊。所以在組建團隊時考慮的不應該是這個人的編碼水平、薪資水平，更重要的是他的生產效率。寧願使用高出其他普通人薪資的 10 倍來聘請人員，也不要用這些薪資聘請 10 個普通的人員。因為這乙個人的生產效率比的上其餘 10 個人的效率，並且人員數量的增加也造成了溝通成本的增加，可能那 10 個人最後的產出還不如乙個最頂尖人員的產出。
最後這一章節指出了：乙個高效的軟體開發團隊，和乙個外科醫生隊伍有異曲同工之處。由乙個人來完成問題的分解，其他人給予他所需要的支援，以提高效率和生產力。很少的人員被包含在設計和開發中，其他許多人來進行工作的支援。
《人月神話》讀後感 二
今天，我又繼續拜讀 人月神話 聽好多人說這本書是好書。我現在雖然並不能完全理解作者想要表達的含義，但是我現 在好歹是有好多感觸。今天是從第四章開始看的，這章講的是我們在設計系統時，時候首先要考慮的是概念的完整性。隨後作者講了系統測試的最 終標準 功能與理解上的複雜程度的比值。卻不僅僅是這個系統有多麼...
《人月神話》讀後感
不同的社會經驗，不同的思想狀態，對讀本書的心得也不一樣，我在此說說我的讀後感，書中有許多非常好的觀點，但我只把我感觸最深的寫下來。這確實是一本很值得多次閱讀的好書，每次閱讀可能都能從中得到一些提示。1.外科手術隊伍the surgical team 專案經理在專案的初期必須清楚的估計專案的人月運作模...
人月神話讀後感
人月神話 這本書風行已經很久了，寫成於1975年，經歷這麼久的時間，在當前又重新流行，讓我很驚訝,但是一直沒有時間讀。今天突然想起自己的機器上有本拷貝別人的電子書，決定讀讀。我今天只看了兩章，即焦油坑和人月神話。人月神話看上去這麼浪漫的名字，原來並不是真的說神話故事，作者闡述的主要觀點是在軟體開發專...