當我捧起《人月神話》，馬上就被深深的吸引了。書中很多細微之處都對我的思維造成了衝擊。上一本給我類似感覺的書是那本四人幫的《設計模式》，已經很久沒有看到這麼好的書了，鄭重推薦。
把感觸比較深的幾點記下來，順便整理一下自己的思路，與大家分享。
1，保持設計的概念完整。無論對小軟件還是大軟件，都必須由一個設計師主導，最多兩個人討論來共同完成軟件的整體設計。作爲一個軟件，一個系統，必須有一個清晰明確的概念模型，大家都在這個框架下工作，所有的創新發展都必須與基本的概念相吻合。具體的實現人員可以細化概念，但只有總設計者纔有否定與發展基本概念的權力。需要注意的一點是，即使是總設計師一直是同一個人，他腦海中所認爲理所當然的規則或者概念，很可能由於沒有明確的文檔化，而沒有成爲所有開發者共同的概念。在其他開發者編碼的時候，就可能會生成與概念相牴觸的東東（模塊，功能，算法），導致整體結構的惡化。這個時候總設計師一定要即時發現，做出更正。
概念的完整性，對於很多小規模軟件，由於開發人員不多，開發經理一般都能控制住所有的代碼，概念完整性在組織層面就維持住了。但要注意以後的Bug修改，功能擴展的時候，也要時刻留意與最初的設計是否概念上相容。對於大規模的軟件系統，則必須通過樹狀組織結構，層層控制，總設計師還是一到兩人，每一層都有對下層的絕對把握能力。我以前參加過一個15人左右的項目組，就是分爲兩層。感覺整體概念完整性的控制效果還不錯。我沒有更多人數項目的具體實踐經驗，希望以後能有機會參與比較大的項目。
2，“一個拿2倍工資的人，生產率可能是其他人的10倍。”我和我的同學，一個小公司的技術總監聊起這個，他也是十分的認同。不知道其他公司的程序員們如何看。我的同事中有一個牛人，做出的貢獻特別大，應該相當於我們公司普通的十個程序員，不過工資最多也就是普通程序員的二倍。是不是有些不公平呢？我也說不清楚。因爲那些普通程序員也十分的`努力。不過，我覺得，作爲公司，應該給最好的人最好的待遇，或者說給比目前更高的待遇。
組建一個團隊，最好的就是那種精英團隊，大家都是牛人，效率會特別高。微軟就是這種思路吧，把最聰明的人集中在一起，想不都難亞。
3，進度落後與增加人力。記得當年看《C＋＋編程思想》，Bruce說“十個婦女不能在一個月內生下小孩”（大意），於我心有慼慼焉。而本書作者Brooks得出的結論是對我是震撼性的：“向進度落後的項目中增加人手，只會使進度更加落後”。()
以前，增加人手基本是挽救進度落後項目的主要辦法。這個辦法行不通的話，難道只有“加班”一條路了？但長期加班是對個人的摧殘，我更願意利用業餘時間去看書，例如看這本“人月神話”。）
如果不想加班，不想削減功能，不想推遲發佈日期，那麼……唯一的方法還是隻有…加人。加足夠的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能對原來的組織造成衝擊，或者對原來的設計有不同意見（特別是加入的人中有比較強大的設計者）。那麼，就當作，新組建了一個團隊吧。交流，培訓新人，就設計達成一致，繼續曏者目標前進。
感觸還有很多，以後如果有機會再寫。不過，我決定去買本英文版回來，收藏，以後再多看幾次。
