這次是讀了《人月神話》第二章之後的想法， 原來人月這個思考方式是謬誤的，他存在一定的錯誤範圍，“成本的確隨開發產品的人數和時間的不同，有著很大的變化，進度卻不是如此。因此我認為 用人月作為衡量一項工作的規模是一個危險和帶有欺騙性的神話。 它暗示著人員數量和時間是可以相互替換的”這個就說明了人月估算法是錯誤的，他暗示了人月這個計量單位人數和時間是可以互換的，但是僅存在於“某個任務可以分解給參與人員，並且他們之間不需要相互的交流”，就像割小麥一樣，你幹這一塊，我做那一塊，其實我覺得每一個項目的開發過程中都會有這麽一段時間，項目開發員在分配工作，在組織者的調節下，他們把自己的工作認真，並規範的完成，這或許就是一個項目由一個團隊共同開發會更加的省時省力的原因吧。

這一點就和《人月神話》的第三章中的思想相似了，一個架構師，盡可能少的結構師和好的工作分工，結構師領導實施人員。這樣可以保證概念一致性和盡可能少的溝通成本。這個團隊要在架構師的專制下運作。這個架構師，就是我理解中的組織者，他負責帶領一個團隊進行軟件開發的組織，及成員之間工作的分配，做到更加的省時省力，提高程序猿的效率，是他的責任，也是他應盡的義務。

“同廚師一樣，某項任務的計劃進度，可能受限於顧客要求的緊迫程度，但緊迫程度無法控制實際的完成情況。就像約好在兩分鐘內完成一個煎蛋，看上去可能進行得非常好。但當它無法在兩分鐘內完成時，顧客只能選擇等待或者生吃煎蛋。軟件顧客的情況類似。”這是在說軟件開發工作者在開發過程中需要非常配合“顧客”也就是需求者的需求，說起來很繞口，但是想一想很簡單，作為軟件開發工作者，唯一的工作就是開發軟件，然後把開發的軟件交給有這種需求的人，簡簡單單。

關於需求者下一次閱讀我就會更加啊細心，認真的分析。

《人月神話》——第二次閱讀