軟體專案的啟動：三件必要事項

萬事起頭難，但是軟體專案的開始卻不很難，至少比收尾容易。


專案在開啟之前，相關人等必須一定要聚集在一起，至少達成一件事情：就是要討論專案如何開始。這個討論很多地方稱之為Kick-off會議。（專案啟動會議）。

在啟動會議結束前，就必須要能至少完成，或理解以下三件事情。如果不能完成或理解以下事項，當然還是可以開始。不過好的開始，雖然是成功的一半，但壞的開始，一定是失敗的八成。

要注意的是，這三件事情只是開始，並沒有涵蓋技術上的真正開始（例如High Level Design）

(1) 了解專案目的

一個軟體開發專案的目的，一定不會是完成某些程式碼功能。通常是帶有應用意義。瞭解其應用意義，才是真正的專案目的。在不了解專案目的的情況下，隨著專案進行走偏的機會很大。

舉例來說，也許某企業組織在一些腦力激盪之後，想要有自己的即時通訊app（類似line），並且也組織了一個小組來進行開發。而它的目的是希望企業員工在用手機的時候能有完整保密的訊息功能，而且非企業員工不可能使用。

單就以上描述而言，重點是在於(a)企業員工使用手機(b)完整保密的訊息估能(c)非企業員工不可能使用。

然而，是不是手機app並不是目的。是不是自己重頭到尾開發，還是利用現有套件也不是目的，有沒有上架也不是目的。

有些時候，專案目的不是這麼容易清楚了解，許多大組織有很多隱晦的目的。即便是人數極少的新創組織，有時候也容易把將組織目的和戰略執行方式混淆。因而，在專案啟動會議的時候，務必再三確認專案真正目的。

有一個簡單的方式可以判斷是否為真正目的。如果目的的描述，非常具體的指名特定技術，在盈利企業的專案裡，它就很有可能不是目的。舉例來說：『我們要開發一個Android APP他可以在開機的時候就自訂在背景執行，而且當發現手機的GPS位置到某一個範圍時，就寄出email』，這非常有可能不是真正的目的，而如果團隊照著進行，也許沒有大問題，但如果能真正了解目的，有可能有截然不同的開發方式。例如真正目的可能是：『我們是個高級西餐廳，需要一個行動裝置，了解某個之前的客戶，如果剛好在我們餐廳附近，我想們要通知他一些折扣訊息』。當目的和技術脫離，軟體團隊才會找到更正確地解決方式。以這個例子來說，寄email大概不是什麼好方法，在背景執行的app也遲早會被使用者發現過於浪費電而停掉。

專案目的也許隱晦，但是要再三確認，實務上也花不了多少時間。

(2) 專案設定

任何專案一定有其限制和背景因素。這些暫且叫做專案設定(setup/config)。

專案的限制有很多來源，有可能是先天限制，例如奧林匹克訂票系統，自然就有在某月某日結案的先天限制。也有可能是後天限制，例如最多能花多少經費。不過無論如何，一定有很多很多限制。在這一階段我們要了解的限制，最少要有以下這一點：在範圍，時間，成本這三個變項之中，哪一個是可以犧牲的。所有專案管理最基本的認知：範圍，時間，成本中一個專案最多只能控制兩個，細節可以參看這裡。

當然有些人可能會列出6個變項，或甚至9個大項目。但重點不在有多少變項，重點在於專案的開始就要先有認知。

專案的重要背景因素，如果有的話，也需要先行認知。背景因素有可能是限制的一種，有可能和目的有關。例如，企業目前營運狀況極為良好，是一種背景因素，他可能會讓專案遇到困難時，有額外的助力。又例如，這個軟體專案是為了新產品，而目前，在市面上已經有競爭對手：這是一個可能在不預警的狀態下，改變專案目的或者增加專案限制的背景因素。

通常只要開口多問幾次，不需要花多少時間就可以了解很多專案設定。

(3) 如何合作

專案成員如何合作的方法論有很多，但最根本的概念就是，合作的本身，不會造成合作的困難。合作本身，能讓團隊效益提高，讓1+1>2。

(a) 認知事實

團隊活動有很多事實會發生，最不好的事實就是『大部份的人都有認知偏誤』。偏誤很難完全屏除，但盡量貼近事實是最好的做法。

事實最好在一開始就是大家所先認定好，特別是困難的事實。舉例來說，專案有三個人，其中兩人才剛畢業，另一個人已經在公司工作35年，事實就是一定會有溝通障礙，技術銜接障礙等等。另一個例子：專案有三個人，其中一個人正在負責其他專案，一旦認知到這點，就一定要把此人在專案未來時間分配上，特別減少某個比率。而這減少的比率應該在這個階段就已經先認知。


(b)角色定義

許多專案管理的方法論，會對角色有各式各樣的定義，例如RACI，PMP都有各自的角色定義。然而，也許比較適合軟體專案的還是Scrum的定義。

但不管採用什麼方法論，至少有個角色一定要有明確的指名。那就是這個專案的負責人，無論是叫他PM也好，team leader也好。明確地找出這個人，讓他負責專案合作上的各種安排。

(c)工具

而軟體專案最少的必要使用工具也要在這裡簡單定義。例如使用git來作為版本控管工具，簡單的使用便利貼加上白板來作為目前進度顯示的工具。工具不見得要是某軟體，在專案執行過程中，要確定工具的本身不會變成專案的負擔，不會變成阻礙，不會耗費過多時間，更重要的是，一定不能成為某些事情的藉口。如果在專案過程中聽到有人反應：『XXX還沒做，是因為build server要執行編譯android的時候，』因此過多的指定工具只會造成問題。

(d)溝通

專案溝通最好還是以面對面為主，我個人是非常反對大型報告會議，但是非常贊成Scrum的每日站立會議的務實方式。每日站立會議作法是：每天固定某一個時間，大家聚在一個地方，每人用1-3分鐘的時間，只說明三件事情（要記得大家先說明，然後要討論是說明完之後再討論）：

   第一：上次會議到現在為止，完成了什麼事情。

   第二：接下來到下次會議之前，打算完成什麼。

   第三：遇到什麼困難。

所有人都說明完畢之後，再根據每個人遇到的困難，也許是一起討論，也許只有某幾個人討論。這樣的會議，會讓大家集中心力在之前決定好要完成的事項上，而且有兩個人在會議室裡面相談甚歡15分鐘，其他人都在看自己的筆電的情況。

如何合作有可能是最花時間去討論的項目。採用過去成功經驗，摒除失敗的經驗是最好的方式。



以上三件事情在大型專案中，也許頂多花上一兩天的時間就可以完成。最不值得做的，就是因為『乍看之下專案好像很急』而草草啟動，忽略了這三個必要事項。

---

沈思：

如何知道這三件必要事項有產生？這三件必要的事情完成後，應該有相對應的簡要文件。如果專案開始的時候，沒有簡單的一頁說明以上三件事情，恐怕表示大家沒有真正的共識，或者這些共識很快就遺忘。

但是相對的，假如在這個階段，就已經產生了鉅細彌遺地各類型文件，那麼專案成員也應該要警覺。帶領專案者，可能有很大的管理上的障礙或疑慮。也有可能這個專案的真正目的和實際上說明的不同。