專案與電車(一)

考試完了，壓力沒有了，我也可以輕鬆的去玩電車GO了。玩的時候還是會想起做專案的時候，也給我發現了專案和駕駛電車有很多相似的地方。

我玩的是電車GO Professional 1。在遊戲中，由起點到目的地，你可以用不同的路線和不同的電車前往。不同路線要停站的數目也不相同，不同電車有不一樣的行駛速度，你不可以用同一個方法來駕駛不同路線。

專案管理也有不同的時間安排和不同的組員。專案管理的作法可以比喻為不同的路線，在專案剛起步時，我們會先計劃專案的路線，對內有checkpoint檢查進度，對外會有Prototype和Release給用戶看看。checkpoint可以比喻為通過站，Release可以比喻為停車站，這樣我們便可以看到整個專案要用多少時間了，正如要行畢全程所需的時間。以下是兩個不同路線的時程表:

停車站: 10個 行車時間: 31分鐘

停車站: 3個 行車時間: 19分鐘

很多人一看到右邊的是特快，當然會選右邊了。沒錯專案選右邊的入作法會較快，但是Release較少，做出來的軟體便有可能和用戶所想的有較大出入了。我曾經看到有人乘搭特快巴士，但不是要去很遠的地方，結果過了快速公路才知道自己多搭了，轉車折返又要花不少時間和錢了。如果那位乘客乘搭的是普通線，多搭了還可以行回去的。做專案也是，如果到了後期才知道自己所做的完全不是用戶想要的，你要付出不少代價的。因此，如非預先取得詳細的軟體需求，否則還是選左邊的，雖然要花上更多時間，但是做出用戶想要的東西出來更重要呢!

一個專案要啟動，然後就是不停的做，「收尾巴」也要收得好。這三個程序正是由一個車站到另一車站的過程，即是開車、行駛和靠站。沒有「收尾巴」便不算是停站來了，當中的駕駛過程便留待下回分解了。

到底我的專案選「快速」還是「特急」會比較好呢?這樣要看軟體需求定義有多詳盡了，如果專案不能取得詳盡的軟體需求，選「快速」比較好，時間不太久又有多點驗證需求的機會，不怕「行錯路」。如果你對用戶十分了解，你可以從他所說的取得大部份軟體需求，而且用戶只有很少時間看看專案，不用擔心搭錯車，這時可以選「特急」，做一個「點對點」的專案便可節省不少時間了。

在我的學習生涯裡，沒有一個專案是「快速」，因為沒有一個專案是可以中途「收尾巴」然後再開，不是專案太短就是課程的要求不適合以「快速」形式行駛。Final Year Project、Project 2B是「特急」的專案，每星期都會給老師過目，其他的是連「特急」也不是。即是甚麼?就是沒有checkpoint的專案，沒有checkpoint的專案該怎樣做?To be continued