企業巫醫 - 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的學歷可能會創造出一個一個的企業小巫醫，在組織裡三不五時的拿一些最新的企管叢書，當做驅趕惡靈的樹枝，到處鞭打真正在做事情的人。


企業巫醫相關文章：

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

實習生的三贏

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

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

犯錯怎麼辦 - 光是道歉是沒辦法解決滔天大錯的

人非聖賢，每個人，在任何時間地點，都可能犯錯。而一個人的職業生涯長達數十年，多少都會做出各種的蠢事。

錯誤也有各種不同的情況，細微小錯自然可以迅速改正，但如果犯下滔天大錯，不見得是道歉能夠解決。

最好的情況當然是「永遠不犯大錯」，透過個人本職學能，讓工作不會出現大錯。

但天有不測風雲，有時候錯誤的來源並非是能力不足，只是純屬於結構性意外，更可能屬於前人留下來的問題和漏洞，但無論如何，錯就是錯，大錯就是大錯。

鑄下大錯最好的做法的三步驟是：「面對」「處理」「學習」。但最後最重要的是，發揮創意把劣勢轉為優勢。

(1). 面對 - 承認錯誤，負起責任

如果是自己做的蠢事，道歉當然是必要的。如果不全然是自己做出來的，有時候也需要道歉，例如：企業產品發生問題，而你剛好是產品的負責人，雖然並不是你直接造成問題，但由於你是當時的負責人，自然要負起道歉的責任。

承認錯誤道歉僅只是第一步。負起責任不是簡單的口頭道歉，或者是土下座而已。所謂負起責任是要能「做出」行為。

既然是滔天大錯，道歉之後，隨即就是「妥善應對計畫」。這個計畫，一定要讓受影響的人清楚明白的了解。做計畫要快速，不見得完美，但是要全面，可以使用心智圖來協助達到全面性。

妥善應對計畫就和所有的計劃一樣，計畫的過程(planning)可能比計畫的本身來得重要。計畫的過程會大幅降低「連環出錯」的可能性，計畫的過程會讓「處理方式」變得有效，計畫的過程更可以讓受害的一方的影響降低。

舉例來說，如果某購物網站，因網站管理員操作不當，不小心刪掉資料庫中所有訂單，如果你是該網站管理員，首要之務當然是通知相關人等，道歉再道歉自己發生的錯誤。接下來，擬定「妥善應對計畫」：(1) 評估受影響的客戶數量，試圖從log或其他任何蛛絲馬跡中推估有多少訂單被刪 (2) 評估受到影響的金額，以及已經結帳後如果想退款的快速方式 (3) 首頁建立道歉網址 (4) 建立快速反應小組，提供電話與email讓受影響的客戶聯繫 (5) 相關社群網站或產品網站如果也受到影響需要找負責人協助  (6) 每日固定時間固定地點呈報修復進度 (7) ....這些應對計畫的細項可能有更多，但重點在於，有計劃自然能穩定人心，讓事實可以持續前進，而不會有錯誤的骨牌效應。

(2). 處理 - 誠實處理，控制損害

有計劃之後，接下來就是按計劃處理。處理原則如下：

(1) 誠實

不掩飾，但也不誇飾問題的嚴重性。誠實的處理可以挽回補償的事情，承認並道歉不能挽回的事情。在能力範圍中承諾最大的努力，但也不答應自己根本辦不到的事情。誠實的說明自己的能力不足，但也不能推託自己應該盡的努力。 

(2) 損害控制

既然是滔天大錯，大概一定會有很大的損害。按照計畫，盡可能將造成的錯誤損害降到最低。

(3) 小心骨牌效應

無論是壓力過大，或者環境本身的變化，錯誤常常是一連串發生的。處理錯誤最怕的是一錯再錯。例如，發生重大意外，投入直昇機救援，而直升機又發生重大意外的機率其實明顯的高於一般直升機普通飛行（參閱論文）。

(4) 不馬上釐清責任

此階段的重點在於執行計畫，控制損害到最低。而不是追究問什麼發生，是誰的錯！

(5) 記錄，檢討，修正計畫

即便計畫的執行很短暫，並且很急迫，也不要忘記簡單的紀錄，隨時檢討補救計畫的本身。並隨時修正計畫的執行。畢竟planning本身才是重點，而非plan。

(3). 學習 - 建立不貳過的絕對能力

當處理問題到一定的程度。無法在減低損害，但也不會讓損害繼續發生時。就是檢討學習的階段。

在這個階段，能補救都已經補救，無法挽回也都無法挽回。因此，是要檢討並且未來不會再發生的最佳時刻。檢討的方式有很多種，比較正式的做法為「post-mortem會議」。

會議進行方式採三階段，(1) 事實說明 (2) 事情經過的改善 (3) 避免再發生的作為

(1) 事實說明：

由犯錯的人或者代表人，從事件的開始說明到今天為止發生的事實。僅只是說明事實，並且釐清事實而已。

例如，購物網站不小心刪除訂單，過程可能是因為要釐清報表問題，以commandline方式進入資料庫，由於新增加一筆測試訂單資料，想要刪除資料時，執行delete的動作過程中，竟然忘記加上where condition。

事實說明過程可以提問，但目的是把事實釐清得更清楚。因此不需要問說：「為什麼當初你不這麼做」，也不應該說「你那時候腦袋在想什麼怎麼這麼蠢」之類和事實無關的話。

 (2) 事情經過的改善：

指的是「妥善因應計畫」執行過程中，有哪些可以改善的地方。基本上就是前段所述「處理」過程中的的檢討。如果有紀錄，則應該可以很快找到哪些地方還可以改善。

 (3) 避免再發生的作為：

這個階段就是重要的釐清責任階段。這個錯誤單純是人為錯誤？還是系統性錯誤？環境天災？釐清的過程要伴隨著「為了避免再發生而做的事」

單純人為錯誤：把某個人解僱就之後就不會發生？或需要靠某個檢驗機制？或讓檢查的本身加入SOP？或者過於粗心的人不適合做這個工作？怎麼樣定義何謂粗心的人？

系統性錯誤：這類型的大錯是不是歸咎於之前某人的設計不良？系統設計如何改善？系統性錯誤出現比率高不高？如果不能避免有什麼簡單方式可以大幅降低損害？是不是該雇用高手中的高手做好系統？

環境天災：特殊大地震或者異常天候？很低的機率才會發生？是不是要特別有處理方式？還是因為機率太低，可以視情況見招拆招？還是機率比想像中的高？

可以將所有「行動」逐一列出來討論。

最後，一定要「行動」。沒有行動的檢討，就不具備任何意義。而既然是滔天大錯，就必然一定要行動，才能做到不貳過。

---

I never lose, I either win or Learn: Nelson Mandela

最後，比較罕見的另一個重點：個人的創意與技能，要能將錯誤的劣勢轉為優勢。畢竟既然滔天大錯已經發生，能補救檢討都已經完成之後，有創意的將劣勢轉為優勢，是犯錯的個人最應該想的事情。

例如：一個遊戲app的廠商，推出新版本時，在伺服器端發現可承受的連線數量遠低於預估，導致於許多新玩家無法玩新版本遊戲，而舊版本又已經自動更新成新版本。當然許多新玩家會不滿，但如果遊戲廠商在處理過程中，額外彌補玩家的損失(送出高等級寶物之類)，其彌補的方式有額外的創意，這類型錯誤甚至可以額外吸引新玩家加入，這就是一種以創意和技能，將錯誤的劣勢轉為優勢的可能。

為自己工作 - 契合組織目標

雖然這幾年，創業蔚為風潮，但在台灣，大部份的人還是受雇於組織或企業。

「為自己工作」這句話看似自私，但其實所導引的結果才是對企業組織以及對個人有利。至少，對白領階級的知識工作者是如此。(註1)

表面上，大部份的人似乎並不是為自己工作。實際上，會去工作的原因是可獲得報酬（報酬涵蓋：薪資，技能知識學習，個人成長，成就感，社會參與感...等等），因此，無論表面原因為何，也無論自己是否有認知到這個事實，即便是受僱用者，絕大部份的人是為了自己，或者自己的家庭，而工作。

然而，在職場上常聽到各種抱怨心聲。其中有很大部分，其來源是沒有認知到自己是「為自己而工作」：

例如：

  *  工作很無聊學不到東西
  *  自己的價值不受到老闆重視
  *  對公司貢獻超級高，但是相對報酬卻很少
  *  做事人少，出嘴巴的人多 (特別是在政府單位)
  *  組織方向不正確，快要完蛋了

抱怨不是大問題，但失去自我方向之後，就很難在職涯上突破。個人的工作目的，必須要「由自己想辦法契合組織目標」。否則，就會有「不是為自己而工作」的念頭。一旦有這種念頭，很快的就喪失信念以及工作熱誠。

誠如前述：「為自己工作」這句話看似自私，但其實所產生的結果才是對企業組織以及對個人有利。

如果真切的認知到事實是「即使是受雇用，但自己其實是為自己工作」則進一步更能在工作上展現能力，切合組織目標。也更能給予組織更多的價值。因此，認知事實，才是生涯展開的最重要的事情。前述的理由就根本不會存在。

例如

  *  工作很無聊學不到東西：請隨意google一下就知道，企業組織雇用員工，不是為了讓員工學東西。而是解決問題或者產生新的價值。而工作學不學得到東西，也請google一下，都是取決於自己而非工作的本身。

  *  自己的價值不受到老闆重視：員工的價值就像在擺在口袋裡的針，只要你夠尖，有一天一定會穿刺而出。如果你覺得不是被擺到口袋，那就找到一個會擺你到口袋裡的組織。光是抱怨是沒有意義的。

  *  對公司貢獻超級高，但是相對報酬卻很少：先確定是自己的貢獻真的超級高。以業務員為例，許多大企業的業務，其業績是靠著大企業的品牌和產品，而非個人能力。以程式設計師為例，其程式產出，絕大部分是靠團隊能力，而非個人能力。

  *  做事人少，出嘴巴的人多 (特別是在政府單位)：也許你的生涯規劃就是要去這類型地方？如果是這樣，也沒什麼好抱怨。如果不是，就趕快離開，也沒什麼好抱怨。

  *  組織方向不正確，快要完蛋了：在一個快沉的船上，就是你發揮能力的時候。如果你自認為是個策略舵手，當然應該矯正組織方向。如果你覺得自己是在大組織裡的小螺絲，那麼你為何能「判斷」組織方向不正確？或許是你的判斷不正確？無論如何，你永遠有離開組織這個選擇。



在大部分時候，人總是可以找到契合組織目標的方式？主要有三種：「自然篩選」「個人規劃契合組織」「創業」

1. 自然篩選

當然，企業組織會自然的篩選「契合組織目標」的人。自然篩選的程度與經濟學上的「看不見的手」有過之而無不及。

例如：一個長期處於保守狀態的組織，自然而然會留下不積極的人。一個以退休津貼優渥的組織（例如公務員），自然而然，就會吸引「為了退休而工作」的人。當然，當一個人拼命念書，絞盡腦汁的通過高普考，一進去公家機關就數饅頭等著退休，自然就不會抱怨「工作無聊學不到東西」以及「自己的價值不受老闆重視」，畢竟，進來這個組織的真正目的，其實是為了退休...。

反過來說：一個新創事業，自然而然會吸引想要透過自己的能力，積極開創一片天地的人。而「退休津貼」就不可能是工作的首要目的。但工作是否有趣，組織方向正不正確，就成為關鍵因素。

雖然，個人沒辦法影響「自然篩選」，但如果你的工作目標，和「自然篩選」的目標不一致，當然會工作的很痛苦，而抱怨連連。

解決自然篩選的方式有三種：(1)離開 (2) 改變自己 (3)改變環境

其中，離開是最簡單的。辭職換新工作，自己創業，創業失敗後再創業等等，都是離開。

改變自己很難。但潛移默化之下，很多人會因為自然篩選的環境而改變自己。

改變環境其實難上加難！但是，一旦有機會做到改變環境，你就擁有一個難以言喻的經歷。這個經歷對職涯有絕對的幫助。

2. 職業生涯規劃契合組織

傳統企業組織都知道，激勵員工很重要。但組織出錢出力，費盡心思的「各種激勵」其實遠遠不如讓員工的生涯規劃契合組織目標。

就前段所述，其實無論如何，自然篩選會讓組織留下契合其目標的員工。但這需要起碼數年的時間，而前提也是組織沒有大的變故。 如果組織 - 特別是營利企業 - 的目標和其展示的行為不一致，自然篩選會失衡，要達到平衡。

因而「以個人力量做出契合組織的規劃」才是最簡單，最容易，最能獲得三贏的選擇。

除了工作內容外，每個人常遇到工作上乍看之下不可伉儷的因素，而認為自己無法契合組織目標。在你還沒有丟出辭呈之前，可以執行的個人能力與選擇非常的多。這些選擇都可以有機會做出契合組織的目標。

例如：

* 每天都做無聊的工作：既然是無聊的工作，表示是重複簡單類型，試著將這類工作最佳化，並自動化(註2)。 不知道怎麼自動化？那就去學阿，在工作中學習成長，並透過自動化的貢獻，不但提昇自己的能力，也讓組織獲取更多價值。

* 工作太多，常常超時加班，生活品質太差：所有企業組織，其存在的目的，絕對不是要員工加班完成目的。其存在的目的都是為了獲利。隨著組織分工，以及各種環境變化，容易產生以「加班」的方式來解決問題。這完全可以避免，請參考：解決專案困難的最爛方式; 如何提高工作效率; 80/20法則。也可以網路搜尋一下任何增加工作效率的方式。

重點在於去做！Just Do It！不去做，永遠不知道加班問題能否解決。

* 加薪升遷不如預期：如果是在大企業工作，加薪升遷的確常常不如自己預料。但如果你確定自己有這樣的價值，一段時間一定會被發現，如果不被發現，在離開之前請先想清楚「自己是否真有這樣的價值」？想清楚的方式也很簡單，可以去試著去應徵其他組織，看看有沒有其他組織願意提供給你更好的薪資福利。如果沒有，表示在當下你的確無此價值。如果是在小企業，薪資福利可能無法有大幅成長，但小公司能提供的通常是更多的自由和自我成長。既然你已經自然被篩選到小企業，或許本來就不是很期待制式的加薪升遷了吧。


* 組織做犯法或遊走在法律邊緣的生意：趕快辭職離開！越快越好。你確定你想要加入犯罪組織或者遊走在法律邊緣？！

3. 創業

創業，當然就是為自己工作，當然也一定會契合組織目標 - 因為你就是組織。倘若你創了業，卻因為各種原因，去做不是你訂立的目標的事情，那等於是沒創業。(註3)

不過創業成功難非常高（參考如何確保創業成功）。富貴險中求，高風險當然比較能伴隨高獲利，如果生涯的志向在此，盡可能參考已經成功的典範，或許能降低失敗機率。

---

註1: 藍領階級的勞動工作者可能不全然適用。

註2: 同註1

註3: 當然，也許你是共同創業，或者持有股份很少，那麼請視為在組織為自己工作，不要視為自己創業。

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

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

剛畢業準備加入開發團隊 - 三個必要的Scrum突圍方式

真實故事 1:

某個陰暗的冬天早上，悠晃進辦公室的當下，看到二十多個人圍成一個大圓圈。既不可能是營火晚會團康，也不會是祈福默禱活動。好奇的在旁邊觀察一下，在圈圈邊上的某個中年男子開始要求大家在這個stand-up會議報告進度，並祈許新採用的Scrum方法可以讓軟體開發有良好的發展。

真實故事 2:

某一次專案研討會中，演講者詢問與會人士，Scrum估計工時的時候，每個人每個工作天應該是多少小時才合理？新鮮人多半回答6-8小時。某些資管企管碩士生，大概讀了許多書，回答:「4小時」。而一個在軟體外包廠商工作的專案經理回答:「10小時」。

Scrum是最近幾年很流行的Agile(敏捷)開發方法之一。它的概念照理說簡單易懂，很容易在現有的團隊中採用運作，或許是因為趕流行？許多資訊產業開始以採用Scrum方法為榮。而各類型顧問也都開始教授Scrum，也開始頒發各種結業證書甚至Scrum Master的執照。就在短短數年之內，在台灣業界Scrum似乎無所不在，成功案例一個比一個容易找到。

但是就像其他簡單易懂的事情一樣。Scrum說起來比做起來簡單。實際實施的時候需要克服慣性與人性，克服與目標之間的各種障礙。但也因此，把握住Scrum的精神，最能夠讓畢業的學生以正確的方式加入軟體開發團隊 - 即便這個團隊此時並未實施Scrum。

追本朔源後，總是可以看出：太陽底下始終沒有新鮮事。Scrum最早正式出現在1986年的一篇文章中(Scrum最早的文獻)：透過個案的深入觀察，兩位日本學者對於有彈性，有效率的產品開發過程中發現一些相似的點：內建的不穩定性，自我組織的團段，互相重疊的開發流程，多面向學習，精微的控制，組織裡習得經驗的轉移..等等。文獻中的產品大部份都是硬體，例如汽車或者影印機。

乍看之下，和現在的軟體開發方法論似乎沒直接關係，但是，而後在經過其他學者的後續觀察歸納。這種以事實為基礎的彈性結構，遠比傳統官僚結構，更能在短時間達成高效率，甚且更容易產生創造性思考的價值。

理論歸理論，如何實踐理論在工作上才是重點。

近年來畢業的資訊科技背景的學生，的確在學校多少聽過Scrum，許多資管的學生甚至上了不少相關的課程。但就實務的角度，除非教授像這位荷蘭的老師（eduScrum）一樣，真心誠意的採用Scrum在課程的本身上，否則對剛畢業的碩士生或大學生而言，Scrum就只是個似乎看的到，卻無法做得到的事情。學界與業界間的藩籬，仍然巨大看似難以突破。

因此，提供以下有三個務實的方式，可以作為剛畢業的學生突破藩籬的參考。

1.理解事實

對於剛畢業的學生來說，理解事實，是基礎中的基礎，但也確是整個職業生涯需要不斷強化的地方。

以Scrum而言，每一個要做的事情 - 也許稱之為一項backlog - 在正在執行人的手上只有三種狀態：「還沒開始」，「進行中」，「已經完成」。

在每日stand-up，最常發生的是產生另一個狀態「快要完成」，也有可能混淆「已經完成」和「進行中」，更糟的是混淆「還沒開始」與「進行中」。

舉例來說，小馮在每日stand-up會議說：「訂單查詢功能已經差不多了，因為訂單查詢結果的排序雖然弄好了，可是分頁還有點問題，但是快要好了」。也許在學校裡和指導教授報告論文進度這種描述是可接受的。但是在Scrum的精神裡，這種描述不但沒有必要，而且會引發更多問題，因為，接下來大家就需要探究所謂快要好了，是還要多久？最簡單正確的描述應該是「訂單查詢功能正在進行中，原本預計2天完成，已經花了1天，接下來1天會繼續完成，目前估計和預估所需時間一樣是兩天」

重點並不在於咬文嚼字，而是在於對事情的清楚認知。當意識到一件事情沒有完成，在產品開發裡，終究是沒有完成。

每個人多少都有報喜不報憂的心態，也多少都希望別人對自己有好印象。因此，常會有自己也欺騙自己的時候。Scrum的每日Stand-up站立會議，僅說明三件事情：1. 從上次會議到現在完成了什麼 2. 在下次會議之前打算完成什麼 3.有遇到什麼困難。僅只三件事情而已，不多不少。

剛加入任何形式的開發團隊的人，能先確切的掌握和自己相關的事實，是看似簡單卻需要時間實現的基礎。

2.控制時間

既然Scrum是屬於Agile的方法論之一，當然符合最早的Agile 12項基本精神（參見這裡）。其中幾個精神和時間有莫大關係，例如，可用的軟體大重於詳細的文件，回應變化重於遵循計畫。而Scrum是最能達到的方式。

以團隊的角度，burndown chart(燃盡圖)是最能表達團隊目前能力，與專案時間預估的方式。他的做法極端簡單，請自行參考wiki。burndown chart展示了血淋淋的事實，可以透過過去一段時間的完成速度，有效預估專案可能的完成時間。由於這種做法去除了人類心態上的偏誤（例如：大家再努力一下，接下來某東西可能比較簡單...諸如此類），因此在沒有能力，沒有創意，沒有實務開發經驗的產品或專案經理的眼中，burndown chart只是拿來參考用，不能給長官看到。

以剛畢業的學生而言，最難的事情在於預估時間，特別是在比較長期複雜的任務。


解決方式為兩步驟：
  (I) 決定第一件要做的事情並且去做 
  (II) 額外增加研究項目(也額外增加時間)

(I) 決定第一件要做的事情並且去做  

對於很長的項目(backlog)，表示他可能隱含數個子項目，而每個子項目可能也不小。例如，讓系統可以支援facebook帳號登入。這可能就要分成數個項目。當然對於新鮮人，分拆項目可能會遺漏，但是，有分拆比沒分拆好，有估計比沒估計好。有分拆之後，如果有漏列項目，也可以清楚知道有漏列。有估計之後，估計的錯誤以後還可以作為其他項目的參考。
而分拆之後，就直接進行第一件要做的事情！確實的腳踏實地去做！不用等，也不用試著把項目分拆的很精細，估計得很詳盡。因為萬事起頭難，當已經開始進行，就很容易知道之前想法是不是正確，還有沒有遺漏。關於項目的分拆(breakdown)可以參考這篇。

(II) 額外增加研究項目

如果分拆之後，很明顯的仍然難以著手，就額外列出一個有限定時間的研究項目在最前面。換言之，花個固定的4到12小時進行學習與研究，將這件事情也列入整個開發流程中。時間必定要是有限的，畢竟絕大部份的產品開發，無論多困難，都還是在有限時間一定可以找到解決方案。

從另外一個角度而言，如果在有限時間無法找到合理的解決方式，對新鮮人而言或許你也並不適合做這個行業，可預見的未來裡，或許你會勤能補拙，試圖用更長的工作期間達到成效。但是這並沒有太大的意義。因為你並不拙，只是專長不在此，在有限的時間投入內，了解自己的專長不在此，或許更能幫助新鮮人找到最能讓自己發揮專長的地方。

3.確保產出

每個backlog表示一項「產出」。只要前兩個精神：理解事實跟控制時間，已經有效掌握，那麼這一項應該不會有太大意外。然而，對於剛畢業的學生來說，無論程式能力有多強，對於產出的完整性，常常會有誤解。不過這樣的誤解其實也很容易釐清。

一般軟體開發團隊，某人的某功能程式碼寫完之後，會經過以下階段：

1. 程式碼完成
2. Unit Test完成並通過
3. 簽入版本控制系統(commit)
4. 通過code review會議
5. 合併到產品主線
6. 通過自動化編譯建構
7. 通過自動化整合測試
8. 通過QA測試
9. 經過產品經理(Product Manager)確認

在Scrum一開始，便應該定義何謂backlog完成？
- 會是 1.程式碼完成就算完成？
- 還是 6. 通過自動化編譯建構 才算？
- 甚且是要等 9. 經過產品經理確認 才算？

有許多開發團隊，產出的本身是透過「默契」來達成。然而就新鮮人而言，一開始一定比較難取得「默契」。開口詢問，並且在三確定產出的「要件」是剛畢業的學生常忽略的要點。

參考閱讀-> 如何快速充實自己

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

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

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




  

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

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

詭異的是，幾乎所有已經在資訊科技領域工作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)你的筆記，以哪種形式存在，會留存比較久？

努力才會成功：三個錯誤方向

有努力不見得有收穫，但沒有努力就沒有收穫。因為努力是通往成功的唯一道路。

然而，對於努力有很多錯誤的認知方向。

以下列舉最常見的三個錯誤方向：

錯誤一：「用力」就等於「努力」

「努力」和「用力」是兩回事。

試圖只用雙手去移動開一整座高山是「用力」；研究各種方式和技術，挖出一條筆直的隧道是「努力」。

在專案遇到困難時，千篇一律的超時工作，無止盡加班是「用力」；探究各種技術的突破，讓專案有進展是「努力」。

在傳統企業推廣資訊科技應用時，苦口婆心的淳淳告誡是「用力」；透過強迫的方式，逼使使用者改變習慣是「用力」；透過各種巧思，讓人願意自己使用新系統是「努力」。

錯誤二：努力一萬小時就會成為天才

小提琴家Auer曾回答學生說：「用手指練琴，可以練一整天，但是如果用頭腦練習只要一個半小時」（參考這篇）

「努力」是需要花時間，然而，努力更要花的是思索以及驗證事物的本身是否朝著正確的方向。瘋狂的往錯誤的地方磨練一萬小時，不會讓錯誤變成正確。那努力一萬個小時變成天才，指的是有用頭腦的一萬個小時，而非不經思索的一萬小時。

但是，努力所花的時間容易被人看到，而且容易讓人產生「同情」。因而，在企業中長時間加班的人，很容易被表揚；在專案延誤時，帶領團隊不眠不休努力，容易被認為是負責任；讓專案順利完成，讓系統保持為定沒有問題，容易反倒被認為沒事做。如果你是領導者，切記不要過度獎勵沒有功勞也有苦勞的情況。

錯誤三：努力的筆直前進

如果目標與達到目標的方式是錯的，努力就變成可怕的慘狀。許多人常被一個故事所誤解（掉到奶油桶的青蛙）認為只要堅持下去，也許事情會有轉機。然而，故事裡的青蛙其實已經採用正確的方式 - 也就是一直游蛙式。如果青蛙使用更有持續性的方式維持生命 - 也就是水母漂，那麼無論如何不可能攪動成為乳酪。

幾乎任何情況下使用googlemap規劃最短時間的路程，絕大部份都不會是筆直：最短時間的路徑，通常不是最短的路徑。

努力的目標要正確：確定努力的目標是你真正想要的目標。

努力的方式要改進。努力的增加知識與能力，讓進行的方式可以朝向最正確的路徑，而不是看似最筆直的路。

在盈利企業裡面，整體努力目標應該是合法的獲取利益；然而，在企業裡面投入工作的個人，在工作上卻應該是根據自己的工作內容訂立正確的目標，如果是業務當然是獲取訂單，如果是生產部門，也許是極大化產量，也許是平衡品質與成本。但是，下班後，目標應該是自己的目標，例如陪伴家人之類。

一個業務，無論採用什麼方式當他的業績，一年後沒有達到目標，當他要「繼續努力」的時候，一定要採取別的方式。繼續堅持用舊的方式，也需要「努力」了解為什麼舊的方式可以持續使用，而不應該改變。

大部份的專案，目標通常都已經定好，然而執行的方式卻應該根據實際的情況改變。例如：在前期中期發現有重構(refactoring) 的需要，就應該先考慮重構，而不是試圖先達到某個帳面上的milestone。

大部份的辦公室日常活動，其價值都越來越低，努力的方向不是增加手指打字的速度，也不是加班完成任務，而是朝向去除完全不必要的事情，簡化或自動化簡單的事情前進。

---

沈思：

努力而失敗的例子太多，可以找到在你的工作領域上的例子嗎？

成長的最好方式 - 反省

曾子曰：「吾日三省吾身：為人謀而不忠乎？與朋友交而不信乎？傳而不習乎？」

反省是進步的最好方式。然而，檢討專案，檢討工作內容，或者檢討自己做對了，或做錯了什麼，卻是需要有結構性的方式來進行。光在腦袋裡想像是很難有具體效果。

普通人大概沒辦法跟曾子一樣每天反省自己，不過，新的一年通常是反思的最好時機。

檢討反省有三個要點：

重點一：目標導向

檢討需要有目標，就算是很隱私的個人檢討也是。反省的目標不同，就會有截然不同的結果。

以帶家人出去玩為例：

如果「全家開心出去玩」是「目標」。則旅途中的延誤，改變行程，物品遺失的檢討目標就應該是如何在意外發生的時候，讓家人仍然很高興的享受意外，享受旅程。

然而，如果心理設定的目標雖然是 ：全家開心出去玩，但檢討的目標卻是怎樣更有效率的旅行，那最後很可能導致全家旅行越來越有效率，但大家心情越來越不好。



以專案管理為例：

在專案完成，或者一個sprint的結束，在回顧檢討(retrospective) 會議的做法，通常是讓大家以「實例」，說明哪些事情做得好，哪些事情做得不好。接下來將這些實例分類，並且用投票的方式，選出最最最需要改善的幾點，指派專人在下一階段負責改善。

同樣的，負責人是以最終目標為檢討改善的目的。假設某手機APP的開發，最終目標是「能在耶誕節前有百萬使用者」，則列出最需要改善的幾點，都必須要朝最終目標前進才對。因此：「與客戶協調上架遞延到12/24日以便確保品質」就是一個不很合理的目標。

要點二：用事實去除人類偏誤

正常人都是以自己的主觀來看這個世界，因此每個人都有對事情的偏誤(human bias)。

檢討與改善的重點在於：盡可能認知人類認知偏誤的存在，讓偏誤在不造成致命影響。不過，要完全沒有影響幾乎不可能。

人類偏誤有很多，舉一些例子如下：

歸因謬誤：對於自己的行為，容易歸類為外在因素，對於他人的行為，容易歸類為內在因素。例如，自己遲到，容易認為是塞車，或者昨天太晚睡；別人遲到，容易認為是他的紀律問題。

負面偏見：人對於不好的記憶印象比好的記憶深刻。這可能和演化有很大的關係，人必須要先規避毒蛇猛獸之類的天然風險。

稟賦效應(Endowment Effect)：同樣的東西，如果已經在手上，則會難以放棄；但如果不在手上，卻認為比較容易取得。例如，自己的車子想賣，總是會想要賣比較高的價格，並且自己也會對這個高價格找出自認為合理的原因。這也是大部分物價易漲難跌的因素，因為銷售物品的人，如果已經用100元能賣出某物品：即便成本降低，即便知道降低售價可能增加業績，但在心理上很難主動降價。





誠如前述，要去除自己「所有的偏誤」是絕對不可能：沒有人是聖人，永遠不會犯錯。但是，去除不必要的偏誤讓自己朝正確的方向前進，卻是不難達到。去除自己的偏誤最好的方式就是根據事實。

因此，在檢討事情的時候僅就「事實」加以檢討。

例如：

事實是「專案每日會議，5個人有3人一定會遲到30分鐘」，根據事實檢討如何讓這3人不會遲到，不需去研究3人遲到的個別因素。也因此，根據事實，將會議時間往後延30分鐘是合理選項。

但是，如果有人試圖追尋某個老是遲到的人的「個人紀律」，「團隊精神」這並非不是事實，只是這類型的事實，沒辦法客觀認定，也不可能客觀評量某一個人的「個人紀律」比另一個人來的好。因此，這些主觀的「事實」，因太容易有主觀偏誤，不應該作為檢討的項目。


再舉另一個例子：

事實是「目前手機APP是使用者付費9美金才能下載，目前每個月約有1個新使用者」

檢討的目的如果是要增加收益，則在現在的事實基礎上，資訊是遠遠不足。因此，這個事實的討論結果勢必是「沒有足夠的事實」可以檢討。

當然要找到所有的事實也是不可能。所以，在這個例子中，起碼找到「新使用者為什麼會買」，「其他類似APP是否收費」，「其他類似的APP在不收費的情況有多少使用者」等等資訊，以便作為檢討的基礎。

方向三：行動優先

反省檢討的目的，不僅只為了知道「我錯了」，重點在於「如何才不會再錯一次」，或者「怎樣讓事情變得更美好」。

誠如前述，人非聖賢，要變成完美的人是不切實際的期望。然而，改變自己的一小部分想法跟行為，讓自己的未來變得更好，卻是可以腳踏實地的達到。

行動必須要和反省與檢討一致，至少邏輯上一致。行動的本身不見得一定要有所「行動」，有時候不做任何事情也是一個選擇，但如同這裡所描述，要確定「不行動」這個選項是和其他選項一起考慮過。

例如：「目前手機APP每個月有1個新的使用者，想推廣給更多使用者」，經過檢討之後，覺得「利用社群網站」：這裏的行動就是利用社群網站推廣。可能是利用facebook的廣告，也可以利用團隊成員每個人都到facebook上貼文，也可以建立粉絲頁。

無論如何，既然要檢討，就應該有行動。沒有行動的檢討，不具任何意義。

---

沈思：你大概多久會檢討自己一次？

資訊科技學生畢業後只想當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. 專案管理的技術領導要怎麼做？(參考資料）

關於技術領導者-team leader 的三個基本概念

資訊科技產業裡面，常有稱呼為小組長，team leader的人，通常負責帶領小團隊前進。這裏簡單說明一下技術領導者的三個基本概念：

(1) 什麼是資訊科技的技術領導

傳統組織隨著人數的增長，通常自然會產生階梯(金字塔)型的結構。然而，這類型的結構把階級當作激勵員工的方式已經不太流行，反倒是以虛擬小組形態，組合不同的小團隊來完成階段性任務，已經逐漸變成常態，特別是在資訊科技領域。

因此一個專案任務，視其大小，需要某一個人負責帶領1-7個人，完成一件任務，而這1-7人並不直接在這個負責人的管轄，也就是另有管理經理負責。這種人，在此稱呼為技術領導人(tech-lead, 小組長, scrum master…總之有零零總總的不同稱呼) ，但其定義僅如下：

                (1) 領導完成任務或部分任務

           (2) 領導1-7個人

           (3) 並非這些人的直屬上司

台灣的學生第一次有機會作為軟體專案技術領導，可能是在學校進行專案的時候。屆時，雖然教授會給予方向上的指導，但事實上是由學生完成，數個學生所組合的團隊可能有各種方式選出一個”組長”。

投入職場之後，運氣好(或者運氣不好)在兩三年內可能會負責帶數個比較新進的同事，主要目的仍是完成某任務，如果組織比較扁平實際的主管也許不會直接帶領新同事，此時，所謂的資深工程師，就很快面臨必須做一個技術領導的挑戰。並非每個人一出生就是個好領導人，但是如果沒有意識到作為技術領導的重要性，則很有可能造成三輸的局面：新人很快陣亡；主管不滿意帶人的績效；自己也不高興。而成功的帶領同仁完成任務比較可能達到三贏：新人很快能貢獻給團隊；主管的期待被滿足；更重要的是自己在技術以及領導力上有所成長。

(2) 技術領導與管理階層截然不同

作為技術領導者，因不是直接管理工程師，所以只能透過領導以及可信服的技術能力來帶領成員。因此，相較於實際管人經理有優點也有缺點：

        優點：

                * 無須擔負直接管理責任(不需要負責解雇人)

                * 不需要直接負責成員的心態問題以及生涯規劃

        缺點：

                * 無法使用職位快速以上對下的方式達成小型任務

                * 對於明顯有心態上的問題的成員無法快速汰換

                * 難以對團隊成員提供誘因

(3) 就業市場非常需要技術領導

一個好的技術領導者Team leader在就業市場上奇貨可居。

資訊科技的就業市場過去數年一直在成長，每年畢業的學生雖然眾多，可是就業市場似乎傾向於取得及時戰力。而有實質經驗的技術領導者，比主管經理的市場更大，因為主管經理不見得一定能夠帶領技術，也可能距離實務已經有一段時間，然而技術領導者需要帶領小團隊前進，正常的情況下本身就需要具備技術領先的能力。

更有甚者，現代組織都希望層級不要太多，扁平化在成熟組織幾乎是常態，People Manager - 也就是所謂帶人主管，通常直接帶領的人數會越來越多，也導致非直接帶人的技術領導，通常才是直接參與開發工作的領導者。

---

沈思

* 如果我已經是技術領導者，我要怎麼提升自我的能力？ -> 參考這裡