巴比倫塔的失敗主要是因為交流不暢，語言不通使得複雜的工程在交流模組變得更加的複雜，過度的交流影響了建築的效率以及概念的完整性。軟體產品也是一樣的，乙個軟體產品的複雜度並不比巴比倫塔低，從分析到設計到開發到測試，整個流程下來，完全可以說軟體產品就是乙個小型的巴比倫塔（建築工程），所謂軟體工程的工程二字，也可以說是因為它的複雜程度吧。
文中針對交流方面提出了兩個問題，乙個是如何保證必要的交流，另乙個是如何避免不必要的交流。看上去保障必要交流比避免不必要的交流要簡單的多。那麼如何避免不必要的交流呢？文中提到了一種簡單易行的方式就是劃定成員職責範圍，當每個人都有自己獨立的職責時，就不存在「不必要」的交流了，每個人在自己的範圍內進行交流發言，明確分工任務，從而減輕複雜的交流。
那這是不是就意味著，不屬於自己範圍的問題就不可以提出呢？當然不是的，要知道在開發過程中，所謂交流，不是有問題沉默，有問題要及時的提出來，爭吵比沉默要來的實在，適當的詢問是可以提高開發效率的。
但是這個過程，也並不是隨心所欲的，擅自的猜測有時會影響團隊成員之間的關係，文中給出了乙個解決辦法——工作手冊，詳細的工作手冊也是增加效率的乙個重要途徑，查詢手冊可以幫助團隊成員解決很多細小的問題。
而對於乙個小型團隊來說，主要是以架構師或者是技術主管為首腦，對於學生團隊，則要以能力較強的程式設計師為首腦，這樣的分布更有利於開發中問題的解決，該程式設計師要有足夠的權威決定產品的各項功能以及完整架構，如此方可實現專案的高效實現。
大學期間我看到了很多團隊都是以「精」為重，他們到處招攬人才，能力水平幾乎沒有什麼區分，在各個專業都是「大佬」級別的存在，這樣的團隊，沒有乙個確定的領導者，而在團隊會議中，各種問題也是層出不窮，每個人都有自己的想法，這就導致了專案開發中的各種交流問題以及決定問題。
所以我覺得，在組建團隊的時候，切忌全部成員都是「大佬」級的人物，一定要突出乙個首腦，這樣的團隊在工作的時候才不容易出現分歧
人月神話閱讀筆記03
人月神話拜讀完了，真的感覺學到了很多，受益匪淺，書開始就形象有有趣的把軟體危機比作 焦油坑，交流至關重要，實踐是最好的老師，文件撰寫是軟體人的必修課，這本書讓我們對軟體工程有了更深一步的理解，有了全新的認識，軟體工程焦油坑在相當長時間內仍會存在，我們必須努力學習，不斷創新，獲得更大的進步。一 我過去...
人月神話閱讀筆記03
今天我閱讀的是貫徹執行一節。假設乙個專案經理已經擁有行事規範的結構師和許多程式設計實現人員，那麼他如何確保每個人聽從 理解並實現結構師的決策？對於乙個由 1000 人開發的系統，乙個 10 個結構師 的小組如何保持系統概念上的完整性？首先要有文件化的規格說明，即手冊。手冊或者書面規格說明，是乙個非常...
人月神話閱讀筆記03
人狼這種民間傳說中存在的怪物，會在月圓之夜由我們熟悉的人類面孔變成可怕的狼臉。我們熟悉的軟體專案也有著人狼的特性，看似簡單明瞭的外表，但是卻可能隨時變成乙個進度落後 超出預算 存在大量缺陷的怪物。在民間傳說中對付人狼唯一可靠的 就是銀彈。所以銀彈在軟體專案中就是比喻這種使得軟體成本像計算機硬體成本一...