你真的知道專案進度嗎？

只要是從事程設式設計相關工作的人，必然曾經參與某專案(Project)。專案的大小不一而足，有些只有幾天或幾週，有些橫跨數年。

如果有幸負責專案管理，則無論規模大小，掌握進度是除了管理利害關係人期望之外的第二重要的事情！！而實際上，要管理利害關係人期望的最好方式就是能有效掌握真實進度。

「掌握進度」之後，才能調整應變可能發生的意外，降低風險。


只要看軟體專案進度的「掌握方式」，就大致可以判斷一個專案經理的「本職學能」到什麼程度。

一個好的專案經理，可以單靠自己，就能足以掌握專案進度。

一個普通的專案經理，可以利用流程，規範，加上開發成員的協助在一個合理的時間範圍內，掌握專案進度。

一個很爛的專案經理，會利用各種會議，各種形式文件的填寫(WBS之類)，直接或者間接的資訊，花很多時間，仍然不能掌握專案真實的進度。


很遺憾的是，好的專案經理很少，好的軟體專案經理，更是極端的少。因為他同時需要具備技術能力，透悉問題的能力，以及有效的專案管理能力。

要點一：以時間為單位

非軟體專案管理上，掌握進度的單位有很多種，例如「以執行預算」或者「實獲值」來掌握進度。（請參見PMP相關網站)

以軟體專案而言，「時間」才是真正掌握進度的單位。

當詢問負責的程式設計師：「A功能進度如何？」，而他回答「只剩下UI整合，加上DB欄位定義調整，就快好了」。這樣的回答，對於掌握進度幾乎完全沒有意義。因為，該程式設計師可能在A功能花了1天，然而UI整合與DB欄位定義調整，可能還需要另外花上3天，換言之「就快好了」根本不是真的，基本上只完成了25%。但該程式設計師並不是故意要說謊，因為或許最難的就是那25%。

程式設計師若以困難度為考量，進度就像下圖，功能完成之後，就「快要好了」。

但如果以實際時間進度為考量，則如下圖，功能完成之後，只完成了25%。離「快要好了」有很大的距離。

大部份的軟體工程師，著重於困難度。這並非不正確，只是專案管理在掌握進度時，實質進度必然是以時間為考量單位。即便「這件事情很簡單」，也必須要考慮「簡單的事情還是要有人去做」。

要點二：產出的事實

直覺上，大部份的產出當然是程式碼。實務上，非程式碼的產出許多時候會超過想像中的多 -  特別對於比較沒有專案管理經驗的人而言。

基本情況

最基本情境是，根據規格要完成功能A。一開始，程式設計師寫好了程式碼，並且自己編譯(compile)並簡單測試之後，簽入(commit)到版本控制系統中，並且和其他相關程式碼合併(merge)之後，整合成新的版本，並且新的版本經過QA測試後也沒問題。這個功能A就算完成。

在這個情境中，寫程式(coding)可能佔了70%的時間，另外merge以及測試可能佔了另外30%的時間。

專案經理要掌握的「事實點」在於：整合成新版本並經過QA測試後也沒問題，至此，功能A才算完成。

進階情況

在一個稍微複雜的專案裡面，根據規格要完成的某任務，實務上可分為「功能A」與「功能B」。一開始，幾個程式設計師分頭完成自己負責的功能，並分別自己compile並簡單測試之後，功能A與功能B就commit到版本控制系統的不同版本線(code line)。此時，QA分別進行測試，沒問題之後，協調某人「分別」合併功能A與功能B到主線(main line)並且整合成新版本。在整合過程，或多或少有需要修改的程式碼，也許在合併工能A的時候沒問題，但是在合併功能B的時候有出現問題，並也修正完畢。最後新的版本經過測試也沒問題。至此該任務才算完成。

專案經理要掌握的「事實點」在於，最後新版本經過測試也沒問題。至此，某任務才算完成。

但是，這和基本情況不同的是，整個過程很長，從數天到數週都有可能。coding本身可能僅佔50%。而合併，測試，在合併，修改等等可能佔了另外50%的時間。

與前述要點一相同，專案管理者要能掌握實際上的進展，跟「未來還需要花的時間」。在複雜的情況中要掌握，除了最後的產出事實之外，中間的進度掌握，需要靠專案管理人員對專案本身實務的了解。

專案進度的掌控，大部份是由專案經理個人獨立可以完成。其中，技術上的要素就是能否「判斷產出的事實」

而以軟體專案為例，專案管理者如要能判斷產出的事實，必須要能做「自己獨立」做下列幾件簡單的事：

1. 在版本控制系統中(git, p4, cvs等)，找出過去一段時間的所有commit過的程式碼變更，誰去變更，為什麼變更。

2. 在最近的新版本測試中，看到哪些新功能確實增加

3. 自行檢查目前bug的清單，並且找出幾個關鍵的bug



假如你是專案管理人員，而你不認為上述事情是自己應該獨立進行，或者你認為上述事情會花太多時間，


請參見下節：除去迷霧。

要點三：除去迷霧

許多「非技術背景」的專案管理人員，常常用各式各樣的大大小小的會議，來獲取專案進度的掌握：每天早上例行會議，每隔兩天來執行bug review，每個禮拜來討論整合進度...開會的本身並不會「加速」專案進行，過多的會議，肯定會「拖累」專案進度。

如果你是一位主管或專案經理，而你迫使專案成員每天花超過10%的時間(也就是40分鐘左右)在正式的會議上，並且只是為了呈報「目前進度」。那麼，你實在是個很糟糕的主管，要麻，你就盡快辭職，要麻，盡快提升自己的專案管理能力，否則你的存在只是浪費大家時間。

了解目前專案的進度，等於是除去迷霧，看清事實。除去迷霧的方式，必須要是「貼近事實」與「清晰的技術檢視」。

貼近事實

事實有時候很容易了解。例如：app要可利用facebook帳號登入。此功能容易判斷有完成，或者沒完成。

但有些時候事實很複雜。例如：某程式設計師宣稱，app要可以利用facebook帳號登入，他需要花12個工作天完成。12個工作天到底是長還是短？如果覺得太長，是因為寫程式的人能力不足？還是既有的app過於複雜，所以要加任何新功能都很難？


按部就班的貼近事實是讓該程式設計師先行「分解」這12個工作天。讓專案管理人員了解，他打算如何利用這12個工作天。

如果該程式設計師說「我這個是大概估計，12天就拿來做這一個功能阿，你還要我花時間去分哪天做什麼喔！我哪來這個時間」。這表示事實是，12天根本只是沒有基礎的猜測，他可能22天才完成，也可能2天完成。

絕大部分軟體專案，程式設計師的某行動完成都應該至少可以以「天」為最小單位，(也可是以「小時」為單位，不過太細的單位也會造成不必要的麻煩)。

超過2天估計，就應該可以分成「兩個以上的事情」，超過12天的估計，應該是建立在至少6個以上的某行動完成。


不能分解行動，表示沒有計畫，也對此任務沒有任何基本了解。

假設該程式設計師將app如何利用facebook帳號登入分解為以下工作：

(1) 修改UI: 3天
(2) 登入的程式碼: 7天

(3) 測試: 2天


專案經理應該要能看出，這樣的WBS其實完全是在應付專案經理，對貼近事實沒有幫助。他等同是一樣沒有了解任務。

如果無法將此任務交給別人，專案經理應該參與「計畫」與「分解」的過程。和程式設計師一起坐在某台電腦前面，將android studio打開，了解登入在哪邊加icon，如何到facebook取得App ID，facebook sdk如何使用。

對於有技術領導背景的專案經理，頂多花上一小時，就應該至少可以分解此任務如下：

(1) 到facebook developer網站了解sdk：1天
(2) 申請App ID以及了解相關規定：0.5 天
(3) 登入Icon要和美工討論實作方式：0.5天
(4) 執行登入，取得session：1天
(5) facebook帳號與其他帳號在db處理的不同：2天
(6) 與QA討論測試方式：1天
(7) QA測試：1.5天
(8) 其餘模糊規格的討論，例如是否可登出：0.5天

加總起來可能僅需要8天。但重點不再於天數減少，重點在於此計畫已經破除進度迷霧。當這個計畫開始執行，到了第三天，如果該程式設計師已經開始撰寫登入程式，那麼表示進度和預測相同，但如果他還在申請App ID，表示進度落後，專案經理需要調整進度，或找人幫忙。但無論如何，絕對在計畫開始執行的前期就已經知道如何處理問題，而不是到12天之後，突然發現根本無法完成。


(Android如何利用facebook帳號登入，請參考這裡)

清晰的技術檢視

前述的app利用facebook登入，專案經理之所以能和程式設計師一起坐下來定好比較清晰的時間，其首要條件在於具備清晰的技術檢視能力。

簡要的說，能區分技術難度，區分使用該技術對於專案的影響，以及，使用技術可能產生的風險。清晰的技術檢視能力，會有效提高對整個產品或者專案的洞察力。雖然，洞察力可以經過訓練磨練取得相關經驗，但實質培養卻需要有意識地進行。

技術檢視需要對技術的深度與廣度，每個專案經理所需要的技術能力各有不同，以下有個簡單的軟體專案經理自我問題清單，回答「是」就得1分。

低於5分表示是沒有技術檢視能力的專案經理。
高於8表示是罕見的擁有技術檢視能力的專案經理。

* [Yes/No] 你可以自己從版本控制系統中了解專案目前大致規模：(行數, 檔案數, 平均每工作日增加的程式碼數量)，無須依靠其他專案成員嗎？

* [Yes/No] 你可以自己找出哪些程式設計師的程式碼常常會出現bug，無須依靠其他專案成員嗎？

* [Yes/No] 你每一週會隨意抽出幾個程式碼簽入(check-in)看看有沒有明顯的問題，無須依靠其他專案成員嗎？

* [Yes/No] 你會手動編譯專案，無須依靠其他專案成員嗎？

* [Yes/No] 你隨時知道目前技術文件(程式碼註解, api 手冊, 使用手冊)撰寫的實際情況？

* [Yes/No] 你知道專案成員實際花在專案的時間

* [Yes/No] 當某個進度完成時，你可以自己檢查該進度是否真的完成，無須依靠其他專案成員。

* [Yes/No] 你會用專案開發的主要程式語言撰寫工具用程式（例如查閱系統log之類），無須依靠其他專案成員？

* [Yes/No] 你能自己估計團隊能力和團隊完成某模組的大概時程，無須依靠其他專案成員？

* [Yes/No] 你能單靠記憶，繪出目前專案個模組之間大概關係，無須依靠其他專案成員？

給不寫程式的人：發展手機APP事業的三步驟

有智慧型手機的人，都會使用某些應用程式(APP)。

你一定也有常用的APP，多少也有自己想要的功能。也許你覺得自己有一些創新的APP想法。或許，你覺得現在用的Line總是有些地方很不滿，你覺得只要照你的想法去做，一定會讓使用者更滿意。

但是，也許你完全不會寫程式，或者雖然是資訊科技背景，但是對於手機應用開發缺乏經驗，也或許只是沒時間學... 最後自己總是覺得無法實現想法很可惜。

其實APP和一般的電腦應用程式不同，不會寫程式的人，其實也可以創造自己的APP，加入這個競爭激烈，但卻很有利可圖的市場。

如果規劃得當，是一個能以極少量成本，兼職創業的好方式。更重要的是，如果規劃得當，這是個極低成本的lean start-up，可以讓你多方嘗試可能性，但不用負擔失敗的風險。

不會寫程式，或者沒時間，但仍能發展自己的APP的成功案例是很常見的事情。例如airbnb，uber等。

事實上，有許多創業家一開始就選擇踏入手機市場，就是因為APP是能在極端有限的資源下，實現自己的創新想法的最容易的選項之一。

主要原因可能是：

在技術上：兩大主要智慧型手機陣營：iOS和Android都盡可能APP的開發方式標準化，簡潔化。目的是在於吸引更多開發群眾。而市面上也有太多工具，可以在某種程度上產生APP，例如appopus.com 或 appsgeyser.com 都可以把文件轉變成APP。技術上來說，等同於擁有一個可以個別銷售的電子書APP（註1）。換言之，APP的製作有越來越簡單的傾向。

在環境上：智慧型手機的市場遠比傳統電腦來得大，而進入市場的門檻極端的低。根據實際的經驗：以電子書而言，撇除掉撰寫的成本，僅就上架與行銷可能只要200美金。如果是具有傳遞訊息(類似Line)加上社群功能(類似facebook登入等等)，大概只要準備700-1000美金。如果是多媒體播放(類似youtube)則僅需要800-1200美金。而以上的參考數字，都涵蓋完整的完成具有完整前後端功能的APP，上架以及基本行銷。換言之，市場環境，大幅傾向低成本門檻。



在實際經驗中，任何人只要能學習以下三步驟，一定可以開發APP並藉此開創事業。（註2）

三步驟：想法具體化，找到正確的人完成APP，進入市場。

步驟一：將想法具體化

將想法具體化：是指把自己對APP的想法盡量用文字以及圖形表達出來，並且對於APP決定好基本的定義。

表達APP的方式有很多。首先要簡單地寫下自己的想法：例如一個可以互相傳遞即時訊息的APP（類似Line)但如果對方沒即時看到，就改用傳統手機訊息傳出。

接下來，使用網路上免費的畫圖工具，例如invisionapp.com 或者 fluidui.com，將自己的心理的想法具體化。

簡單的通訊APP(類似Line)的設計，練習個幾次，任何人都可以做簡單的設計。

想法具體化不是只有手機流程設計。最起碼還包含兩件事情的具體化：誰是使用者，以及：定義成功。

誰是使用者？

在你的心目中，用有哪些屬性的人會使用這個APP：就是所謂的市場區隔。雖然他可能會改變，但在這個階段，你需要自己具體化一個清楚的使用者描述。例如：「在台灣，25-35歲，單身男性，就業中，未與父母同住，使用Android手機」。

如果你的目標客群很大，例如：「在台灣，使用Android手機」。也並非不可，但是在之後進入市場時，可能不容易看到基本行銷的效果，或者需要極大的努力才能看到行銷的效果。目標客群越清晰，越容易看到行銷的效果。

如何定義成功？

在你的心目中，當APP完成放到市場上，經過3個月，達到哪些事情才算成功？自我具體定義成功，是發展APP的重要基礎。

成功可能是獲利。例如，假設APP是要收費，或者間接收費(例如廣告)，上架經過3個月，實際營收達總額達到1000美金就算成功。

但所謂成功，更有可能不是設定為獲利。例如，APP是免費，而且也沒有廣告，但上架經過3個月，希望實際使用者達到1000人。因為很多APP一開始是希望有大量使用人數，等到夠多人使用時，再考慮獲利模式就變得很簡單。（例如Line是免費使用，一開始是沒有廣告）

有創意的定義成功，能夠讓不寫程式的人，更容易看到手機APP的事業的可能性。例如：APP是免費，也沒有廣告，但上架經過3個月，希望所有已經安裝的使用者，解除安裝的比率低於15%，而且每天使用這個APP的比率要超過65%。換言之並不在乎多少人使用，只在乎這些使用者是真心的黏著在這個APP上。

步驟二：找到正確的人完成APP

好像很明顯，你需要找人幫你寫程式。

但是，其實你真正需要的是：找人幫你完整完成開發APP這件事情。

完整開發APP指的是：

(0) 將想法具體化   <- 這一點在步驟一中，一定已經完成。
(1) 先把APP的流程決定好
(2) 根據流程畫出APP的樣子
(3) 加上自己認定的顏色，圖樣，Logo
(4) 根據設計，撰寫程式
(5) 測試程式，確保品質大致沒問題
(6) 將APP上架：放到googleplay或者applestore
(7) 利用各種行銷方式，讓使用者下載，安裝，使用APP。
(8) 每一段時間收集相關資訊，了解此APP是否成功。


(1)-(3) 就是APP的設計，完成APP設計之後產生出APP的mock-up。這件事情可能在步驟一中自己做，也可以找人來做。

一般人都直覺地認為，「找人去做」表示執行(4) (5) 這兩件事情。但其實你真正需要的是(1)-(8)都需要有人執行。

找到正確的人的方式有很多，首先，先確定自己(1)到(8)能做哪些事情。然後，剩下的事情都要「委外開發」。

委外開發的最直覺方法，就是到外包網站上招標。例如：upwork.com ，guru.com， freelancer.com。外包的價格差異很大，而且軟體產生的品質和價格沒有直接關係。關於如何招標尋找正確的廠商，請參考這裡。

基本的參考數字：一個類似line的訊息傳遞APP，開發需要120-200美金之間，如果要涵蓋基本的UI/UX設計，另外需要50美金，如果要含品質測試以及上架，另外還需要30美金。也就是整體大約200-300美金可以完成一個還不錯的APP。（這個數字不適用於遊戲APP）

委外開發的其他常見有：找有技術能力的志同道合的好朋友；找學校的相關科系學生專案，等等。不過，這些常見方式，都需要一段時間的磨合，以及一段更長的時間的互相體諒與了解。

步驟三：進入市場

進入市場包含「上架」，「基本行銷」。想要長期留在市場，還得進行「維護」以及「未來計劃」。

上架：

完成APP之後，當然就是要進入市場。進入市場第一步就是將APP上架。如果是Android，自然就前往googleplay，如果是iOS，就去applestore。

「上架」需要一些步驟，對於非資訊科技背景的人來說，可能稍微困難，因此，在步驟二：找到正確的人完成APP的階段，必須要把上架當作工作的一部分。

Googleplay上架請詳閱這裡。Applestore上架請詳閱這裡。強烈建議不要看市面上的書籍，或者參考某些部落格的文章來當作上架教學。因為，這些書籍文章可能都是「過期的資訊」。使用官方文件，作為上架的使用指引，才不會浪費自己的時間。

基本行銷：

不過，上架只是讓市場有機會看到你的APP。這個世界上有近千萬個APP存在，要讓使用者能真的下載使用某APP並不容易。因此所謂進入市場，必須考慮基本行銷。

行銷可以很簡單，也可很複雜。最基本的情況是：你需要盡可能讓很多人知道有這個APP，下載這個APP來使用，如果APP需要付錢才能使用，則還得包含說服使用者鼓起勇氣付錢。

最最最基本行銷的過程是：找到目標客群，針對客群送出訊息，等候以及檢視結果。

找到目標客群：

定義目標客群應該是在第一階段完成的事情。這階段的目的是找到目標客群的「資訊傳遞」方式。最簡單的方式，是透過小型行銷公司，直接把你要找的目標客群的email找出來。只要你的定義夠清楚簡單，可以在前述的外包網站，找到小型行銷公司，以30美金的價格，取得大約500個大約目標客群的email。或者，也可以用15美金的價格，送出1000個目標客群的潛在facebook貼文。如果願意在行銷投入更多的資金，可以用200美金，購買一個月的google ad，讓自己的APP廣告出現在某些google adsense能抵達的範圍。

針對客群送出訊息：

取得email之後，可以利用現有的email行銷軟體。常見的像是mailchimp.com，klaviyo.com或者zoho.com，送出廣告信。信中當然就是這個APP的介紹與連結，還有一些說服別人使用這個APP的方式（例如抽獎活動之類）

email 行銷是很老套，但也由於是老套，所以很容易看到效果：例如多少人有打開email，多少打開email的人真的有下載APP。

如果是facebook行銷，可以花15美金，送出1000個目標客群的潛在facebook自動貼文。也可以花60美金，雇用虛擬助理，以人工的方式，逐一在潛在的facebook粉絲頁或個人頁，貼上獨一無二的訊息。關於虛擬助理，請參考這一系列文章。

如果是google adsense行銷，或其他網路廣告方式，預期每個月，可能會花上200美金。

但無論如何，手機APP事業的基本行銷費用，其實並不高。盡量利用前述的免費或者簡單的方式。不會超過200美金就可以達到某個程度的效果。

檢查結果：

等候一段時間，檢查看看APP的成功定義是否有被滿足。

如果你的成功定義已經被滿足。那麼恭喜你：你的APP是千萬中選一的好APP。你的APP事業發展在未來可能輕而易舉。只有極少部份的情況，是可以在一開始就這麼順利。
如果你的成功定義，沒有被滿足。那麼還是得恭喜你：你知道過去的做法一定某處可以被改善。根據手上有的資料，回溯之前的過程，找到可以改善的點，加以修改，然後重新觀察。一半左右的APP是落在這個情況。重點在於，如何根據現有資料修正APP或者修正基本行銷方式。

如果你的成功定義，不但沒有被滿足，而且實在差距太遠。那麼還是得恭喜你：因為你只花自己一些思考時間，以及500美金左右的成本，就證明某個想法在目前不可行。目前你的損失很小，可以再多嘗試其他主意。更重要的是，簡單而低成本的經歷失敗的「失敗經歷」極為難得可貴，是創業成功的不二法門。請參考確保創業成功一文。

---

參考： 

發展自己的APP事業，看似複雜，其實就是這麼簡單的三步驟。當你了解這些步驟，甚至可以把整件簡單事情，交由專門協助產生POC(Proof of concept)的企業來處理。

而你自己，只要專注在於「出個好主意」就好。

---

註1：如果你寫了一本電子書，可以在亞馬遜銷售，也可以在其他APP管道銷售。那為什麼需要自己獨立產生單一電子書APP？有很多可能：例如你想單獨獲利，不想讓各類銷售管道分享微薄的利潤；或者這是免費電子書，你想要免費分送，因為裡面可能有置入性行銷的訊息等等。

註2：開創APP事業如同本文所說很簡單，但要確保事業能成功極端困難，請參考這篇。

解決專案困境的三步驟(軟體主管的31堂課)

一個完美被執行的專案幾乎不存在，特別是越是有潛在價值的專案，通常會伴隨一定的風險，因此很難不遇到問題與困難。

有經驗的專案管理者，可以在問題發生之前先行規劃解決，這和專案一開始的結構設定有很大的關係。然而就像扁鵲的父兄的故事一樣，能在問題出現之前防範未然者，讓專案順利執行，這樣的人在台灣的環境，似乎難以被定義其價值，即便有也難以被發現。

總之，有價值的專案，無論如何，難題總是會在某時候出現。

在接案公司中，最常出現的可能是時程，需求過度擴張，等等常見問題。例如：協助政府建立某APP用以查詢政府


透過以下三個務實的步驟，協助解決問題

在這裡假設問題已經發生，必且這個問題不在專案進行的時候的風險規劃之內。

這些步驟乍看之下，可能會讓人覺得簡單到需要特別說明嗎？不過，實務上遇到專案困難時，由於時間的壓力以及人類固有的習慣，能保持平靜看待困難是不太容易的。因此，透過簡單的步驟。

某些人常會對於既定的步驟有些許誤解，認為規劃好的步驟可能會失去彈性，減低創造力。但如果掌握真正的精神，結果會正好相反。

(1) 第一：了解事實

大概不少人會認為這是一句廢話。不過，在遇到真正困難的時候，困難的本身通常會隱藏事實。


舉例來說，看似最常遇到的困難就是資源缺乏。以軟體專案來說，就是沒足夠的人力，或足夠的時間來做事情。

但是，絕大部份的人力不足，其根本原因都不是人力不足。

根本的因素可能是：現有的人沒有執行這方面專案的經驗；負責的專案經理能力不足，無法有效協調人力；現有的人員無心執行任務；規格不明確，而導致執行方向不正確，因而使專案到中後期看似沒有足夠的人力或時間完成...等等，諸如此類，才是真正的事實。

人力不足，沒有時間，只是表象。

專案負責人（可能是專案經理），必須要先找出事實。

一個很簡單的原則：如果有表象是「沒有人手」，「沒有時間」，「規劃的進度常常延誤」，專案負責人幾乎99%可以斷定背後必有其他原因。


了解並且面對事實是務實的第一步驟。缺乏這個步驟，任何其他的解決方法都沒有意義。

(2) 第二：模擬不同的解決方案

通常界定真正的事實之後，解決方式大概就隨即而出。然而，既然是困難的問題，就應該想出一個以上的解決方案，然後模擬可能的後果。

這裡強調提出不同的解決方案，因為既然是困難的問題，表示一定在有限的時間以及資源之內，無法簡單的解決。換言之，任何可能的解決方案都可以會犧牲某些東西。因此「模擬」就有必要性。

最簡單的模擬是拿一枝鉛筆一張紙，描述接下來會做的解決方案跟可能結果的流程圖。

舉一個最常遇到的例子：時間不夠，而時間不夠的主要因素已經界定為專案進行過程，常常有需求的改變，但是專案期限卻沒有改變。

假設，可採用方法有以下幾種：

Plan-A：開始軟性或者硬性延長工作時間。

Plan-B：與專案業主坦承需求改變已經造成專案延誤，用Scrum的方式讓專案繼續推進到期限，但在此之間，專案完成的定義也會被改變。

Plan-C：與專案業主談判，取得延期或者需求限制。

Plan-D：...（還有其他很多）

這些解決方式也許彼此是有相關的，例如B與C，其實都需要和專案擁有者（就是出資的人）協商。

模擬Plan-A：

拿出紙筆，寫下所有已知的資訊或事實：

* 目前為止團隊每週的產出
* 目前為止需求的改變數量，和造成的延誤時間，假設延誤10天
* 規劃需要加班時間總數：假設延誤10工作天，目前到期限仍有4週，等於是每週需要額外20小時工作
* 加班之後可能能夠多做的哪些功能
* 加班的總長度，這個例子是連續4週
* 過去加班的耗損率：每週超過10小時的額外工作時間，會讓人請病假的機率
* 長時間加班之後人才的保留率：每週超過10小時的額外工時
* 加班的這段時間，還是會有需求改變。
* ...等等...

將這些已知資訊，不過心裡知道與否，還是盡可能寫在一張紙上，在腦中想像這些資訊「拼湊」起來之後，對於目前專案，有沒有可能使用這個方法解決，而這個方式，其副作用是不是過大。

模擬Plan-C：

拿出紙筆，寫下所有已知的資訊或事實：
* 目前為止團隊每週的產出
* 目前為止需求的改變數量，和造成的延誤時間，假設延誤10天
* 專案業主對專案的瞭解程度
* 專案期限往後延，對於業主的損失
* 專案業主的協調能力
* ...等等...

將這些已知資訊，不過心裡知道與否，還是盡可能寫在一張紙上，在腦中想像這些資訊「拼湊」起來之後，模擬與業主溝通時的可能對話，以及可能產生的結果。

選擇：

將模擬的過程，用心智圖(Mindmap)或其他圖形化方式，寫在同一張紙上。這麼做是為了盡可能排除個人主觀意見，將自己的思緒，用鳥瞰的方式呈現給自己。

模擬數個方案之後，最重要的是選擇一個自己認為相對最佳的方案。

(3) 第三：執行解決方案

如果前兩個步驟，已經竭盡所能。那麼，第三個步驟就變得很簡單：根據第二的步驟模擬之後的決定，執行解決方案。

然而，既然是困境，就不應該預期解決方案一切順利。如何克服困難去執行，就看專案經理的智慧與能力。

執行解決方式同樣有很多需要注意的地方。不過內容絕大部份取決於每個不同專案的特定現況，因此不會有放諸四海通用的銀色子彈。

但是，由於專案困境常有相似性，因此尋求有經驗的朋友或顧問的建議，倒是一個永遠不會吃虧的選項。

---

沈思：為什麼有價值的專案總是會遇到困難？
參考->解決軟體專案困境的最爛方式

資訊科技學生畢業後只想當SA/PM (三個創意作法)

很多畢業生，資訊相關系所，擺明就不想要寫程式，但是卻又想要加入資訊科技產業。老實說如果是做行銷(Marketing) ，業務(Sales)，或者支援類型工作(admin, finance)倒是也無不可。

只是很多資訊科技學生，似乎想要當SA(系統分析師)或者PM(專案經理)，也許只是覺得名字好聽，或者認為：既然是資管學生應該做點管理工作也不為過。

這種想法其實很危險，也不可靠。

系統分析師(SA, System Analyst)扮演的角色在各公司都很不同，有些很像是業務助理，有些是專案經理的小跟班，有些是扮演IT對外採購的角色，不一而足，單看是去哪個公司。

而專案經理(PM, Project Manager)情況可能稍微好一點，顧名思義就是：負責某一個或者一些專案的進行。20年前PMP證照流行的時候，專案管理本身被視為一門複雜的學問，當然在軟體或者新創網路科技產業，PMP那套不太可行，Agile/Scrum/XP 等等方法論興起，讓PM多少都不太可能單純只做管理。

不管如何，缺乏實務經驗(指的是起碼3-4年努力寫程式的經驗)就去做SA/PM等同於是碰運氣，就算花大錢去取得PMP證照以及其他相關證照，也沒什麼用。這就像是從來沒打過籃球的人，想要當NBA籃球教練一樣幾乎不可能。

雖然很不贊成這樣的事情，但與其碰運氣，不如提供實務作法。

(1) 創意一：讓自己真實變成SA/PM (要花一點錢)。

在學校的專案課程中，讓自己變成PM然後讓某同學變成主Co*(註一) 是絕對沒有用的。任何有經驗的主管，一定看得出來你只是負責動動嘴巴，補補文件。

你可能需要付出一些代價，例如100美金，然後想一個app的好主意，到outsourcing網站，像是upwork.com，雇用一些印度，巴基斯坦工程師，實際上幫你寫程式，這時候你100%是PM，你控制了整個專案的進行，負責製作需求與控制工程師進度。更好的是，這還是個跨國專案。

不過，實際上這樣做出來的東西，失敗率很高，特別是假如這次你第一次當PM - 這裏的PM同時兼具Project和Product。因此，對此創意方式要有正確的期待，也就是說事情的成敗並不是重點，而是在此過程經歷了什麼。這非常接近NBA例行賽開打之前的練習賽，練習賽獲勝固然可喜，但比勝利更重要的是團隊的磨合以及戰術的演練執行。

註一： 主co = 負責主要coding。這個名詞是最近幾年面試學到的，意思差不多就是這個專案課程，程式都是我寫，事情都是我做，其他人出嘴巴。

(2) 創意二：組織同學來做專案

等一下，前一段不是說在學校專案當PM然後某同學來主co是絕對沒用的嗎？為何這裡又說要組織同學來做某專案？

不一樣是，組織同學來進行非課堂的任務，遠比修課需要的專案來得困難，但是更實際。

第一種可能是，到市場上接專案本身到不是問題，因為一開始取得專案的目的，並不是獲得高額利潤，因此價格競爭是有可能的，畢竟你的目的是要取得成為SA/PM的事實，並不是真的要從專案獲利。

然而，業主可能也知道，這種情況下的專案可能不見得做的很好，因此價格競爭有時候也沒太大用處。

第二種可能是，自己找事情來進行。十幾年前BBS風起雲湧的時候，大部份架設BBS的人，都並非學校課程，也不是因為賺錢獲利，只是覺得好玩有趣。架設BBS讓當時的學生取得寶貴的UNIX（FreeBSD等）的營運經驗。如果想當PM，也可以自己找事情，組織同學來進行。不過通常這種情況需要是以技術強度來領導，因此遠比接專案困難。

(3) 創意三：尋求業界導師

由於linkedin和其他社交工具的發展，很容易可以找到業界資深的學長學姊。只要是在他們時間允許的範圍，很容易可以請求協助。當然，每個人的時間有限，所以最好的方式是，互相幫忙，互蒙其利。當你在與不太熟悉的人聯繫上之後，可以用交換的方式，讓他們指導你，並且為你的成就背書。

舉例來說：你可以作為業界導師的私人虛擬助理*(註二)一段時間，幫他處理非機密的相關業務，例如，調查研究競爭對手產品，處理文件，處理linkedin或者其他socail media的日常文章，業務聯繫等等。而作為交換的是：他可以指導你實務專案上"他實際上做了什麼"。數個月後，你甚至還可以取得業界導師的背書以及推薦。

另一個做法是尋求成為學徒的機會。學徒制度是一個非常古老的學習方式，在某些情況下，學徒制度非常有用。如果你是一個剛進學校的研究生，尋找指導老師是最重要的一件事。而如果你是一個畢了業就想要當SA/PM的人，找到正確的業界導師，會讓你事半功倍。

我們會在未來的文章探索學徒制與軟體專案發展的關係。





* (註二)：關於虛擬助理，請查Virtual Assistant

---

沈思 

如果本文對你沒幫助，還請與我們聯繫取得免費協助。

1.  再次強調，在沒有技術背景的情況下，最好是別真的想做SA/PM

2.  如果真的想做，那麼務必考慮這三種方式。

3.  當你想要什麼，執行的方式如果是「碰運氣」或者「期望別人給」永遠都是最糟糕的選項，想要什麼最好是先構思自己要怎麼取得。

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

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


專案在開啟之前，相關人等必須一定要聚集在一起，至少達成一件事情：就是要討論專案如何開始。這個討論很多地方稱之為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分鐘，其他人都在看自己的筆電的情況。

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



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

---

沈思：

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

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

務實專案管理(FLA)的三個重點...(從team leader的角度)

軟體工程與專案管理的方法論以及參考書籍非常多，無論是最傳統的PMP，到近幾年強調的Agile, Extreme programming，以及創新公司最常用的Scrum，這些方法都不外乎希望能盡可能圓滿達成專案目標。

而越後面產生的方法論，似乎都盡量想要化繁為簡，貼近事實，以便彈性的因應改變。例如Scrum就是將需求變更控制在sprint開始或結束，並且讓每個短暫的sprint(3-5週)可以專心於現在的計劃，改變於是乎就受到控制。

專案經理的角色和技術領導相輔相成，只是目的截然不同。專案經理最終的目的其實是”管理利害關係人的期望” (Manage stakeholder expectations)。實務上，這個目的甚至比專案在時間成本內達成來的重要。

技術領導雖然不是專案經理，但實務上，技術領導的小團隊是專案執行的最適切單位，因而技術團隊領導者也是反映真實狀況的適切人選。

技術領導當然不見得一定需要知道專案管理的細節，然而在軟體專案的執行中，技術領導者瞭解得越多，越能讓專案有機會成功。瞭解得越少，越容易受困於專案管理的本身。

(參考案例一）

專案經理(PM)在專案一開始就召集所有分析師(兼為小組長)進行傳統的WBS製作，完成了一份洋洋灑灑專案管理文件。在缺乏專案管理的知識下，三個月後在專案中期，某小組長發現有很多事情其實未列在WBS中，他就很掙扎要照常繼續回報列出來的項目？還是要重新修改WBS？

(1) 萬事起頭難：起初，專案計劃

作計劃這件事很重要，相關的名言也很多：

• 廟算者勝，得算多也；未戰而廟算不勝者，得算少也；多算勝，少算不勝，而況於無算乎。
• A goal without a plan is just a wish
• Fail to plan, plan to fail
• Plans are of little importance, but planning is essential.
• You can't predict the future, but you can plan for it
• The general who loses a battle makes but few calculations beforehand
• Planning is everything. Plans are nothing!

任何專案管理方法論都會涵蓋”做計畫”(planning)這件事情，原因也很簡單因為這實在太重要。可是也太容易被忽略誤解或輕視。

無論任務範圍大小，多寡，範圍，一個適切的”文字化計劃”對於軟體專案絕對重要！特別是有任務是整個團隊曾經執行過類似的，”原則上”只要根據以前的經驗”照著作”就可以達成，這種特別容易被資深員工忽略的任務特別容易出錯，更何況”照著作”等於是打算重覆過去的經驗，而不是打一開始就意圖要精進。

忽略："現在時間很急迫，不趕快做來不急，就不先搞計劃了"

越是急迫的事情越不能出錯，減少出錯的最基本方式就是先行計劃。更重要的是簡單的思考整件事情，並且寫下來，適事情大小，不但不花太多時間，而且最能降低的風險以及未來避免浪費時間來修正錯誤。

誤解："作計劃要花很多時間"

一個複雜的任務絕對需要花時間計劃。但是一個簡單的任務，可能只需要花15分鐘把心裡想做的事情簡單地寫下來。這個過程就可能會讓團隊避免發生前述案例中無聊的錯誤和不必要的問題。

輕視："作計劃是給老闆看的，反正事情都不是照計劃進行，計劃對我們沒有用"

這種想法跟不打算作計劃完全一樣。等同於靠運氣跟個人當時心情來決定最後任務的好壞。

做計畫並非僵化，計劃的本身形式也不拘，一個簡單的心智圖(mindmap)就可以整理思緒 揭露許多未來的可能性。

下圖是本文撰寫的第一個計畫，可以和最後的結果比較看看，雖然粗糙，而且之後順序以及結構也有很大的改變，但是計劃的本身卻是很簡單可以引領思考。

　

(參考案例二）：

有個售前支援團隊，與各國業務長久一起合作習慣了，常常四處進行軟體產品展示任務。有一天得到通知要去東南亞某國家進行安裝測試，大家都以為當地業務會大致把前置作業搞定，因此就迅速訂機票出發。到現場才發現，客戶負責的技術人員當天根本就沒來上班！整個作業只好延宕一天。

任務分配

團隊合作必然涵蓋工作分配。在資訊科技領域中，分配的方式也有很多種。而對於一個團隊的技術領導者而言。當已經對自己以及團隊的能力有基礎認知之後，有效的工作分配是一開始就要先計劃的事情之一。

技術領導者必然是已經瞭解自己也大致瞭解團隊能力，同時也瞭解任務內容之後，才能進行計畫任務分配。任務分配可以是團隊所有人一起討論，也可以技術領導者自行決定，但無論如何一定要先考慮團隊成員能力彼此之間的比較利益。

比較利益法則最早出現在經濟學鼻祖大作國富論的第一章(亞當斯密,1776)。衍生的，基本概念很簡單，只要有效分配，任何情況下都可以達到1+1>2的效果，即便專案成員某些人明顯地比其他人能力還差。

(2) 專案專案執行中面臨的問題

專案執行面臨的問題 - 人的偏誤

人類判斷事情會先採用快速直覺，這乃是上百萬年來的演化，無論是視覺上還是意識上皆是如此。以下簡單列出常見的人類認知偏誤：

歸因謬誤（Attribution Biases): 

解釋別人的事情時，會傾向別人的內在因素，解釋自己的事情時，會傾向外在因素。例如：會議有別人遲到，心裡會想這是這個人紀律問題，沒志力起床。自己遲到，會解釋是因為交通問題，昨天事情太多太晚睡。

錨定效應(Anchoring)：

有參考點或第一次接受的訊息時，會過度偏重參考點。例如某地區最近賣出的房價是一坪100萬，則臨近的房子無論好壞，預售價格為一坪50萬時就會被認為"很便宜"，即便一坪50萬對絕大部分的受薪階級來說還是貴得要命。

沈沒成本(Sunk Cost)：

過去已經付出去的，不管未來的選項如何，其成本都不會變。也就是說不同的選項無關過去的成本，只關係未來。例如當已經花錢買了張電影票，但是臨時聽說同一時間有某明星簽名活動。這時候有兩個選項，一個是繼續看電影，另一個是去參加喜歡的明星的簽名活動。無論是哪個選項，其該電影院票價成本都是存在，因為錢已經花下去。換言之，要考慮的只是，現在看這個電影是不是比得到喜歡明星的簽名重要，而不是考慮如果去參加簽名活動會損失電影票的錢。

過度自信(Over confidence)：

人類對於評估自己的能力時都會過度自信。例如，在一個50個人班級裡面，所有人自我評估考試成績的"名次平均"在技術上說應該是25，但是通常自評估的平均值都會遠小於25。也就是大部分的人都會高估自己的能力。

羊群效應(Herding Effect)：

在團體中，個別成員會不自覺跟著團體中心行動。例如，股票市場中，市場最常發生一直買或者一直賣的情況。而如果是在競爭市場，有特別突出的公司時，其他公司會學習特別突出的公司的行動。

專案執行面臨的問題 - 進度(時間進程 vs 距離進程)

在專案或者任務執行之中，技術領導者多少需要有效評估跟瞭解現況。而目前進度是最重要的"現況"。在比較嚴謹的專案管理領域裡面，有許多評量進展的指標，例如已投入成本和預計完成所需的成本比例(一般PMP常用方式)然而，在資訊科技領域中，比較適當的衡量應該還是以時間進度能準確反應事實。

所謂時間進度指的是，還有多少時間可以達到目的。舉例來說假設某人要去日本玩，從家裡到機場需要一小時，而飛行時間為兩小時，抵達機場之後到旅館需要一小時。因此當我們詢問他的進度時，當他的飛機抵達日本的當下，他會回報進度完成75%，尚有25%未完成。

然而，如果是距離進程，也就是以還有多少距離可抵達就有很大的不同。舉例來說，家裡到機場僅有50km，飛機實際飛行距離為1000km，機場到旅館假設有50km，所以當他的飛機抵達日本的當下，他會回報進度完成96%！只有2%未完成。

單以事實來看，這兩者都是事實，可是呈現於資訊科技控制進度與瞭解現況來說，恐怕是以時間進度比較能夠掌握。畢竟，當一個團隊成員說有件事情只剩5%完成，而且你知道他在這事情上做了3小時的時候，在沒特別問清楚的情況下，你大概直覺上認為只需要幾分鐘完成，而非剩下的5%距離，需要在1小時完成。

不過專案進程的事實搜集，有太多太多慘痛的例子是在混用時間進程和距離進程的估計。事實上，由於人類天生的偏誤，在距離很短的時候，會不自覺採用距離進程來回報狀態。這時候技術領導有意識的取得"時間事實"才最重要。

專案執行面臨的問題 - 技術問題

技術問題層出不窮，不過大部份專案的技術問題，通常可以解決。然而，技術問題通常也很難概化討論之，他和專案的特性以及屬性有關。

不過就軟體專案而言，有個兩個看似有些衝突的基本概念一定要知道：

(1) 每個人的技術能力與技術方面的產出差距可以達到10倍以上。而每個組織的能力與技術產出，也有近十倍以上的差距 

(2) Scrum的方法論裡面，假定短時間每個人的績效不會成長，也不會改變

我們以後會再來討論這兩點。不過建議先對agile, scrum有初步研究。

(3) 專案的結束：好的結尾比好的開始更難

第三個重點，專案的結束。很多大公司，無疾而終的專案很多，軟體專案通常無論如何都還是會結束，只是結束的方式好不好而已。

礙於篇幅，我們在日後的文章再來討論專案的結束

---

沈思：

* 為什麼這次有些項目會在日後再討論，沒辦法先提示一些重點嗎？

* 對於務實的專案管理方式的諮詢服務，請與我們聯繫。

技術領導者team leader 提升能力的三個方向

作為技術領導者，當然在技術力以及領導力上都能必須足以帶領團隊。實際上，能力只有下限沒有上限。因此有意識的提升自我能力必然是作為技術領導者的重要條件。

技術領導者（基本定義請參考這裡）自我訓練，提升能力的三個主要方向參考如下：

(1) 提升領導力

領導能力，乃是帶領組織的能力，與管理不同的是領導力主要產生於個人的能力以及影響力，而非自己的組織地位。簡單地說，領導是讓團體一起朝著正確的方向，作出正確的事情，達到預定的成效。領導能力是抽象而廣泛的，但是產生的結果卻是清楚可見的事實。例如：溝通能力是領導者須具備的能力的一環，在某次開會之後，當詢問5個與會人員，開會的結論如果有5種不同的說法，那顯而易見的這次會議的領導者有很大的問題。

對於技術領導者而言，這樣的領導力是可以透過自我訓練以及培養不斷地提升。然而，更重要的是技術能力以及領導能力需要同時，有意識的自我提升，偏頗與缺一不可。

外商常用的360度回餽(http://en.wikipedia.org/wiki/360-degree_feedback) 其中一項常見問題就是”利用自己的影響力，而非職位來協調同仁完成任務“，誠實的根據過去自己的經驗，來回答這些衍生問題可以簡單探知自己的領導力。

誠實瞭解自己是提升的第一步。接下來根據自己缺乏的事情，自我提出學習計劃。以上看起來簡單，但是做起來極其困難。過分自信(參見偏誤)是人的主要認知偏誤之一，且人類傾向繼續做自己專長的事情，要移出舒適圈難上加難。

有幾個簡單的方式可以參考：

• 閱讀

不僅只是閱讀企管類書籍，而是廣泛而長期的閱讀各類書籍。廣泛而有系統的閱讀，會讓思考全面，而養成長期閱讀習慣大部份好領導者的少數共同特質。

如果對閱讀沒有長期習慣的，建議先讀"How to read a book"。

關於資訊科技的市場以及分工，不免得先對經濟學有所瞭解，可以先看鼻祖書The Wealth of Nations（國富論）然後市面上有很多科普叢書，都能引人入勝。例如蘋果橘子經濟學。

小說類型可以考慮作者已經死很久的，而且篇幅不太大的開始，例如聊齋誌異，雙城記，基督山恩仇錄。近期可能還是稍有名氣作家，例如金庸武俠，村上春樹的小說系列，作為開始比較容易。

至於混合歷史知識和想像的書籍，像是丈量世界，哥倫布行動，萬曆十五年都是開拓視野的好開始。

當然在此沒有列出資訊科技書（例如Design Pattern）倒不是因為不重要，而是因為在此假設技術領導者已經有這方面的學習習慣。自然無需贅述。

閱讀清單(非技術類型):
- 雙城記
- 基督山恩仇錄
- 拷貝一瞬間
- 蘋果橘子經濟學
- 黑天鵝效應
- How To Read a Book
- 國富論 (The Wealth of Nations)
- 丈量世界
- 哥倫布行動
- 萬曆十五年
- 水滸傳
- 不花錢讀名校MBA
- 企業巫醫
- 孫子兵法
- 科技奴隸

(這個清單跟技術領導力沒有直接關係，但是從旁的間接關係不少，重點是要有自己的閱讀清單)

• 記錄：

        記錄或者筆記，對於工作的執行以及回顧來說很有價值。記錄工作以及重要事項不見得會花很多時間。但是對於追溯自己的思緒有諸多好處。許多管理叢書強調筆記的各類祕技，但總歸一句話，有用的筆記自然有用，沒用的筆記就不會有用。對於強調隨時存取且無限量的"外部記憶體需求"的技術狂熱者而言，雲端服務似乎是某種終極筆記方式。

但請注意：首先，書寫的手感是無法用打字取代；其二，對長期保存而言，目前資訊科技尚未有可確保穿越時間的做法  (例如，1995年如果你有一張3.5吋軟碟片，和一本手寫的日記，在2015年的現在，哪一個可以正確無誤看到其內容？）

• 練習：

領導能力跟很多可以學習的東西一樣，需要勤加練習。參加領導訓練課程就跟打籃球一樣，看一萬場NBA球賽，不如下場打一次。但是，要練習領導能力並沒有練習寫程式這麼容易。以下做法提供技術領導者參考：

首先，只要在團隊中，就有機會主動帶領"事情的發生"，事情無論大小，只要還沒發生就值得主動組織人力執行。

其次，回顧過去的成功與失敗經驗，也是練習的好方式。要注意的是因為自己是自己的練習對象。

(2) 提升技術力

資訊科技的技術能力指的是對程式網路演算法作業系統協定軟體工具等等的瞭解以及應用能力。對於資訊科技瞭解以及能運用的範圍越深越廣，大致表示技術能力越好。

軟體工程師要評估自己最簡單的方式是先由程式語言能力開始。如果你自認為熟悉java那就從上網找SCJP相關測驗，在線上誠實的瞭解自己到底對java了。非程式設計師類型的資訊科技工作，例如DBA，一定也有相關的事實評估方式。自我評估重點在于自我誠實的瞭解。

只要能認清事實，技術能力培養並不困難。有簡短目標的實際練習，就是個簡單易懂的式。例如，雖然很熟悉c與java，但是從來沒接觸過python。想要學習python就應該簡單地定出一些目標。最後一點，如果技術能力的提升目前是個困難，那必須認真思考自己目前是不是能夠擔任技術領導者。

(3) 其他能力：英文能力.專案管理

由於大部分資訊科技資訊，以英文形式為最大量。因此英文能力絕對是團隊能力評估的一環。同樣的英文能力評估也不能靠猜測跟想像，現在有太多遊學留學生，在美國一整年但英文能力卻沒有如同想像中的好。以企業而言，目前最簡單的方式仍然是以TOEIC的實際分數為準。就資訊科技商用領域，TOEIC 785分應該是所謂”無英文溝通專業問題”的最低標。

技術領導team leader在很多時候，必然要了解軟體專案進行的各種細節。實務上Scrum也假設Scrum Master就是技術領導者。

不過在這邊因篇幅關係，先省略專案管理部分，待日後的文章討論。(軟體專案管理相關文章請看此）

---

沈思：

1. 這樣看來當技術領導好像很困難？

2. 專案管理的技術領導要怎麼做？(參考資料）