RojerChen(ROX) CYH.2011.03.07

從我開始工作以來，常常會遇到下面這種狀況：


業務：『你來看一下規格，如果要完成這些功能，大概要花多少時間和人力，你來評估一下』。


我：『我看一下喔，如果開發的話，大概要W個月、X個人手，系統上線測試大概要Y週左右…，如果過程中遇到一些問題，可能需要Z週的時間，所以總共需要…』。


結果時程加一加，好像除錯所需的時間比開發的時間還要來的久，有說和沒說一樣。




評估專案時程，真的是很困難的一件事情，評估自己工作所花的時間已經夠難了，更何況還要評估整個專案的運作狀況。


在我一開始工作的時候，長官常常要求我們評估工作所需負責的時間，一開始不知道該如何評估，因為評估時間評估的太短或太長都不好。評估得太短，遇到一些突發狀況，沒有緩衝時間可以處理。評估的太長，又說不出甚麼東西出來，好像自己很沒效率一樣。


在本章節中，作者提出了一些想法，我覺得不錯，以及我自己的一些心得：


『要把任務分得很細』

通常一個專案或是一個功能，我會把項目細分到『天』或『半天』。如果功能太簡單了，可能只要幾小時之類的，我會盡量把這幾個項目合成為一個。如果功能很複雜，所需的時間太長，大約要『幾週』左右的時間的話，我就一定會把工作項目切細做劃分。

我們會固定每週開專案會議，監控專案的進度狀況，如果某功能要超過一週以上的時間來完成，這樣等到出問題要監控的時候，就太慢了，這樣會無法掌握專案進度。


『評估工時，加入除錯、整合與緩衝時間』


在評估一項功能所需花費的時間，我通常都會加上20%左右的除錯、測試與緩衝時間。如果是功能與功能的整合，會另外獨立出一項工作叫做『某某功能整合』。

在安排進度的時候，避免讓專案時程排得太緊，如果評估得太樂觀而沒有把除錯的時間加上去，這樣在出問題的時候，就會讓工作進度延後，也會讓專案經理無法掌控人員的調度，結果還是花費了同樣的時間在解BUG。


『紀錄最初與目前的估計』

不斷的更新專案的進度，了解目前專案進度的狀況。除了讓自己也讓專案成員了解到原本預估的時間和到專案完成的時間差距有多少，讓下次的工作能夠評得出比較接近的工時。不論是專案經理，或是專案成員都需要練習。


『時程就像積木』

當你知道整個專案所需花費的時間後，就可以清楚地了解到現在的專案進度狀況，也比較有足夠的依據來決定人員的調度，並且知道哪項功能花費多少時間在裡面，並且依狀況決定是否要『加班處理』還是『加派人手支援』。