◎ 本文轉載自 Blog.XDite.net。
很多人知道如何實作網站功能。但是卻不知道如何將網站成功的完工,並且如期上線。往往明明專案開始之初有不少的工期,有不錯結果的卻很少。上線前後總是一團慌亂。
其實「上線」這件事情完全是可以被掌控的。這當中有不少眉角,只是多半被疏於控制,導致風險橫生。
在回答別人幾次這樣的問題之後,我決定把我的經驗分享整理出來:
這是我認為在專案管理過程中,最重要的一件事。累積參與過幾十個專案下來的經驗之後,我發現上線前手忙腳亂的原因,幾乎都是時程的安排不當。時程混亂冒出的很多風險又沒有被妥善的管理,最後才大失火…
一般的專案進行方式,雖然都會有確切的完工期,但專案進行的方式往往會形成相當的浪費而最後造成大量的風險。
比如說一個需要 6 個月工期的案子進度通常是這樣的:
=> 完全來不及寫完程式 => 半成品上線
上線後一個月:
上線後第二個月:
上限後第三個月:
「規劃」其實絕對不是開發一個網站的最重頭項目。「施工」和「調整」才是。
傳統的專案進行方式往往會掉進一個陷阱:六個月看似非常長,於是就大膽的將大部分的時間都丟入「規劃」這個一階段,因為沒有時間壓力,於是會議也通常沒有結論,或者是 feature 發散。等到驚覺時間已大幅燃燒殆盡,再不進行開發絕對完蛋,才匆匆結束。
「規劃」畢竟是個空想產物,等到實際請美術設計頁面,又會發現很多畫面以及 UI 實際上不可能完成。
於是在這一個月,團隊又會大幅的來回修改刪除功能:直到一個勉強接受的範圍,等到視覺完工再轉交給程式設計師「套版」。
在上一個階段,粗估的一個月往往是不夠用的。因為還牽扯到往來的修改時間。而這時交出的產品 scope,也僅只限於「UI」部分有辦法被完成。
「UI」部分有辦法被完成不等於「功能」有辦法被完成。有時候畫面上一個小小的按鍵功能,背後的基礎開發工時可能要花上三個月。
最終的上線版本,因為不夠時間了,通常最後只有寫完當初規劃出的功能的 10 - 30% 。而且 Bug 還很多。(因為時間關係,只有辦法完成勉強達到 UI 操作的目的,細部細節根本來不及實作)
最後成效不彰,檢討會議上大家互相指責。但無論如何怎麼檢討來檢討去,完全沒有人會把最根本的問題朝向「規劃時間太長」,只會輕描淡寫的用「必要之惡」一筆帶過。
我的作法完全相反。如果一個工期是六個月。我會這樣分:
只有 1 個月,是否不夠時間詳細規劃功能?
完全不會。
我會在以後其他的專案管理文章解釋為什麼。