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