其實前兩天就把這本書買回來了，由於工作關係，其實到了現在也才看完三分之一而已。不過還是覺得可以先把一些心得做一個簡單的整理。首先先來提提這本書的作者吧。Steve McConnell 已經被公認是軟體研發裡面相當具有經驗的人，而他所寫的Code Complete更是聖經中的聖經。不過我個人比較喜歡的書則是Rapid Development: Taming Wild Software Schedules (Paperback)，因為這本書裡面利用故事講解了許多關於軟體開發上會遇到的現象與問題。
回頭來談談買這本書的原因吧，主要是因為最近組織調整的關係，原本我們是負責主要軟體研發與設計的部分(當然有所謂的除錯)。工作調整後，現在則專心在做專案管理與主要產品的控管部分。套句主管常說的話，除錯的能力人人都有，但是專案管理的能力可以讓你一輩子帶著走。不過仔細下去開始做，每個同事都是做得唉唉叫。比起以前硬著頭皮下去改程式碼、修臭蟲，原來專案管理與軟體研發的時間管理是更佳的困難。以前只要開程式開發工具毛起來去解問題，解不出來就加班到死~其他人也跟著你拼到死把產品交出去。現在則要好好的安排各種研發的時間與測試需要的時間與風險管理。如果需要別人加班，還需要有相當大的理由去說服人家~ 你當初在專案管理的時候怎麼沒有把加班排進去你的計畫中。除此之外，每天的報告與分析計畫更是少不了。不過~ 可能是以前做整理與分析資料的工作習慣了，我反而相當適應這樣的工作。
這本書~ 就如同他的標題一樣，主要就是講解如何去對你的軟體開發去做”評估”。怎麼樣才是一個好的評估呢? 在他的第一章先解釋”評估”與”計畫”的關係。(Relationship between estimation and plan)。裡面開宗明義開始解釋一下這本所提到的評估是甚麼，還有不要把評估當成是計畫。因為評估的時候往往是沒有了解全部資訊的，而計畫才是。(當然我們往往犯下錯誤~ 在沒有全部消息的時候就開始做計劃、或是被要求做計劃)。
接下來的第三章~ 就開始來談~~ 精準評估的價值 (The Value of Accurate Estimation)。 有專案管理經驗的人都知道 過分評估(Overestimation)與不足評估(Underestimation)的痛苦。 往往銷售端的人由於客戶壓力就會有不足評估產生出來的行程。(通常是~~好好！！ 明天就給你修好的版本）（好好好！！ 下周一這個功能就可以做完！） 這些不足的評估造就了我們執行者(身為PL或是PM的人)執行上因為又過度不足的評估造成相當趕的狀況。雖然往往最後都是會延遲~ 但是銷售端的人礙於客戶壓力~ 也不斷的上映一樣的戲碼。
不足評估造成的影響可能有哪些?專案延遲~ 銷售業務可能得去道歉、可能得重新評估一個新的時間、甚者~ 可能給了一個完全無法正常使用的軟體給客戶~造成客戶困擾而生意掉單。過分評估會造成的影響相對的小: 工程師因為一個相當久的時程安排~ 而開始偷懶~ 到最後幾天才開始隨便做。 但是相較於不足評估，過分評估的的影響很明顯少了很多。