與熊共舞

專案管理本身就可以成為一個專業，而軟體的專案管理更是不同。

打完收工

通常業內人來看，專案管理的結果可能有準時完成，或是延遲完成，是否少了甚麼可能性，在嚴謹的理論下，應該還要有提前完成這個選項。實際上會認為實際完成的，就是還在學校裡，不知道世界是怎麼運作的。如果能夠提前完成，那預估時程就是浮報預算，你才有「提前」這回事，也可能是一切順利都沒有發生意料之外的事情，那也是提前沒錯，這一樣又回到多數老闆認為，是你預估的不準確，所以才會提前了，下次預估時程會更刪減風險的可能性，以減少預算，使得時程縮減，實務上，提前完成就不會存在了。

最佳利益

接著專案準時完成必須要很多評估準確，意料之外的事情都沒有發生，或是預估的最佳時程也不可能會盡最大努力完成，因為這是很操的情況下去做，知道不可能完成的情況下，人們也不會願意努力。在最充足的時程下，完成機率最高，可是一樣也不會讓人想努力完成，反正還有充份的時間，最後一樣還是發生延遲的可能性。最佳還是預估在這兩個時程中間，合理的結果才是實際的結案時間。

要五毛給一塊

軟體專案的風險，通常來自於五個原因: 時程延誤、需求膨脹、人員流失、規格崩潰、績效低落。其中只有最後一項績效低落與工程師有關，其他都是在初期評估的時候，就可以計畫在內，過度評估會增加成本，老闆不會答應增加未必會發生成本，但可以增加舒緩措施，常常專案要發生問題的時候，都是已經到後期，那時候再來拯救措施常會來不及，注定要延遲，事先規劃的措施可以在風險即將誕生的時候，實施處置，有規劃過，就可以知道哪些事情可能對結果會有大影響，例如實施「敏感性分析」，預估那些事情發生對專案的敏感度。

GONE GIRL

未知的事情就無法預估風險嗎，在怎麼未知，還是有已知的部分，事先調查資料可以評估未知的部分有多大，那就可以接著預估措施該怎麼做，當風險發生的時候，就要啟動防止措施，避免專案失控。

誰給的勇氣

軟體專案管理，和普通專案管理有很大的不同，就是太多的未知與風險，以及不可控因素很多，團隊裡的工程師專業程度也可以大大影響成敗，這些都要平實的資料收集，下次做評估的準確度才會漸漸提升，再加上現在嵌入式系統也漸漸流行，管理起來更多 了其他變數，嵌入式系統很重視經驗值，影響成敗可以產生十足的差異，換人之後可能專案就此快速完成，或是就此失敗，通常團隊都是傾向完成專案，而非失敗終結專案，繼續拯救之下，會投入多大的成本直到老闆出現制止或限制成本的運用去拯救專案，使得成員必須採用低成本將舊的方式做出收拾。這都不是好現象。例如嵌入式專案還多了勇氣的部分要加入評估，時常要做新功能，沒有勇氣就會傾向用老方法，做出沒有創新的效果，帶著勇氣做創新應用的時候，成功了會帶來市場上的特殊性，失敗了就要面對上級的責難，或是無法收拾的殘局，時間久了可能還會消耗人力、人才，變成爛攤子對誰都不好。

透抽小卷

結論來說這是一本好書，不管過了幾年都有很多地方值得學習，第一次對於風險可以這樣看待，了解風險是甚麼，即使他很抽象，書中講清楚這個抽象，接著學到面對與處理方式，即使提風險是多數老板不喜歡面對的事情，真切願意面對風險，才能讓專案順利的完成他。

買書這裡
https://www.books.com.tw/products/0010888540