人月神話這本書，於2年前在台北工作時，就有買來看了，不過當時真正寫程式接觸專案也才1年多，看了也看不懂內容在寫什麼，什麼焦油坑???，完全看不懂且沒感覺……看完前2個章節就丟給我同事，2年
因為到元智讀書，工作轉換到桃園，接觸了2個不難的專案，卻如同第一章焦油坑壁畫，雙雙陷入焦油坑中，專案遲遲不能結案。台北公司的人數與桃園公司人數相當，不過台北做的專案是千萬元，有自己的核心技術，專案大多能順利完成；而桃園做的專案都屬於網頁建置，無特別的核心技術，有案子就接，內部技術人員不能處理就外包。
於桃園工作期間遇到問題常常會思考要是台北公司老闆會如何處理，而我又會如何處理!!雖然時常建議公司，不過很可惜的主管都聽不進去!!以下整理出在看人月神話此書時，對印到在桃園工作期間專案的感受，雖然不像書中所提的IBM那樣上千人的大型專案，不過也不因該，因為是小型專案而忽略了很多重要的因素：
1. 團隊角色錯誤
如第三章提到外科手術團隊，每個團隊都有其專屬腳色，當一個無程式經驗的工程師，放在開發系統核心架構、共用元件時，能預期的此專案的架構當然不構完整，架構、共用元件很多地方都是寫死，無法應付客戶多變的需求，造成事後整個系統需要重寫，所花的時間金錢更是可觀，除了每個團隊都要有其專屬角色，專屬角色是否挑對人，這也是相當重要的。
2. 客戶需求不明確，導致系統無整體性
當初由於時間緊迫，也未確實與客戶做需求確認，導致完成系統後，客戶才提出修改需求，如A功能流程變更、B功能加個按鈕…等，真的就如同第五章的第二系統效應，那張圖真的很貼切，原本設計好的系統，加一點點，
加一點點，最後真的變成ㄧ大坨，而且整個專案失去控制。
3. 系統設計欠缺整體性
系統多人開發，每個人對於功能設計、按鈕設計、資料庫欄位設計、甚至SQL語法、程式寫法皆然不同，若無整體性設計原則，到頭來整個系統有5、6種設計模式，維護也很頭大。
記的台北公司在專案開始前，連同程式內的變數、方法……等都列出規則文件，好讓ㄧ同開發的同事有ㄧ致的標準，事後維護也不用找原來的開發者；桃園公司就真的亂七八糟了，系統到現在一大堆放著沒有用的程式碼及SQL語法，同個功能卻有2種以上的設計方式。看到第四章本書主張系統設計時，要有概念整體性，我想除了系統設計，專案整個執行過程中都因該有許多規則，並建立文件來輔助專案的整體性。
4. 樂觀
本書第二章文章中提到【樂觀】的程式設計師，無可否認的當然是有些程式設計師很樂觀，認為自己的程式沒有錯誤，或者如同書中提到最後一個錯誤剛剛被我找出來囉!
但是我發覺也有很多樂觀的主管，常常對著屬下說這個功能有這麼難嗎??不是這樣做就好，唉阿!!這個功能你半天就可以寫出來啦!!整個系統你一個月就可以完成啦!!真不知是主管天真，還是硬ㄠ你做不出來你一個月不要回家…=.=”
一個專案若單單只考慮以人月來做評估，譬如一個專案1個人要做6個月完成，那6個人做一個月就一定完成嗎???這個答案當然是”No”， 人與人相處需要溝通，專案執行最基本的當然是人與人的溝通，在專案中有太多不定的變數，並非多幾個人，專案就一定能更快執行完畢，能否有效的溝通、能否有效解決專案中所出現的問題， 需要考慮的不單單只有人月；相信還是有很多人（豬頭老闆、呆呆主管）的答案還是”YES”，他們真的該好好看看人月神話啦!!!所以專案評估只用人月是不精準且容易失敗，此書取為人月神話就是告訴大家以人月來評估專案那真的將會是一種神話啦~~~
本書中我最喜歡的一段並非作者所寫的部份，而是推薦序二，科技在怎麼變，人還是人 - 盧希鵬 所寫的一段，摘路如下「企業中如果以人月工時來估價或是來算成本的話，常常無形中嘉獎了庸才。同樣的程式，聰明的程式設計師可能花了4個鐘頭就寫完，庸才程式設計師可能要花12個小時，下班寫不完，還要加班4個小時才完成。同樣的工作，反而多領了加班費。許多時候，人月所代表的不是專案大小與成本多少，更是程式設計師的能力。」，非常認同這段話，
並非我能力超強，而是我不喜歡加班，尤其在假日，通常我都會利用正常上班時間就把工作作完，除非真的差很多，當然自己乖乖留下來完成；此段話令我想到，也有很多老闆喜歡看自己的員工做事做到很晚，當然也有員工怕比老闆還早走，就算作完事情也不敢走，或者事情就慢慢做，因此一個留的比一個晚，何苦那麼辛苦呢!!
