如何提昇士氣激勵團隊成員 - part2 - 三件一定要做的事 (軟體主管的31堂課)

激勵團隊成員士氣，是在軟體開發團隊中，最好的提高績效與成果的方式。這又是一個所有人都知道，但是很難真正做到的事情。想要作為一個好主管，應該要有某幾種可激勵人的行動。

有幾件用處不大，做了不會有傷害，多少會花點時間，如果有其他人的協助當然可以執行，但是不建議軟體團隊主管花太多時間在這類事務上：

* Team Building：找個空擋帶著團隊成員出遊
* 零食飲料：在辦公室塞滿各類型零食飲料
* 生日卡片，慶生會等等

真正有用的事情，恐怕都要花點時間，有幾件事情的做法可供參考如下：

一：透過聆聽了解團隊成員的需要

在1vs1的時候，放下心中成見，專注於聆聽團隊成員的真正心聲與需要。每個人會工作有必然真正的原因驅使並激勵這個人。

困難點在於每個人的激勵因素都不同，一般認為，軟體工程師會持續激勵有高績效產出「可能是」因為：
(a) 完成程式執行順利時候有種滿足感
(b) 自己也能夠學習成長
(c) 團隊溝通順暢協作愉快
(d) 強烈認同組織目標
(e) 對團隊有影響力 能夠被人認可
(f)  ....其他...(家庭之類)

以上雖然都有是原因，但是每個人真正的「激勵因素」卻差距很大。需要靠one-on-one時，盡量耐心聆聽出每個人真正背後原因

絕大部分的情況下，軟體工程師不會真正為「錢」而工作，當然千萬不要因為這樣就降低薪資，錢是屬於保健因子，沒有足夠在人才市場競爭力的薪資，是絕對無法找到能力好的工程師。但是，工程師會留下來持續高績效的產出大部分也不是因為錢。

二：根據需要，量身訂做能做的事情

聽起來好像是廢話，但是每個人的需要會讓主管該量身定做的事情差異很大。而且執行起來極端困難 -- 不過本來作為主管就是困難的事情。

這點有空會再說明一些實質作法。

三：透過直接了當的方式，表達重視團隊成員

絕大部分的人都是「被需要的」。在許多時候，主管多少會忽略「現在做的很好」的團隊成員，將心思放在做的不是很好的人身上，這其實無可厚非，畢竟，現在做的好的人，雖然通常表示思慮成熟，做事完整，並且也能自我學習。然而，這並不代表這樣的人知道主管「其實很重視他」，尤其是高績效的人常常也是獵人頭無時不刻的挖角對象。

直接了當在one-on-one的時候，對現在績效高的人講這句話：『你對我來說非常重要，我們團隊是真的需要你，我也很需要你的繼續協助』必要的時候可以在one-on-one開頭，中間，結尾都講一次。

企業巫醫：應該要在同一間公司待多久？

一個在就業市場工作的人，到底應該在一間公司待多久才算「正常」。就產業的不同，自然有截然不同的答案。就資訊科技領域來說，過於頻繁地更換工作，會讓求職者更難找到好工作。

何謂頻繁更換？當在現有工作遇到瓶頸，自己有機會透過自身能力改善瓶頸，然而卻選擇離開就算頻繁。

真要講個數字的話：
* 工作7年以上，在最後7年的職業生涯中，但不在任何組織中待超過2.5年，就會被列入低優先考量 - 並非完全不考慮，而只是不優先聯絡。
* 工作3-7年，但不在任何組織待超過1.5年，也是屬於低優先考量。
* 工作3年之內，其實到不用太在意。

理由是 考量「大部分的情況」，而非考慮「極端情況」。

大部分的情況是：

工作7年以上，但最後的七年，沒有在任何組織待超過2.5年，表示曾經換過起碼4~5個工作。然而資深的工程師，通常其工作內容是比較困難的，並應該能展現其架構設計與實作的經驗。可是，如果其架構設計，並沒有被「市場驗證」那就很難用各種方式評斷他的真實能力。講得更直白的是：也許這位資訊工程師，雖然有Ｎ年工作經驗，但搞不好每次都挖洞給別人跳，自己拍拍屁股就走了。或者是，也許他工作能力其實普通，但「自我感覺太好」因此老是覺得自己應該找到更好的工作。而更重要的事實是，他的確離開了，這事實也表示這4~5個工作並沒有「留才」的意願。兩年半是最低限度檢驗一個工程師，在技術上能取得「市場驗證」的時間，兩年半表示工程師至少經過兩次以上的績效考核，並且其工作的正面負面評價也容易以事實檢驗。

極端情況是：這位資深工程師運氣太差，雖然各方面能力都好，但就是遇人不淑，常常遇到公司倒閉。或者有不得已的家庭因素。

許多企業巫醫都有各種不同的見解（請參見最下面的參考文章），但整體來說，職涯長短雖然因人而異，但最好不要把自己視為特殊例外。而應該以市場上的事實，來推估自己職涯最適合的況狀。

舉例來說，有些人認為只要沒有成長學習性，就應該換工作，但是過去七年沒有一個工作做超過兩年半，難道表示這五個工作的內容「統統都學精通」？如果老是遇到不好的工作機會，是否就表示「自己對專業工作機會的好壞判斷有問題」而專業機會的判斷，通常也是資深工程師應該要具備。

就業市場的事實是過於頻繁換工作「通常」表示有問題，頻繁換工作的大部分人是屬於通常，而非特殊例外。


參考文章：
* 在一個公司裡為何要待十年的十個好理由
* 在一個公司待太久不好嗎？
* 在同一公司內部發展職涯才聰明
* 在同一間公司不要待超過四年喔
* 你在公司待很久了嗎
* 在一個公司待太久會對職涯不利嗎？

何謂：資深工程師

在招募人才過程中，經常被問到「資深工程師的定義是什麼？」

以軟體開發的角度而言，資深工程師有三個面向：

* 技術能力
* 實質經歷
* 團隊合作

聽起來簡單，其實不太容易。

技術能力指的是對「現在使用的技術的直接掌握能力，以及持續成長態度」。

實質經歷指的是「過去曾經做過哪些事，取得哪些成果」。

團隊合作和前述的實質經歷略有關係，不過指的是「處在組織裡，透過自己的能力對組織造成正面的影響」

在人才招募中的過程，在有效時限內，對應徵者針對這三個面向判斷是否符合「資深工程師」是有點難。有幾個方式可供參考。

技術能力

現在使用的技術的直接掌握能力。最簡單的方式是設計考試或者實做作業，根據其結果來判斷技術能力。典型的證照例如SJCP, CCNA都屬於此類。當然， 也常有組織採取直接面談的方式來判斷技術能力。

直接掌握的能力，當然不包含應徵者，自我宣稱說："這個我google的到"，或者，"我不記得但是查得到"。畢竟大家都可以查得到，既然都查得到就不是判斷的標準。

技術能力的判斷上：考試，作業，面試各有其優缺點。簡單的說，人為介入越多，就有不客觀的判斷；但是，無人介入的純客觀單純考試，難以判斷設計概觀等複合的技術能力。

使用半開放性的實做作業，加上2人以上，事先決定好的面試結構，應該是比較妥善的方法。不過，請避免幾個認知偏誤：(1)月暈效應 (2) 羊群效應 (3) 觀察者效應。這些偏誤，在技術面試時會特別嚴重，因為許多人會誤以為技術面試很「客觀」，但實際上，所有面試都很主觀。唯有特別注意偏誤，才能盡量降低主觀性。

月暈效應：因為某些光環，讓面試官覺得應徵者可能很厲害，而沒有去驗證事實。舉例來說，有三十年程式設計經驗，又做過某些驚人專案，就假設此應徵者「隨便學什麼都會」。又或者某應徵者可能是網路傳說的「大神」，就覺得他可能很厲害對團隊很有幫助。

羊群效應：面試之後的討論，如果有人先有意見，沒意見的人可能就會追隨之前的意見。

觀察者效應：因為外表或履歷表的直覺或第一印象，而讓面試官試圖尋找錄用或者不錄用的證據。而非客觀的先收集事實。

最後，在技術上持續成長態度很簡單，能認知到一個事實「當自己學的越多，表示自己不會的越多」，並且真有實質行為-固定閱讀也好，非工作之外寫程式也好，其他任何實質行為佐證對資訊技術有成長喜好。

實質經驗

所謂資深，當然表示在軟體開發類型的工作上，有很多經驗，並且這些經驗取得成果。

資深的實質經驗，通常包含「好事」以及「壞事」。更重要的是，經歷過的壞事，知道如何真正改善它。並且認知到，不是所有錯誤都是別人的錯，必然有自己的錯。

面試實質經驗也一樣要破除上一段的認知偏誤。就不再贅述。

團隊合作

資深工程師，能體會真正的團隊合作要素：(1) 技術溝通透明 (2) 控制進度透明 (3)  立基於事實的溝通

技術溝通透明是指：任何單純技術上的選擇，使用，表現，都是透明的。簡單的說，能真正了解技術完全不需要任何的隱瞞性。

控制進度透明是指：了解透明進度對團隊非常重要，並也了解：控制進度的單位是時間，而不是工作內容。

立基於事實的溝通是指：雖然許多事情必須要有假設和猜測，但就工作上的決定，必須要盡量立基於事實。舉例來說：「我覺得最近的release可能會有問題」這就是一種猜測的說法，然而：「最近的release並沒有執行回歸測試，所以我覺得可能會有問題」這也是一種猜測，但卻是立基於事實的猜測。

企業巫醫：公司需要你，還是你需要公司？

每年年底照例有不少人考慮轉換跑道

換工作是很個人的考量，每個人狀況有很大的差異。然而，當生涯成長變成首要因素時，其中一個考量點是：「公司需要你，還是你需要公司」？

盈利企業當然需要各式人才，讓企業持續成長獲利。但每個人在組織中的重要性不同，特別是上千人的大企業。即便主事者真心誠意認為「每個員工都是公司寶貴資產」，但就事實來看，上千人的組織，不可能「每個人」都是寶貴資產。

因此，在想要轉換跑道之前，先衡量一下，到底公司需要你的程度如何？請記得衡量標準不是你的個人能力，而是公司需要你的程度。

了解自己被需要的程度有幾個方向：

(1) 有機因素 vs 有毒因素

有些時候，某些人以為掌握特定資訊，是被需要的因素。然而，這是屬於有毒因素。換言之，如果只靠掌握某些資訊是很危險的(註1)

舉例來說：在大企業中，專案從開始到結束有一定的流程和系統需要專案經理維護資料的正確性，例如填寫各種表格之類。然而如果專案經理「很會」填表搜集資訊，並且甚至知道很多「秘訣」，這並不是真正「被需要的」理由，而僅只是資訊掌握。將這個因素，作為被需要的原因，就是屬於有毒因素。又或者，僅只是在一個組織中待了很久，知道許多「眉角」，這並非壞事，但僅靠這點不應該被依賴的原因。

大部分的人，都能靠自己的能力產出價值，這就是有機因素。最簡單的情況就是：一個程式設計師撰寫所需要的程式，自然就產出價值。又或者一個廚師的手藝驚人，自然可以產出有價值的菜色。

有機因素和有毒因素都可以被培養，但是，培養有機因素的道路比較長遠。

(2) 換！

有些工作，天生取代性高。例如：餐飲業的員工，只要有心學習，絕大部分的人都能成為一個好的餐飲業員工。

有些工作，很具有專業性，只是在某個特定組織內，取代性很高。例如：在大型軟體組織(例如微軟)的工程師，在數萬個工程師中，其實任一工程師並沒有絕對的必要性。

屬於這類型的狀態下，要提昇被需要的程度，最快的方式其實就是「換」。

但是在「換」之前，需要確保兩件事情：

(a) 現在的工作產出已經超乎別人的預期：也就是說，別人(同事,老闆)很確定你做的非常好了 

(b) 提昇自己的個人能力：說來簡單做起來難，尤其是在大組織中。但就現有的工作範圍往外擴張是最好的方式。

(3) 避免帕金森法則

帕金森法則：請先參考wiki的說明。

當在大企業做了3-5年之後，很有可能落入帕金森法則陷阱之中。也就是會盡量「擴大本來不需要的時間與資源用來完成工作」。這在過去的研究中有相當多的證實，並且全世界所有政府機關都有此現象。

一旦不自覺的落入帕金森法則，會下意識的降低自己的效率，產出和學習新技術的能力。自己的低效率，會成為成長的障礙。在員工能自我解決此問題之前，對大組織來說，都是「員工需要這個公司」而非「這個公司需要員工」。同樣的，對於小組織而言，公司需要員工的而非員工需要公司的機率會大得多。

---

註1：但是業務掌握客戶關係則不屬於此類，客戶關係並不是資訊，而是透過長期互動累積而來。是屬於資產的一種。
參考資料

參考資料
(1) 自我感覺良好的能力不足

中高階人才選用：成長心態鑒別的技巧

或許Carol Dweck這名字有點陌生，但是這位1946年出生的教授與她指導的學生(Lisa S. Blackwell, Kali H. Trzesniewski 這兩位才是研究作者，教授是列為共同作者) ，闡述的學習成長理論，卻經常的出現在教育界與職場上。

簡單的說，根據對美國小朋友的實驗，鼓勵「成長作為」比鼓勵「天賦能力」更能讓小朋友學習快，解決問題更有彈性，獲得更好學習效果。說的更直白一點，要多對小朋友說：「你做的很努力唷，好棒棒」「你做的方式很有創意耶，好棒棒」，千萬不要對小朋友說：「你好聰明唷，好棒棒」「你好厲害喔，好棒棒」。研究者把小朋友的內心，分成兩種心態(mindset)：成長心態growth mindet，以及，固定心態fixed mindset。說的更直白一點，這些研究認為擁有成長心態的小朋友，未來的發展無限，人生就是彩色的。由於這個研究，引發了之後的更多類似相關研究，對於教育者而言，某些過去鼓勵方式，反而可能對小孩子有錯，而後，這些研究者，成立了 Mindset Works公司，開始賣服務與各類教材。

各企業巫醫們，自然能從中獲得啟發。比較好的像是lifehack，所做的此圖也還真的有啟發性。

對於企業組織要選用中高階人才，自然會希望找到「具有成長心態」的而且「很有能力」的人。換言之，就是要找在龜兔賽跑中，早就已經跑很快，而且也謙虛向學的兔子！對於已經具有十多年工作經驗的老江湖，確蠻有可能在面試過程中，不著痕跡的隱藏自己。那麼企業要如何找到具有「成長心態」的人才，而非找到「很會面試隱惡揚善」的人才？

當然企業不可能重複一次Dr Dweck的實驗，不過確可以用情境實例面試精神，找到簡單的三個「事實」來鑒別人才。

請緊記情境實例面試的原則：了解此人過去的經驗與能力，而非此人「對未來的憧憬與幻想」。換言之，企業組織雖然是為了未來，才需要雇用人才。但是，鑒別人才確必須要依賴了解這位候選人「過去的事實」。

1. 困難問題實例：最近2,3年來，解決最艱困的工作方面問題是什麼，自己如何解決？

這個問題必須要問的簡單清晰。畢竟一個有10多年工作經驗者，必然會遇到困難問題，而既然是最艱難的問題，必然有下列幾種狀態，確實問出幾種客觀狀態，來鑒別此候選者的成長心態。

(a) 問題的艱難程度：不能太過簡單無聊的問題
(b) 此人對此問題的獨立貢獻程度：也就是是這個人「做」的，而不是他「叫別人做」。
(c) 問題解決方式的創意：這和下一題可能有關，但艱難的問題不見得要用創意的方式解決。

如果是資訊科技產業，這個問題要修改為「技術相關的艱困問題」。

2. 創意問題實例：最近5年內，對組織做出最有創意的貢獻是什麼？

此問題的基本精神在於，一個具有成長心態的人才，一定是會做出有創意的貢獻。當然也不可能每天都有創意，把時間放長為五年，應該已經很寬鬆。必然要透過這個問題，以及接下來的對話，確實問出以下客觀狀態：

(a) 這個創意，是此候選人「做」的，而不是他「叫」屬下做，或者是「建議」別人做的。
(b) 這個創意，範圍夠大，確實有所貢獻。
(c) 這個創意貢獻是否能有實質證明。

3. 失敗問題實例： 在工作上，做過最爛最失敗的事情是什麼。

雖然這是面試的老問題，但此問題必須按照事實，看出是否有「避重就輕」。特別是，許多工作十幾年的人，在職場都可以歷練出舌燦蓮花的本領。因此要檢查幾個事實狀態：

(a) 問題的嚴重性：確實有些人運氣特別好，工作十幾年都沒犯錯過。但這個機率實在太低，當一個候選人簡單的講一些根本不是失敗的例子，大概就只是避重就輕。面試時，可以簡單值說：說這些失敗其實根本不重要，能否在舉一個「嚴重犯錯失敗」的例子。另外也有可能是，其過去十幾年來工作內容太不重要，以至於沒有嚴重失敗的經驗。

(b) 失敗的歸咎責任：詢問問題時，一開始請讓候選人自行暢所欲言，許多固定心態(fixed mindset)的人，在能夠暢所欲言的時候，自然而然的會把責任轉移到非自我本身。例如：「那時候我們的QA根本沒找到問題，所以後來系統出錯的時候...」或者是「當時我們的人力不夠，所以就只能拖延...」

(c) 事後的影響：成長心態的人，對於重大失敗會有決定性的影響，因此，這個失敗事件，能否對他後來的「行為」「想法」有改變才是重點。

固定心態的人，很有可能會說「以後運氣還不錯 就沒發生同樣的事情了」或者「也就是因為如此 所以我才想離職」，更慘的是，規避了解失敗的真正原因，特別是曾經當過主管的失敗例子：「因為之前的屬下太過自由導致出問題，所以我現在就很嚴格管理所有細節」「那時候跑scrum有很多問題，所以現在都不用scrum了」。

成長心態的人，則比較傾向找到失敗的真正因素，改善真正因素：「那時候跑scrum有某某問題，所以我們現在scrum會做XX調整」。而重大失敗，更是會變成具有成長心態的人，隱含的內心記錄的一部分。

工作3年後 - 如何主動換個好工作

工作3年後 - 如何主動換個好工作

畢業開始工作2到3年後，是個轉捩點。許多專業工作者(例如工程師)都在剛畢業後2-3年就會主動考慮換工作。

要隨便換個工作不難，但是要換個「好工作」其實非常非常難。

最踏實的作法是對「換好工作」這件事情有具體的目標和可行的作法。雖然這和每個人的職業和背景的不同，而有差距，不過計畫的步驟其實差不多。

想要跳過說明，可在此取得「TS 換個好工作 計劃表」。

有很多原因，會讓工作2-3年的人想主動換工作(註1)，以下是幾個常見原因：

(一) 未來發展：覺得現在組織沒辦法讓自己升遷，增加責任範圍，學不到技術等等。

(二) 生活品質：薪水不夠，加薪幅度不夠，工作時間過長等等。

(三) 組織狀況：大組織內政治因素過大，小公司極端不穩定，產業外移等等。

(四) 興趣：現在工作內容沒有興趣，感到厭倦無聊，或者發掘自己的興趣在一個截然不同的產業等等。

(五) 想創業：這不在本文討論範圍之內。(註2)


除了以上原因之外，「最爛情況」也可能是換工作的原因。所謂最爛的情況，是指「非理性行為」：年輕人畢竟容易血氣方剛，容易產生各種憤怒：「對微妙小事看不順眼而憤怒」，「因為覺得老闆好爛而憤怒」「覺得不被重視而憤怒」，甚至，「我的老闆沒被大老闆重視」也可能是原因。

但其實，企業組織只要沒有違反法律，這些爛原因，絕大多數都是無聊而且不必要的。因此也不在討論的範圍之內(註3)

要找工作很容易，要找到好工作很難

再次強調，換工作很簡單，但是要換到好工作很難。對於困難的事情必須要有計畫的完成它。

計畫如下：

(1) 了解自我原因

了解自己為什麼想主動換工作的原因，是最基本，但是卻最容易被自我扭曲誤解的第一步。

有個簡單的方式可以讓自己對自己「誠實一點」：將自己為什麼要換工作的三個最主要原因，依優先順序寫下來。根據80/20法則，第一個原因約佔80%，第二個原因是16%，第三個原因最多是4%。舉例如下：

80%：因為學不到新技術
16%：因為加薪幅度不到10%
4%：覺得厭倦無聊

先把80%的原因遮起來，模擬假設解決了80%的原因，只剩下另外兩個原因，還很想主動換工作嗎？如果不太想換了，才表示你誠實的面對了自己。如果還很想換，就表示那80%的原因根本不是主要原因，請換個主要原因再試一次。這步驟是要迫使自己誠實面對自己，了解自己真正想換工作的原因。當然，想要換工作的原因可能更複雜，但一定要先認知問題的存在。

因為「解決問題的第一步是認知問題的存在」。而如果不先了解自己真正想換工作的原因，那就很難了解自己認為「好工作」的定義。

當然在這個時候，很有可能會覺得不想換工作，或者想創業為自己工作，那也很好，重點在於找到自己心裡真正的原因。

(2) 足夠計劃實施時間

在台灣，知識類型的工作者，最好要有3到5個月的準備時間。以下的計畫就是以3個月的準備時間為準。

3個月看起來是個冗長的時間，但如果你只有2-3年工作經驗，只準備了3個月就換到適合自己的好工作，其實是極端快速的。要達到極端快速，需要妥善計劃。

如同精實創業和敏捷開發的「時間控制」原則，這3-5個月時間是固定的，如果期限內沒達到效果，應該重新檢討，重頭開始。

(3) 定義目標

當準備換工作，目標必須是要換個好工作。而定義「好工作」就顯得很重要。每個人的好工作定義都不同，但該目標必須要「解決當初最重要的換工作原因」。

目標的需求描述，可以是4至8個項目。描述的內容要和換工作的三大原因有所關連，但不見得要一比一對應。也可以加入額外條件，像是地點之類。最後，描述的目標一定要有幾個「參考公司名稱」，因為畢竟換工作，最終還是換到某個公司，目標公司並非表示你非他不可，而是有個顯著的參考值。

例如：

 * 要學到比較完整的軟體開發流程
 * 透過轉職加薪，要比現在多15%
 * 工作內容聽起來要有趣
 * 工作地點在大台北地區
 * 加班頻率不高
 * 有國外出差的機會
 * 目標公司：四零四科技，趨勢科技，LINE台灣

(4) 瞭解與目標的距離

了解與目標的差距，最簡單的做法就是「馬上去面試一次看看」。但這樣做是有點風險，因為許多外商，通常在拒絕應徵者之後，可能3-6個月都不太會讓這個應徵者再來面試一次。

其次，花半天的時間，上網搜尋相關資料，特別是在104, linkedin上的公開資訊。可以看出這些公司最近需要的人才的技術能力為何。通常比較大公司很容易找得到「面試經驗談」可作為參考：要記得只是參考而已。

另外，也可以透過linkedin找到該公司的HR或者主管，虛心請教哪些技術能力及程度，是必備條件。有兩點要稍微注意的是：(I) 目標應該放在知識與技術能力，暫時先不要考慮「軟技能」像是人際關係之類的。(II) 英語能力是屬於技術能力的一種，並非軟技能

列出此時此刻，自己和目標最大的3-5項差距：

 * 對比較嚴謹的開發流程沒經驗
 * 對Linux不熟悉
 * 英文溝通能力不太好
 * 線上程式測驗比較難 
 * 沒有大數據相關工作經驗


注意！如果在這個階段，你認為沒有差距了，就勇敢地去面試。一旦被綠取，那麼你也已經達到計畫的目的。然而，要是沒被錄取，就表示「實際上」的確有差距，必須要回憶面試過程，找到其中差距，然後用下一段(5)行動，來補足差距。

Action speaks louder than words

(5) 行動

計畫最重要的部分就是行動，沒有行動的計畫是死的。不過，好計畫也是行動的關鍵。不知道怎麼行動比較好？可在此免費取得通用版本的「TS 換個好工作 計劃表」作為參考。

換個好工作的主要行動有五項：

(A) 急速提升目前工作績效

快速且大幅提升目前工作的產出效率和在組織內評價，是縮短與好工作距離的「最佳做法」。絕大部分的用人主管與人資主管，判斷應徵者的未來潛力，是透過他「過去工作績效」。

換言之，要換個好工作，關鍵成功因素是把現在的工作做到最好！而且是「以別人的角度」認為你做得最好，而非從自己的角度。

實際做法是：

首先，列出三項在1-2個月內可以達到的「額外」工作目標。並確定達到之後，現在的主管「鐵定」會非常滿意。可以主動和現在主管確認，這些額外的目標確實有很大意義。當然在這個時刻，不需要跟他說你有換工作的打算。

接下來，用盡「所有能力」，去達成這些目標。所有能力包含以下各種可能：

 * 厚著臉皮請教同事應該怎麼做比較快
 * 快速學習新技能以達成目標 (參考下一段)
 * 在做的過程中虛心向老闆求教
 * 每天提早40分鐘抵達辦公室做這三項額外目標
 * 用80/20法則，找到目標的關鍵任務先行完成

絕大部分的人，無論是什麼樣的工作，都能透過這個方式，在1-2個月內，展示出「大幅提升績效」的結果。並且是會獲得「外界肯定」，而非自我感覺良好，自覺大幅提升。

(B) 急速學習技能 

在瞭解與目標差距中，已經列出數個技術差距，而每個技術差距，都應該可以用學習技能來補足。

快速學習的本身，也有一定技術可依循，請參考這篇：快速學習解決職場困境。

每個技術差距該做的事情都不一樣。不管列出幾項差距，最好是「一項一項」逐一解決，盡可能不要同時解決。考慮現實，3-5個月最多也只能增加3個技能。而每個要解決的技能，必須有極為明確的目標。這也是極速學習的關鍵：清楚定義目標，在大目標下逐一達成每個小目標。例如：

 * 對Linux不熟悉：熟悉LPI-201, LPI-202，通過線上測驗。
 * 英文溝通能力不太好：考TOEIC目標成績850
 * 線上程式測驗比較難：每天花10分鐘，到Leetcode或topcoder上找中難度的題目練習

(C) 急速打造通路

通路(Channel)是在商務上，將產品送至客戶面前的方式。

對於知識工作者來說，「你自己」就是產品。而企業組織，就是客戶，企業組織雇用員工也是一個「市場」，而市場，常常是被通路所控制。既然你是產品，就應該要妥善處理你的通路，而非讓客戶來決定通路。

最基本的通路，可能也是最差的，是所謂求職網站104, 1111之類，當然，有3年工作經驗，也可以用求職網站。但它恐怕不是最好的方式。

另一種通路是linkedin，和求職網站稍有不同，linkedin需要更大的主動性去維護 履歷表。

再者是獵人頭公司(headhunter)，大部分的情況下，獵人頭公司對3年工作經驗者不會有興趣，當你只有三年工作經驗，獵人頭可能只會對你的聯絡方式有興趣，等你「長大一點」再跟你聯繫還不遲。然而，有些做法可以讓獵人頭提早對你有興趣。其中一個做法就是透過業界導師推薦。

最佳的通路是「內部推薦」。如果剛好有認識的同學朋友在該公司內部，那你的運氣就實在太好。但是如果沒有任何認識的人？創造認識的人就是最好的方式。

如何創造認識的人？透過linkedin或者其他社群網站了解內部員工都參加哪些活動，或者研討會。主動參加那些活動和研討會，就會自動認識內部的人。稍微熟悉一點之後，就可以厚著臉皮懇求幫忙送履歷表。幫忙送履歷通常不是問題，問題在於「是否真心推薦」才是重點。技術類型的工作，參與相關的研討會，參與比賽，參與開源開發專案等等，絕對是能獲得真心推薦的方式。

(D) 應徵/面試

當準備到一個程度的時候，就應該去應徵面試。何謂「到一個程度」，只要你按照原定計畫，2-3的月就一定會到某個程度。你就應該「驗收」努力的成果，而非覺得「不夠完美」所以想持續學習。

不夠完美是一定的，因為人不可能完美。持續學習也是一定的，因為學無止盡，但時間是會流失的，這也是為什麼一開始需要鎖定一段時間，無論好與壞，每一段時間一定要能驗收檢討成果。

應徵和面試的技巧，網路上各企業巫醫專家實在太多，就在此省略。

(E) 檢查是否朝向目標

要給自己固定一小段時間，檢查自己所作所為是否朝著計畫前進。最好是定在每週一上午9:00~9:15 (這時間有特殊意義存在，盡量不要改變它) 

要檢查三件事情：

 * 過去一週的行動，有沒有確實提升工作績效
 * 過去一週的行動，有沒有縮短與目標距離
 * 有沒有浪費時間在其他地方

(6) 最終結果與選擇

如果在時間內，確實被錄取「目標好工作」。那麼就應該作出選擇，決定要不要去。因為也許3個月後，由於你的工作績效大幅提升，原本一定要換工作的原因已經不存在，當然就可以選擇要不要換。

如果在時間內，並沒有被錄取「目標好工作」。那麼就應該從第一步開始，檢討哪邊出了問題。並且重新再做一次3個月計畫，然後，確實再實施計畫。即便第一次計畫失敗，也會讓下一次計劃成功。

＊＊＊＊＊＊＊

每個人都有適合自己的方式。但如果你沒有好方式來換個更好的工作，參考並實行這個計畫一定能獲得好結果。


＊＊＊＊＊＊＊

---

註1：也有一些種情況是被動或者被迫換工作。 最糟糕的情況是因為績效不佳而遭到資遣，其他情況像是：公司倒閉，公司裁員，組織重整，健康因素，家庭因素等等。被動換工作的通常是「措手不及」的，因此要採取略微不同的方式。請參考這裡。

註2：工作了2-3年，應該可以知道，創業和換工作截然不同。創業的成功關鍵請參考這裡。

註3：不過，人類有各種認知偏誤，合理化既定決定，無論決定合不合理，都有可能被自己合理化。

不玩一樣的遊戲 - 準備面試的真正技術

程式設計師如何在面試中展現真正價值：最好的方式當然是不要跟其他人玩一樣的遊戲，也就是在面試中，找出幾個能突顯自己技術能力的要點。針對這些要點，做延伸性的準備。

不管什麼原因，當一個軟體工程師下定決心要換工作時(註1 )，面試通常是免不了的。

作為軟體工程師，鐵定會上網搜尋各種「面試技巧」文章。

例如：常見面試問題的最佳回答：這篇或者這篇。也有些人會說，面試除了回答問題，更重要的還是會問對問題，例如這篇。

但是，人資與主管，通常比面試者更知道這些所謂「標準問題」。也很清楚面試者可能會去找的「標準答案」。這些面試技巧文章只是一再重複大家都知道的常識，多複習這些常識是有很大的好處，至少可以避免緊張或者不必要的誤解。

但常識不會是關鍵。


在面試的時候，除了回答標準問題之外，最重要的是「確實展示自己的價值」才是關鍵。

軟體工程師/程式設計師的價值展現，其實第一時間點是在「看履歷表」的時候。短暫的面試時間是在「檢查履歷的正確性」。假設面試者的履歷寫的中規中矩，沒有什麼誇大，也沒有過度謙虛(註2)，會讓你進入面試階段，就表示在履歷表上展示的技術能力是公司願意接受的。

面試展示自己的價值，通常是在幾個關鍵點。而這些關鍵點，都是「面試之前」可以先做好準備的。

(1) 應答技術問題
(2) 解釋過去做的事跡
(3) 詢問技術相關的問題

(1)  應答技術問題

大部份的軟體工程師工作，通常都會有程式考試題目。只要你在Leetcode, topcoder之類的網站，用你本來就熟悉的程式語言，多練習幾次，應該就不會太離譜。事實上，技術問題不可能考得過於艱澀 - 因為公司組織通常沒這麼多閒功夫在一個面試者身上。

其他的技術問題應該要根據你在履歷表上的專長做「延伸性」的準備。延伸性準備，才是展現價值的最好方式。

例如，倘若履歷表上你的專長是WebUI，那麼你就得延伸準備到HTTP：至少了解一些重要的header。如果你的專長上有寫Linux，那麼就必須準備回答曾經使用linux做過什麼事情？

如果曾經在linux上架設web server (nginx, apache...)，至少也得知道設定檔在哪裡，如何開始停止服務，如何列出執行的行程(process)，如何在不得已的時候強迫結束服務。當然，如果你會回答kill -9，最好確實知道為什麼是-9。

應答技術問題的不僅只是「防禦性」告訴面試者你的能力。而透過簡要地回答，「順便」展示自己對技術能力掌握的額外價值。就以上述kill -9為例，以筆者過去15年，面試超過400個人經驗，在履歷表上寫「熟linux」的起碼也有150人。這些面試者，八成都知道kill指令。然而，僅有不到10個人，知道為什麼要用kill -9，並能說明kill預設single 15是比較好的選擇。

在回答簡要技術問題，只要能有正確延伸性的回答，就能展現與他人不同的價值。而這絕對事是先可以準備的。

(2) 解釋過去做的事蹟

只要有2-3年工作經驗，面試時，一定會被詢問過去做了什麼。

因為，要了解未來一個人在組織的貢獻，最好的方式是看他「過去貢獻了什麼」。以下是一些解釋過去事蹟的要點。

＊＊ 妥善呈現事實而非感受。

當你已經離職時，過去的事蹟就已經成為「歷史」，而你可以準備的是「妥善呈現歷史的事實」，切勿扭曲或用「感受」呈現。

例如：「在那個專案裡面，幾乎事情都是我在做」。這其實是你的個人感受而非事實。事實必須要用無可扭曲的方式呈現。

又例如：「這個專案扣除html/css之外，前端javascript在git上大約有3萬行左右，其中兩萬五千行是我commit而且到專案結束也都是我負責維護」。這只是說明在程式碼上的「事實」，你並沒有貶低別人的貢獻，因為也許那其他5千行極端重要也說不定，但你也呈現了以code base而言，你的貢獻在事實上絕對不低。

＊＊過去事蹟，絕對可以，而且也絕對需要在面試前妥善準備。

因為，你對過去自己真實貢獻越了解，就越能掌握過去事實。越能掌握過去的事實，就越能表示自己在技術上更有未來潛力。

例如，假設你是IT部門員工，過去都是協助內部系統上線，這些系統其實也是外包商提供。在面試時，被詢問做的內容，如果只是簡短回答「將公司委外開發的系統上線」當然也是可以。

但如果你在事實上，也會做「自動化檢測系統」「建構上線風險評估」「上線後的使用分析」「成本分析」以及「有沒有達到預期目的評估」，這些才是IT真正產生價值，並且與眾不同的地方。

最好的情況會是，公司之前並沒有此做法，而是你主動完成這些有價值的事，讓公司變得更好。可是，如果你已經離職，來不及產生事實 (當然也不可能去捏造說謊)。那麼，至少還是可以說「當時其實應做自動化檢測系統」，雖然那時候沒有完成，但你也可以在面試前自己做一個小規模的自動化檢測系統，而在面試的時候就可以大大方方的說，當時雖然沒做，但是自己覺得應該要做，所以主動在事後做了。

當然這表示你需要在面試前付出時間準備。這樣的付出不會是沒有代價的。即便這次面試沒用到，你所做的事情是不會消失不見，只要是你做的「技術上正確」的事情，未來一定會對你的職業生涯有所助益。

(3) 詢問確實的問題

通常面試的最後，都會給面試者問問題的機會。

許多文章中，的確會說明問問題的重要，例如這篇。有上網查過的面試者，也了解不該問一些瑣碎小事，上下班時間，或者公司基本福利，因為這些問題只是等於打發時間。雖然沒有害處，但是也沒有價值。

軟體工程師最適合的就是詢問有價值的技術相關問題(註3) 。而這些問題也可以讓你稍微判斷此公司的狀況。

基本問題

一些很基本的問題，可以簡單展示你對軟體專案成熟度，也可以讓你了解這個公司的狀況：

* 請問目前是用什麼樣的版本控制系統，管理程式碼？

    該組織用什麼樣的版本控制系統不重要，無論是git, svn, cvs, p4...都可以。重點在於，的確還有些組織連版本控制系統都沒有。

* 請問目前組織是使用哪種專案管理方式？

    最近幾年是流行Agile/Scrum，

* 假如我有幸錄取，前三個月你希望我能完成哪些事情？

    這個問題代表自己的積極程度。主官如果對這個問題講得過於籠統抽象，很有可能該面試官(主管)並非實際的技術管理者。

* 團隊最近一次做code review是什麼時候？
* 團隊的bug追蹤流程目前大概是怎麼做的？
* 目前自動化測試的涵蓋率大約是多少？

    這些問題是展現自己對軟體開發的成熟度。特別注意的是，如果這些問題被籠統的回答，也不需要追根究底找別人麻煩。


進階問題

可能會引發進一步討論，也可能被反問，所以要事先準備被反問時的技術回答。

例如：

* 就現在的資料和面試的情況，您個人覺得會錄取我嗎？

* 最近一次在團隊裡面遇到最大的技術困難是什麼？

* 組織如何判斷成員的技術產出？

高級問題，

很有可能被認為是反過來刁難面試主管的問題。必須斟酌採用。例如： 

* 目前軟體專案程式碼的entropy有多高？

* 目前自動化建構和測試是採用哪些工具，涵蓋率有多高？

* 就您個人而言，最近在組織內學到新的技術是什麼樣的技術？新的程式語言或者新的工具？

面試是可以事先作準備地，軟體工程師的面試準備，應該花時間以事實展現價值作為準備方向，而非準備一些大家都知道的常識或者花時間準備外在行頭口語表達...等等。當成功地完成許多面試，就可以在工作機會上有所「選擇」。

---

參考文章：
(1) Scrum認證！不要再浪費你的時間了
(2) 如何充實自己
(3) 畢業前六個月 建構職業生涯
(4) 年底才績效評估或考慮轉職 已經太遲了
(5) 因為沒挑戰想轉換跑道，先檢討自己吧

---

註1：要轉職換工作區分成「主動」與「不得已」兩種。不得已：例如公司倒閉之類，當然就不用討論。但是如果是「主動」，就要先想清楚「真正的原因」。因為這個原因，可能不會因為你換工作而消失。

註2：剛畢業的學生可能是怕履歷表太空洞，通常都有誇大的傾向。而在業界打滾數十年的老鳥，有時候會有過度謙虛的可能。

註3：當然不應該「窺探機密」，因此可以在一開始的時候先說「如果這個問題不小心牽涉到公司機密，請告訴我，在這個時間點我無意探究貴公司的機密」

數據分析 - 獵人頭如何從Github尋找人才？

前陣子遇到某特殊的獵人頭hunter公司(參考:這裡)，竟然是透過分析統計在github, gitbucket的程式庫，來找到軟體人才。

目前，github使用者數量仍屬商業機密，但估計約在2千萬左右(參考:這裡)。當然，使用者大部分從事軟體相關的行業。

資訊科技，特別是軟體的實際成果，容易在網路上展示。因此，如果要找到「軟體開發人才」，github是一個很好切入的地方。一般獵人頭可能會人工搜尋，但身為工程師，當然是寫程式找到大量資料。

從github找人，這做法有一些顯而意見的好處：

1. 有可能看到此人實際上寫的程式碼
2. 有可能了解最近此人的工作範圍
3. 很快找到此人的聯絡方式(email)部落格或其他技術相關資訊
4. 有可能找到此人合作對象
5. 有可能看出此人的英文語言能力

當然也有些顯而易見的缺點：

1. 當然找不到那些不在把專案程式擺道github的人
2. 此人可能只是擺放玩樂性質的程式
3. 只能有機會看得出技術能力，非技術能力仍然需要其他佐證
4. 資料範圍過大，很難逐一肉眼看完

雖然我不是獵人頭，但基於工程師的精神，就嘗試一下解決「資料範圍過大，很難逐一肉眼看完」的問題。看是否能透過程式取得並處理gitbub資料，找到潛在挖角對象清單。

實際上做的步驟如下：

1. 了解gitbub資料如何取得：

github提供api可供程式使用。和許多Web Service一樣，也有完整的文件，請參考這裡。

2. 以程式取得少量測試資料

github的web api測試起來很簡單。舉例來說，如果你已經登入github，用以下這個URL request就可以找到，以javascript與nodejs為關鍵字的所有程式庫：

https://api.github.com/search/repositories?q=topic:javascript+topic:nodejs

當然，他的回應是json格式，需要簡單地用程式轉換。例如下圖，乃是搜尋和javascript相關，並且其位置在台灣的使用者：

測試資料回傳乃是json，調整格式成為csv，以便於日後在excel做簡單分析。

3. 了解測試資料內容

如果已經有在使用github，那麼對於回傳的資料應該很清楚其內容意義。

如果不太了解github，就需要找對軟體版本控制系統有些認識的人幫助瞭解其含意。

這上述的範例：「搜尋和javascript相關，並且其位置在台灣的使用者」來說，程式會刻意收集following(有多少人在跟隨這個人的更新)，follower(這個人跟隨了多少其他人)。此外，程式會額外計算push和javascript相關的程式庫的次數，取名為work，表示和javascript的相關工作在過去一段時間的次數。

4. 撰寫簡單統計程式，大量取得資料

當然，這個程式就放在github上。請參考這裡。

程式本身是python撰寫，需要有github帳號密碼才能使用。

5. 結果

以上述範例：「搜尋和javascript相關，並且其位置在台灣的使用者」大量取得資料並且「過濾可取得公開email」的人數一共是661筆。並且取最前面的199筆，給熟識的headhunter (獵人頭) 鑑定看看是否有效果。

目前的回應都是此資料非常有用。