網站程式上線前需要準備的事（一）

◎ 本文轉載自 Blog.XDite.net。

很多人知道如何實作網站功能。但是卻不知道如何將網站成功的完工，並且如期上線。往往明明專案開始之初有不少的工期，有不錯結果的卻很少。上線前後總是一團慌亂。

其實「上線」這件事情完全是可以被掌控的。這當中有不少眉角，只是多半被疏於控制，導致風險橫生。

在回答別人幾次這樣的問題之後，我決定把我的經驗分享整理出來：

第 1 件事：界定時程

這是我認為在專案管理過程中，最重要的一件事。累積參與過幾十個專案下來的經驗之後，我發現上線前手忙腳亂的原因，幾乎都是時程的安排不當。時程混亂冒出的很多風險又沒有被妥善的管理，最後才大失火…

傳統瀑布式專案進行法：寶貴的時間被大量的浪費

一般的專案進行方式，雖然都會有確切的完工期，但專案進行的方式往往會形成相當的浪費而最後造成大量的風險。

比如說一個需要 6 個月工期的案子進度通常是這樣的：

• 花了 3 - 4 個月無盡的訪談需求
• 花了 1 個月請美術設計視覺與介面，以及反覆修改
• 最後剩下不到 1 個月請 RD 寫程式

=> 完全來不及寫完程式 => 半成品上線

上線後一個月：

• 到處都是 Bug
• 發包方抱怨
• 使用者抱怨

上線後第二個月：

• 終於寫完當初規劃的程式
• 終於修完大部分的 Bug
• 使用者早已認定這是個未完工的網站，不再來訪

上限後第三個月：

• 因為網站規劃不良，使用者對這個網站不感興趣
• 因為網站規劃不良，預計的成效沒有出來
• 還有資源 => 繼續籌畫下六個月的改版
• 已無資源 => 死城

「規劃」從來不是最重要的事

「規劃」其實絕對不是開發一個網站的最重頭項目。「施工」和「調整」才是。

傳統的專案進行方式往往會掉進一個陷阱：六個月看似非常長，於是就大膽的將大部分的時間都丟入「規劃」這個一階段，因為沒有時間壓力，於是會議也通常沒有結論，或者是 feature 發散。等到驚覺時間已大幅燃燒殆盡，再不進行開發絕對完蛋，才匆匆結束。

「規劃」畢竟是個空想產物，等到實際請美術設計頁面，又會發現很多畫面以及 UI 實際上不可能完成。

於是在這一個月，團隊又會大幅的來回修改刪除功能：直到一個勉強接受的範圍，等到視覺完工再轉交給程式設計師「套版」。

在上一個階段，粗估的一個月往往是不夠用的。因為還牽扯到往來的修改時間。而這時交出的產品 scope，也僅只限於「UI」部分有辦法被完成。

「UI」部分有辦法被完成不等於「功能」有辦法被完成。有時候畫面上一個小小的按鍵功能，背後的基礎開發工時可能要花上三個月。

最終的上線版本，因為不夠時間了，通常最後只有寫完當初規劃出的功能的 10 - 30% 。而且 Bug 還很多。（因為時間關係，只有辦法完成勉強達到 UI 操作的目的，細部細節根本來不及實作）

最後成效不彰，檢討會議上大家互相指責。但無論如何怎麼檢討來檢討去，完全沒有人會把最根本的問題朝向「規劃時間太長」，只會輕描淡寫的用「必要之惡」一筆帶過。

我的方法：從後面倒回來推算時程

我的作法完全相反。如果一個工期是六個月。我會這樣分：

1. 什麼時候要上線：上線前 1 個月前要 Feature Complete，留足夠的時間進行各樣測試和修復 bug。（剩下 5 個月可以用）
2. 寫程式要花多久時間：寫程式要花多久時間是不一定的事，但是可以粗估不出包的時間大概是 2 - 3 個月，可以粗抓 2.5 個月。（剩下 2.5 個月）
3. 視覺設計要花多久時間：畫面設計要花多久的時間也是不一定的事，但是可以粗估不出包的時間大概是 1 - 2 個月，可以粗抓 1.5 個月。（剩下 1 個月）
4. 是的。只剩下 1 個月時間可以開會、規劃、畫草圖。請不要浪費時間。

只有 1 個月，是否不夠時間詳細規劃功能？

完全不會。

我會在以後其他的專案管理文章解釋為什麼。

You may be interested in the following articles:

• 網站程式上線前需要準備的事（五） - 2012-06-25
• 網站程式上線前需要準備的事（四） - 2012-06-08
• 網站程式上線前需要準備的事（三） - 2012-05-24
• 網站程式上線前需要準備的事（二） - 2012-05-13