企業巫醫 - MBA無用矣

企業巫醫The Witch Doctors（中譯本為商周出版）是一本距今十一年的老書，但書中對於盛行於商業界的企業管理顧問的見解卻始終精闢。這本書的標題雖然聳動，但內容卻是不只是流於隨想批判，而是踏實的先提出數據，做橫跨時間與空間的研究，最後提出見解。破解在招搖撞騙的「大師」形象。

作者對「大師」的批評相當有建設性，幾乎在1990~2000年間的企管大師，都被他非常精闢而有建設性的評語跟分析過他們所提出的方法論：彼得杜拉克，麥可波特，愛德華戴明等等。而史蒂芬柯维，吉姆柯林斯則是被他列在不入流的範圍。


組織與企業經營的是合併藝術與專業的範圍，在因果模型中屬於複雜的範圍（參考這裡）。換言之，企業的大大小小的決策，與是否能達到效果，很難在事前看出，只能事後瞭解其因果關係。而有趣的，具有戲劇性的論點，逐漸就取代了嚴謹的研究。這讓迷惑於複雜邏輯的人，有了某種追尋的方向，從這個角度來看，「真正」的企管大師也知道這種現象，但他們一方面提出淺顯易懂的見解，另一方面也持續進行研究，這也讓大師的研究結果可供大家參考與學習。

「企業巫醫」則利用根本沒有人可能了解其因果關係，讓自己以有趣的方式解釋因果關係，從而謀利 - 開設顧問公司，提供考取證照方式，提供分析報告，寫書，演講等等。

萬一，自己解釋的因果關係沒發生，當然會拿另一套關係來彌補。就像在原始叢林部落裡的醫生一樣，當有疾病-例如嚴重流感時，會先說明和惡靈的關係，接下來可能拿某些植物的葉片猛力槌打你，打的你又痛又麻的時候叫你回家躺幾天。如果好了，證實的確是惡靈的問題，如果因此病情加重，併發肺炎，表示這樣的懲罰惡靈仍然不滿意，則會換一套方式，直到你痊癒或者死亡 - 當然死亡就表示惡靈趕不走(此段說明彷自企業巫醫一書)

在企管書籍，個人認為最最最有名的巫醫例子應當屬於「從A到A+」。用google搜尋「從A到A+」可以找到非常多人閱讀記錄，甚且有精闢的閱讀心得。該本書所說「嚴謹的長期觀察和研究取得」，分析好公司和「卓越」公司的差別，並且這些從數百家篩選出來的好公司中再篩選的卓越公司，肯定可以「永續經營」？

但是實際上根本不然。

2005年的研究就顯示A+公司，在1996-2005年間，就已經不太算是A+。不到幾年後：11家卓越公司倒了2家，9家之中僅有1家沒受到太大的金融海嘯影響。其中8家在2008危機期間甚至績效平均比其他SP500的公司還差。

從結果來看，從A到A+的理論根本沒用，但是，如同企業巫醫，作者後來竟然還寫了一本「為何A+巨人會倒下」用以自圓其說。非常典型的巫醫行為。

相對於企業巫醫，MBA的價值是否真正有用也很難說。某些研究都顯示，擁有MBA學位的CEO和沒有MBA的CEO在公司經營的成效上，沒有差異（參見這裡）。

然而，某調查顯示，擁有MBA學歷似乎對薪資有幫助(參見這裡），就這個角度來看，擁有MBA似乎還是有用的。但如果仔細看過這類調查，很明顯排除了MBA低薪，以及MBA本身的成本。

反倒已經有百年歷史的最最著名MBA產地的期刊 - 哈佛管理評論的一篇高學歷管理者的迷思。誠懇的點出問題：管理學位取得者，在學習過程中沒有學到真正學到務實的作法，而只是為了取得學位。開始工作之後，如果又沒透過工作經驗，學到新的技能，當然就沒用。

如果沒能對複雜的問題，保持清澄的理智，分析可能的問題，簡化並反覆查證因果關係，踏實的從不同的角度看問題，MBA的學歷可能會創造出一個一個的企業小巫醫，在組織裡三不五時的拿一些最新的企管叢書，當做驅趕惡靈的樹枝，到處鞭打真正在做事情的人。


企業巫醫相關文章：

如何拒絕或調整客戶不合理的需求 

實習生的三贏

時間乃最終之敵人? (上) 

時間乃最終之敵人? (下）

如何提高工作效率：三個務實的快速步驟

Give me six hours to chop down a tree and I will spend the first four sharpening the axe. 

 - Abraham Lincoln

白領工作者，或者，知識工作者的工作，追根究底是利用智慧知識和經驗，做出一些行為。例如：行銷經理，就是擴大產品的市佔率；軟體工程師，就是產出程式碼；業務員，就是賣出產品； 言情小說作家，就是寫書；專業經理人，就是領導管理團隊完成任務。

只要是知識工作者，不管用什麼方式衡量工作效率，理論上都可以持續提高。

就概念上來說，工作效率來自於三大方向，(a)技術與知識，(b)環境，(d)心理層面。

技術與知識。需要靠學習與經驗累積，而正確的學習和正確的經驗累積更為重要。請參考這三篇相關文章：自我學習的方向，片段知識的危害，工作中學不到東西。

環境。如果週遭都是工作效率極高的人，自然而然就會主動提高效率，然而環境有點運氣成分，大部份的人很難控制周遭環境。

心理層面。從馬斯洛需求階層論，到赫茲伯格的雙因素理論，心理與管理學界不乏各種相關的研究以及結論。但知識工作者，可以先參考Ted的這篇。


工作效率，絕對會和「超過」的工作時間呈反比。長期的加班對絕大部份的知識工作者而言只會降低效率，拖延成果，殘害自己與家庭。尤其是對剛進入職場的新鮮人，提升工作效率是最最最最重要的事情。工作效率的提升，會伴隨知識技能的成長，更多的時間運用，以及對組織產生真正的價值。高效率地利用時間，可以產生對職業生涯的正面循環；低效率的長期加班，則會產生很難逆轉的惡性循環。


只要願意嘗試，每個人都可以利用以下三個務實的步驟，持續並快速提升績效。做法很簡單，只需要筆記本和筆：

(1). 15分鐘每日計畫

每天開始工作前，先不要開電腦收email，而是拿出筆記本和筆，把今天最重要的幾件事情寫出來，分類事項，決定今天要先做什麼，要完成什麼，參考這篇的分析。切記先完成重要且緊急，以及重要不緊急的事情。

每日計畫只是簡要列出「打算完成」的項目，並且花一點點時間，沈思哪些真的可以完成，哪些是在80/20法則中最重要的完成項目。 也可以加上一些「保留」時間，用以處理意外。

(2). 15分鐘檢討改進

每天結束工作「後」。拿出筆記本，看看今天開始計畫的事情，哪些完成，哪些沒完成，哪些真的重要，哪些其實後來發現不重要。自己檢討一下自己的判斷為何不正確，為什麼該完成的事情沒完成，並且，簡要記錄一下，完成的項目大概花了多少時間，未完成的事項是因為什麼原因。

(3). 15分鐘重點學習

改進檢討結束後，找一小段時間，再把筆記本拿出來，看一下那些比預期晚完成的事項，哪些是因為自己的知識技能不足，導致太晚完成。列出這些項目。特別是找到「厲害的人一下子就可以做到」的事項。舉例而言，excel的PivotTable是資料分析的最基礎的方式，也是做big-data模型時，小規模測試的最好參考，會妥善利用PivotTable的資料專家，會比不會用的人更節省時間的驗證自己的模型。

在筆記本列出需要學習的項目，每天花15分鐘，在網路上學習這個技術或知識。每天只要專注於「一個能提升效率的事情」就綽綽有餘了。




知識工作者最悲慘的情況，莫過於努力了好幾天去做一件完全不需要做的事情，或者完美的執行一個完全不對的方式。

如果還沒有找到最適合自己的方法，請按照這三個務實的方式，每天花不到45分鐘，在2-3週之後一定會有顯著的效果。

---

這篇文章的乃是根據以下書籍參考，匯整，並且實際執行之後的結果。
- Getting Things Done  
- The Productivity Project 
- The 4 hour work week
- Lean startup
- Do Over

靠感覺做專案管理 - 鐵定失敗

真實故事：

有近70個工程師參與的軟體專案的組長會議中，除了專案經理之外，另有8個負責領導開發不同模組的組長一同與會。

例行的報告進度後，專案經理看了一下大家，帶著遲疑的臉說：「在兩三個禮拜大家的模組就都完成了，如果沒有問題的話，應該整個系統同時也都弄好了吧？」

負責UI以及整合模組的組長，看著大家漠然不語，也只能硬著頭皮的說：「現在最大的風險在於：如果所有模組都在最後實現完成，那根本不會有人知道組合起來會發生什麼事，所以我只好老實的建議，要不就額外增加整合測試的時間，要不就要減少某些模組的功能讓他可以早點進入整合」。

但其實大家心裡有數，這麼多人在短時間開發出來的系統，不可能在短期間整合完畢。

未料，專案經理似乎沒有體會事實，他說：「接下來大家就要在努力一點，就快要搞定了」。

可能是心情不好，在加上長時間加班的火氣：某組長就說：「我們到目前為止的問題是在於我們不夠努力嗎？」。

專案經理當然說：「不是，我知道大家都很努力...」話未說完，該組長就說：「既然問題不在於我們不夠努力，為什麼叫我們更努力，就可以解決問題？」。

專案經理：「...」

---

許多失敗的專案管理者，在遇到困境時，只會用幾個永遠不會有好結果的方式，來試圖解決問題。常見的方式像是：無意義的加班，默許降低品質，虛報進度，哭訴人力不足要求增加人力。在緊要關頭，這些作法都不會有好效果。只會這幾種方式的專案經理，儘快離開管理位階，才會是組織最大的貢獻。

最有天賦以及領導力的管理者，通常擁有不可言喻的直覺，並能透過直覺透徹專案。很遺憾的是絕大部分的人不會有這樣的天賦，特別是作為軟體專案經理者。很難具備以敏銳直覺，完成複雜系統開發。

然而，專案管理其實不需要天賦，所有人都可以透過自我學習，了解專案管理的精隨，透過自身的努力作個稱職的專案經理。和所有重要的事情一樣，首先是要了解事實。在略具規模的專案，應該透過事實的呈現，來了解專案目前進度，可能的風險，遭遇的困難，以及解決方式。

而且，只有盡可能了解事實，面對事實，才能引發可行的創意行動。


事實的取得有三個面相：

恰當的衡量：

恰當衡量，是判斷專案經理的好與壞的關鍵之一。恰當：簡而言之，必須是可行，正確，有效，有意義，精簡的衡量。

近年來Scrum蔚為風潮，其中一個重要因素是對於進度的恰當衡量。通常專案進行了一段時間之後，burndown chart可以清楚的顯示，現在專案的進展，和是否可能在預定期限內完成。也因為burndown chart展示的是不可否認的事實，讓Scrum的團隊在取得洽當的衡量之後，做正確的因應。

不恰當的衡量，出現在幾乎所有失敗的專案場景裡。

有些專案經理會依賴WBS的圖表，來看進度是否得當，但WBS是固定的無法調整，即便調整，也很難追溯過去調整的細節。WBS在軟體專案中，很難達到可行，正確，精簡。

有些專案經理，會依賴團隊成員報口述「完成」來斷定進度，在沒有看到「實品」（例如程式碼，每天自動編譯測試的build等等），口述完成不是「有效」衡量。

最慘的專案經理，會透過大型，繁複，耗時的會議，逐一確定已經完成的項目，花在「了解事實」上的時間，遠超過「做事情」的時間。這種本末倒置的既不可行，也不精簡。它唯一的好處只是在於讓原本不懂的人 - 也就是專案經理，花上不可置信的時間了解事情而已。一個不超過10人的團隊，要是每個禮拜耗費總時超過4小時在這類型的會議上，就表示專案經理沒有對技術有透悉能力，儘快換掉專案經理會是對團隊最有利的作法。

承認不確定性：

沒有人可以預知未來，必須承認不確定性，並且把可能的不確定性當做事實加以處理。當打算推測不可知的未來時，用過去之已知事實，並加上不確定性。

例如：未來3個月團隊的總人時？假設團隊成員共10人，每個月22個工作天。則總人時推測為220人日時，等於表示沒有推測。這220人日，根本沒有把「過去已知事實」考慮進去。比較好的推測應該是，220人日，減到(1) 過去3個月，這10人的總休假生病天數。再減掉(2)可能的季節性假日，例如颱風。再減掉(3) 組織已知的活動，例如員工旅遊，大型會議等等。當然，這些以過去的數字推測未來不一定準確。但是，以過去的事實推測未來的不確定性，總比當做沒看到的好得多。

一般專案管理中，不確定性會用風險管理來衡量並且控制。正是「真正」的風險，就是坦然面對事實。

失敗的專案經理在每週的報告中，會把「人力不足」當做風險，試圖避免未來失敗的責任歸屬 - 畢竟已經先在每週報告中說了，目前人力不足是風險，但是就是沒給足夠的人力。這其實單純是專案經理試圖逃避未來責任的作法。

人力不足壓根就不是真正的風險！如果人力不足是真的，那麼專案時程規劃不正確，對技術掌握不足，專案經理沒有創意來解決問題...這些才是真正的風險！假如真有人力不足，它必定不是突然出現的可能機率，它是「已經存在的必然」，風險必須是某種可能會出現的事件，萬一出現，會對專案造成及大的影響。例如，在建築專案中，大地震就是風險，必須要規範出現的機率，但它很有可能不會出現。

把不正確的風險當風險，以及不把真正的風險當風險，都是不願意面對事實的畏縮專案管理者會做的事情。

理解認知偏誤：

在專案管理中，人類認知偏誤(Human Bias) 不可能全部去除，但可以盡量避免。根據事實原則，專案經理應該承認：認知偏誤的存在，盡可能減少影響，但也要理解，不可能全然去除認知偏誤，畢竟人非聖賢，也非機器。自認為已經去除所有認知偏誤，等於是一種認知偏誤。

去除是不可能，理解並且降低偏誤，是取得真正事實的最重要的方向。

例如：在code view的精簡會議中，常出現偏誤在於，極為資深的員工的程式碼，通常比較不會被挑出問題。但根據研究，只要運用程式語言超過2年以上，資深與資淺員工，在程式碼撰寫品質並沒有太大的不同(參見約耳談軟體一書)。要去除這類型偏誤，最簡單的方式是透過系統送出匿名程式碼(在尚未commit之前)，要求成員利用email寫出自己的意見，而意見也可以是匿名。

高階主管為另一個例子：高層主管對團隊的了解，大部分來自第一線主管或二級主管。高級主管必須要認知，取的團隊資訊，必然經過過濾和扭曲。這幾乎是不可避免的事情，畢竟第一線主管或二級主管也是「人」。例如，如果發現有某團隊老是有問題，進度不佳，人力似乎永遠不足，高級主管如果找第一線主管了解原因，不會有第一線主管直接了當的說「是我的問題」。但是，一個團隊有問題，75%的原因是出現在領導者身上。去除認知偏誤的方式，除了越級訪談之外，高級主管不應該詢問一級主管的「看法」，而是直接詢問可以獲得的事實。例如：目前的問題，一級主管採用哪些「有價值的作法」來解決。

偶爾進行的團隊訓練活動，也可以將人類偏誤以討論的方式作為主題。讓團隊成員知道有偏誤的存在，自然就有可能減少偏誤的發生。



只要能根據「事實」，降低並去除認知偏誤，比較有機會在困難的專案狀況下，發揮團隊潛能，並且找到有創意的解決方案！畢竟，根據「事實」，一個營利組織必然希望團隊能帶給組織真正的價值，而非僅只是達成表面目的。

---

非戰之罪？組織變動的三個因應作法

世界越來越小，變化越來越快。企業環境更是如此

從2015年底的弊案開始，東芝一連串的裁員新聞便在網路上出現（參考這裡，這裡）。最近，由於有要徵約聘員工，通常是很難在約聘的職位上找到有經驗的軟體工程師，通常也很願意找剛畢業雖然能力不足但很願意學習的年輕人。可是，這位林先生卻是個例外。他是自願前來面試約聘職缺，而且有十幾年工作經驗的專案經理。經過詳談才知道，他也是東芝海外大幅裁員的其中一員。過往，林先生充足的筆記型電腦專案管理經驗，讓他幾乎沒有其他的資訊科技能力，對於軟體開發自然也是完全沒有經驗。環境的變動，不是他的錯，但沒有先針對可能變動而準備，會讓他失去工作之後的6個月內仍然難以找到足夠幫他解決房貸問題的方式。是不是雇用林先生？還不一定。每個人都應該針對不預期的組織變動而有因應準備，這才是重點。



在一個超過150人的組織裡，一般的員工其實很難對企業環境的變化做出正確的因應。更直接地說，組織重組(re-org)目的各有不同，但一定會順帶調整人員，而作為資訊科技的組織的一員，在重組時很可能會受到不預期的影響。

可能發生的最糟糕的情況是「被汰弱」，其次的情況是「改變工作」，最佳情況是「被留強」。

而作為資訊人員，軟體研發人員，除了隨波逐流，隨遇而安之外，對於組織的變動，能夠有正確的因應作法會是最好不過。

變動因素

組織變動的因素很多，而絕大部份通常都非單一個人所能控制（除非你是CEO）。

好的情況有：獲利太多，而跨大經營範圍；獲得額外投資；併購其他企業。

壞的情況像是：賠錢要砍部門；被別人併購；移轉工作地點到低成本的地方。

不好不壞的情況也很多：改變經營策略；將寶貴的人力資源移到別的地方；停掉某些產品研發等等；組織汰弱留強，調整人力品質。

對個人影響

組織變化對個人的真正重點在於「因組織變動產生的行為」，當然不外乎以下四項：

離開組織（資遣/開除/離職）：無論是被迫，自願，或者被自願。

執行讓員工離開團隊的任務（執行資遣/開除）：通常是中低主管的任務，也許是會執行讓人離開組織的任務，也許是更換工作內容以及更換部門。無論是被迫還是自願。

改變工作內容環境：做其他專案，升遷，換到其他部門，換老闆，更換工作地點，改變工作時間等等。

改變工作報酬：加薪，減薪，更改薪資計算方式，更改其他相關福利等等。


如果不是CXO，幾乎不太可能在很早之前，事先知道組織變動。不過，對於資訊的技術人員（程式設計師之類），即便是一般員工也能有比「隨波逐流」更好的因應作法：

做法一：事先因應。

首先，所謂事先因應，並不是事先知道各種變動因素發生。通常你知道變動因素發生的時候，一定已經是「太晚了」。

事先因應，指的是因應「黑天鵝事件」，也就是試圖因應未曾發生過的，但是一旦發生，會有劇烈變化的事情。但是，既然是黑天鵝事件，就不可能事先知道事件的種類，發生的原因，發生的時間地點。

事先因應指的是，培養自己，因應「未知」的事件。

作為資訊科技技術人員，相較於其他行業，培養自己比較簡單。剛出社會的新鮮人，當然就繼續學習新的技術，不管是程式語言，系統工具，開發流程，都有極大的學習空間。

稍微麻煩一點的是，工作7-10年左右，在可能不上不下的階段。這個階段，必須要先確實「認知」自己對現在組織的價值，並且透過這樣的認知，

乍聽之下很抽象。例如，你現在可能是軟體公司的技術小組長，帶領3-4同事進行軟體開發，這時候顯而易見的有兩個未來的選擇，(1) 你可以往技術方向前進，未來成為架構師(architect)或者技術長。這時候，培養優勢就在於，應該有意識的讓自己的知識範圍，隨著時間越擴展越大，並且不會僅侷限在這個組織之內。(2)你也可以朝向專業經理人前進。未來成為帶人的主管。這時候，培育的優勢方向在於：必須要同時兼備技術能力和判斷決策的能力。判斷決策能力的自我培養，必須要是有意識地進行。



找到自己的價值，發揮優勢，培育優勢。並且試圖擴展的優勢，讓它不僅限定在特定時段，特定組織，特定產業，甚至特定國家，。

做法二：創造選項。

至少在台灣，絕大部份的人，在任何事情上都有「選擇」。

有些選項，顯而易見。例如，有個選項是：覺得不喜歡組織的某些事情，就「選擇」離職了。

有些選項，因為認知偏誤，不容易看見。例如，有個選項可能是：覺得不喜歡組織的某些事情，就「選擇」去改變這個事情。

大部份的人，都可以輕易看出既有選項。但是，能「創造」選項的，或者看出非既有選項的。其實不多。

軟體技術上，能創造選項的例子比較多。例如，即便到今天為止，在很多企業仍有winXP的存在，但是他所使用的IE(8)很老舊。如果你的網站應用程式，一定要給這些企業使用，擺明著選項有兩種，一個是苦幹實幹，讓網站遇到IE8的時候，用比較老舊的javascript library，另一種是說服企業升級winXP。不過，只要稍微想過，很多技術人員都可以「創造」其他選項。例如部署新的firefox/chrome到winXP上。


然而，非技術的選項，能「創造」的可能性變少很多。但其實，這僅是受限於自己的目標錯置，認知偏誤，或者錯覺。

以組織變動的情況而言。也許你是「被自願」離職的員工，似乎也只有自願離開一途，但如果真的很不想被自願離開，首先需要知道你不想離開的真正目的，和你真正想要達到的目標。例如：或許是因為家庭因素，你需要穩定的收入，而非真的喜歡這裡；或許是你喜歡這個工作環境；或許是你一時之間找不到其他工作。原因可能有很多，但如果你的目標沒先想清楚，能創造的選項自然受限。

如果是因為家庭因素，你需要穩定的收入，而並非真正喜歡這個組織。你的目標應該是「在短時間能創造有穩定收入」，對於有技術背景的人，這並不難達到。難達到的是：「短時間創造極高收入」

如果是你一時找不到其他更好的工作。你需要「創造」找到更好工作的機遇。到linkedin上認識headhunter，加入open source社團，到社福機構提供技術能力當義工...等等都是可創造選項的機會。

做法三：根據事實。執行。

執行選項，特別是執行不那麼容易的選項，需要克服很多心理上的障礙。


特別是以非技術選項而言。突破個人心理上的障礙，執行最適合的選項是知易行難。

遺憾的是，沒有人能夠代替你執行。因此在此只能提出幾個參考點，協助克服認知與心理障礙。

(1) 只有自己才能負責自己的職業生涯。

(2) 軟體技術人員，在技術上都有過度自信的傾向。

(3) 沒有人剛生下來的時候是會寫程式的。

(4) 學習特定的軟體工具，平台，程式語言很重要。但要注意的是，不能把雞蛋放在同一個籃子裡

(5) 組織領導者（主管）的優劣與否的判斷很難。不過，試圖讓所有相關人等都滿意，大家歡喜的領導者，反而容易引導至糟糕的結果。




  

你真的知道專案進度嗎？

只要是從事程設式設計相關工作的人，必然曾經參與某專案(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] 你能單靠記憶，繪出目前專案個模組之間大概關係，無須依靠其他專案成員？

資深與中高階人才選用：三個要點

在資訊科技領域裡，資深或中高階人才選用遠比找到剛畢業很有潛力的人來的困難重重。

詭異的是，幾乎所有已經在資訊科技領域工作7年以上的資深專家，通常多少都會遇到獵人頭(hunter)的引誘。事實上，中高階的職缺其實很少，由組織內部升遷的機會很大。然而，如果真的從組織外部尋找，雖然看似符合條件者眾多，但能有效媒合卻是難上加難。

要點一：情境實例面談

絕大部份的中高階人才之所以是「人才」，乃是根據其真實的過去事蹟。而非未來想像。

在書面篩選階段，通常是根據過去工作經歷，決定要不要請來進一步面談。

而在面試階段，卻常落在討論未來的理想和展望。的確，未來的理想跟展望，的確很重要。不過，在面試階段，要判斷此人能否實現理想和展望，應該是根據其過去的「理想與展望的實際產出」。

一般外商HR的實務操作方式為：面談時著重於情境「實例」。(SAR: Situation Action Result) 

例如，有個軟體研發部門RD主管的履歷表中，表示有帶領軟體開發團隊開發軟體。此時開放性問題無法真正展現該主管的經歷，應該採用情境實例問題，了解過去的「真實例子」。

-- 爛問題範例 --

未來取向的開放性問題：「未來你如何帶領開發團隊？」「你覺得RD團隊應該如何與業務團隊溝通？」....這種問題的回答必定是十分鐘不著邊際的長篇大論。

-- 好問題範例 -- 

初級情境實例問題：「目前你的團隊共多少人，其中有直接report給你？」「此專案你本人有參與寫程式嗎？」「此專案你本人有執行code review嗎？」「這個專案一共大約產生多少行程式碼？」

......初級問題著重能取得簡單而無可偏頗的答案，答案可能為「是或否」，可能是「數字」。回答應該是在10秒內。




中級情境實例問題：「在帶領N個人的團隊裡，你個人做過哪一件事情對團隊合作最有幫助？你怎麼做的？結果是什麼？」「在之前的工作裡，你做過最糟糕的決定是什麼？為什麼此決定是最糟糕？」

......中級問題著重於過去的某單一事實，必須引導回答針對這個人的實際作為，以及產生的結果。如果詢問的問題是負面資訊，例如犯下的錯誤。必須確定是問到犯下「最大的錯誤」。在面談過程，如果一個中高階主管，在過去7年的職業生涯沒犯任何錯誤（或者拿一些小小的失誤當作談話材料），很可能是隱藏事實，但更糟糕的是，他不覺得自己有任何錯誤的地方。


高級情境實例問題會和另外兩個要點：「本職學能」以及「獨立執行單位有關」請參考以下兩節。


簡而言之，SAR的基本概念很簡單：找出事實，而非空想；討論實際，而非理想；了解過去，而非未來。這部不代表理想與未來不重要，而是要判斷中高階人才的理想與未來，應該是看他「過去實踐過多少」，而非不是他「打算未來實踐多少」。


參考資料：(Careerly, SAR)

要點二：本職學能

已經位於組織中高階，很有可能早已不具備，或者喪失本職學能。因此，正確判斷是否具有合適的本職學能極端重要。

然而，中高階位階的人，其本職學能比較抽象，需要有方法加以判斷。

資訊科技領域的判斷方式有：(1) 基礎經歷 (2) T型延伸 (3)培育人才


(1) 基礎經歷：

以職業籃球為例，目前NBA的總教練，必然曾經在他人生的某個時期是「頂尖球員」，也許只是在NBA眾多明星中的候補球員，但也至少是NCAA某個第一級學校的球星。縱使不是，至少也是在高中時期，某一個州的的MVP等級球員。總而之之，他必然曾經當過明星球員，因此在當總教練的時候，能夠了解一整隊明星球員的思維，球員在比賽時的「真正作為」

同樣的，假設在軟體開發，找尋中高階的帶人主管，他本人必須「曾經是軟體開發人員」，最最最起碼也需要有3年以上實務寫程式的經驗。一個的SA或PM，也許工作的經歷還不錯，但如果沒有務實的寫程式經驗就來帶領開發團隊，就好像一個資深的球隊經理，看過很多比賽，卻沒有實際上打過球，就來當總教練一樣的危險。

或許有人會說，有些人屬於「將將之才」，他當將軍比當士兵還適合，不應該以過去的基礎經歷來斷定。在其他領域，或許是，但在資訊科技領域，「沒寫過程式」就是「沒寫過程式」。


其他的基礎經歷，必須有「清楚的事實」的佐證。例如，在履歷表上有AWS的使用經驗，就必須要清楚地知道何謂使用經驗？是用過EC2/S3/Route53，還是用過那數十個服務的哪些服務？是自己親自使用還是「指揮」別人使用？使用的規模有多大？等等


(2)  T型延伸

T型延伸的基礎是先有「基礎」，因知識與職責擴展的關係，延伸到其他相關領域。例如，在已經有智慧型手機應用程式開發的「基礎之上」，延伸到線上行銷，社群開發等等。

誠如前一節所述，沒有基礎，延伸不具意義。

關於T型人才，請參考這裏與這裏。

(3) 培育人才 

並不是每個人都會是好老師，不過如果中高階人才承擔的任務與管理有相關時，能否「培育人才」將會是團隊成功的關鍵。在SAR的方式裡要找到培育人才的方式很簡單。初級問題像是「你個人過去六個月以內，做了哪一件事情最能幫助團隊培育人才？」。中級問題像是「」

要點三：獨立執行單位

資深的工程師和初入社會的新鮮人最大的差別之一，應該是能夠自我成為一個執行單位。判斷是否已經成為獨立執行單位，是選才關鍵要點。


判斷的基礎方式有：(1)自我培養，(2) 計劃未知，(3) 人才培育。



(1) 自我培養

可以在組織裡，自行培養自己，發起並參與適當的事件。在中高階人才中，不存在「組織要協助培養能力」的情況。

這並不代表不用學習，只是不應該透過組織來建構自己的職業生涯和學習計畫。資深與中高階人才，應該要能自己規劃學習計畫，主動學習，並且「主動」將自我成長與組織成長「整併」。

僅專注在自我成長，對組織沒任何好處。努力使組織成長，放棄自己的成長，對組織也沒有好處。雙贏才是長久之計。



(2) 計劃未知

沒有人能預測未來。但資深中高階人才，應該能透過本身的技術能力，工作經驗，長久累積的直覺，有效看出至少數個月後的可能發展，並能有效制定計劃。

計劃(plan)本身並不重要，重要的是做計畫(planning)。中高階人才應該能在有限的已知情況中，盡可能計劃未來，建構真正的目標，評估控制風險。

而這計劃並不是為了展示，也不是文書作業，也不一定需要900頁巨作。關於計畫，請參考這裏。


(3)人才培育：

請參閱前一節的培育人才。

工作筆記的三個重點

這幾年來，市面上有如何做筆記的書。例如記事本圓夢計畫，重點就是要這樣記，不花錢學筆記(註1)等等。

在 youtube上也有很多類似的教學影片，在youtube上搜尋"how to take notes"可以找到數十個教學範例：例如這裡。

大部份的筆記教學，大概都是透過個人經驗，指引筆記的技術。例如，有效使用不同顏色的筆，將一頁分成兩欄，左欄做為索引用途，右欄作為記錄重點用途，等等。

而筆記教學的目的，則和筆記教學的內容有根本上的差距。筆記的「目的」，通常極為崇高，例如實現人生夢想。但筆記教學「內容」，卻是極為底層，例如，試圖說明為什麼紅色的筆，適合書寫哪些東西。

其中的差距，其實只有三個難以實踐的重點。

找到並擷取重點，採取正確形式，定時審閱檢討。

重點一：重點

無論是會議紀錄，執行工作中的紀錄，在學習新技術的筆記，都應該擷取並且記錄重點。

這是無庸置疑，但不見得容易做到。

以軟體開發而言，會議記錄的首要重點在於「結論」，而結論的重點在於「會議後執行的行動」。會議的過程，熱烈討論的經過也可以摘錄重點，但都沒有最後結論來得重要。

以學習筆記而言，如果是要學習既存的軟體程式，以便於接手未來開發工作，學習的紀錄重點在於「為什麼」程式會這麼撰寫，而非程式怎麼被執行。因為「為什麼」的理由可能只有當時的工程師才知道，而怎麼被執行，卻是原始碼的本身就會告訴你的。

以日常工作記錄而言，工作八個小時之後，重點在於紀錄「今天你認為已經完成的最有價值的事」。並記錄為什麼這是有價值的。

重點的節錄，不見得只有「寫下來」這種方式。當特殊email出現(例如變更規格email)，可以直接列印出來貼在筆記本上，不但節省記錄時間，還可以完整紀錄email時間和收件人。當技術討論會議結束時，將白板的複雜圖形拍照，直接email，或者列印，或者交由虛擬助理後續處理，都是簡單有效的方式。

庶務(註2)上的重點，也應該當重點擷取紀錄，但要切記不要將紀錄庶務，當作有價值的東西。應該統一記錄在某處即可。

補充一下：

在工作中，重點難以找到的原因很多。例如：每個人認為的重點不一樣；重點有時候會轉移；這事情壓根就完全不重要...等等。

根據自己對團隊組織的存在價值的正確理解，再加上對自己目標的認知，才能記到真正的重點。

以startup為例：三個初創的創業夥伴，各有1/3的公司股份，則必須要對組織未來存在價值有正確共識。假設其中一個人目標是希望能在2年內損益兩平，而另外兩個人則是希望在兩年內能獲得某程度的市場佔有率。這兩個目標就非常不一致，透過工作筆記「重點」的紀錄，很快就可以察覺不同（請參閱第三段審閱）

以在大企業工作為例：一個10人的軟體開發團隊，其目標是在某日之前完成某產品功能。其中有3人是負責品質(QA)，另外6人負責開發(RD)，還有1位是專案經理(PM)。作為QA的人，其工作記錄重點，就應該會與PM有很大的不同。QA的所有工作相關記錄重點，應該是「到目前為止」的品質狀況。PM則應該是「到目前為止」所有利害關係人的期待是否被滿足。

重點二：形式

工作相關的筆記，正確的形式能獲取效率。

形式的優先順序應該是：

1. 圖
2. 表格
3. 條列式
4. 一段文字
5. 沒有紀錄

換言之，可以畫圖就不應該做表格，可以是表格就不應該條列，可以條列就不要用一段文字描述。可以有機會紀錄，就避免沒有紀錄。

以軟體工程師而言，mindmap (心智圖)可以擴大思慮完整性，並且將事情想得完整。UML的各種圖形標準，則已經涵蓋各種技術的表達的可能性，幾乎不需要其他規格的圖形。

如果是專案管理的角色，則RACI(表格)會很容易表達各種則關係。但是，如果要和利害關係人報告，則不可避免的應該使用投影片(slide)形式，作為表達的形式。

形式似乎很簡單。但是缺乏對形式的正確認知和練習，只會事倍功半。

一些例子：mindmap(心智圖)可以作為決策樹的前身或練習。任何文件(ptt,word)的表格，應該先在excel中實作之後，在插入投影片。任何excel的條列，必須是二維，並且應該先試圖使用pivot做簡單的分析。

重點三：審閱

定時審閱工作筆記，構成對於過去工作價值的概觀。


審閱的方式很簡單。固定時間（例如每兩週，每個月）把過去一段時間的筆記攤開，快速看過一遍。誠實的面對自己，「二次紀錄」需要改善的地方，特別是哪些事情「浪費時間」。然後，每年，固定時間（例如剛過完新年）審閱過去所有的二次紀錄的地方，再次誠實面對自己，審思如何改善。

如果你已經每天固定紀錄「最有價值的完成事項」，每個月應該花10分鐘，審閱過去的筆記。了解這些最有價值的事項，累積起來，確實讓這個月過得有價值。如果沒有，則應該「現在馬上」進行改變，即便只是稍微調整工作的方式，工作的目標，有改變都比沒改變好。

工作的會議紀錄，則要審閱並且演討「會議後執行的行動」。特別是沒有達到的行動。

工作的學習筆記，則要審閱之前有問號(?)的記錄之處，是否已經都了解。在工作中如果有發現之前紀錄沒有發現的問題，則應該額外紀錄遺漏之處。

沒有固定審閱筆記，跟沒有做筆記基本上是差不多的。

沒有審閱並事後查核會議紀錄，等於會議沒有紀錄。

審閱，能達到筆記真正的崇高目的，也就是幫助「未來」而不是僅只記錄過去。





註1:不花錢學筆記，這本書不是免費，還是要花錢買。

註2: 所謂的庶務，指的是某些資訊或者行為，本身也許有價值，也許沒價值，但無論如何，它不是這個團隊存在的重要過程或目的。例如：某個特殊系統的帳號密碼，大企業裡某些申請經費的特殊流程，辦公室阿桑固定掃地時間，福委會團購產品方式，某些高層主管定時會議的地點等等。很多大組織（特別是公務機關）中的老員工，把熟知庶務當作本身的價值。在資訊不發達的時代確實如此，但在今日已流於荒謬。

---

沈思：

1. 工作筆記的其實和紀錄的工具沒有太大的關係。不過，如果你是在西元2006年之前投入職場的人，在哪邊可以看到10年前你的筆記呢？今年(2016)你的筆記，以哪種形式存在，會留存比較久？

資訊科技學生畢業後只想當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.  當你想要什麼，執行的方式如果是「碰運氣」或者「期望別人給」永遠都是最糟糕的選項，想要什麼最好是先構思自己要怎麼取得。

技術領導者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. 專案管理的技術領導要怎麼做？(參考資料）