節省招募時間 - 電話面試的技巧 (成為主管的31堂課)

在軟體「人才」的招募上，通常會花上比預期還要多時間，人才難尋是軟體產業其中最困難的問題。自招募流程上，各種審慎的過程當然不能省略，例如技術評估，面談等等。然而，整個過程可以透過各種方式，提前篩選適任或者不適任的人。其中，電話面試在台灣是最被忽視的一項。大概也是因為台灣交通十分方便，特別是大台北地區，面試者一般都不會因為「太遠」而放棄，但交通因素並不是電話面試最大的好處，電話面試最大的好處是可以低成本有效地去除偏誤，有效增加後續篩檢的正確率，並節省時間。

---

案例：在某次研討會中，軟體研發團隊主管K說，我從來不做電話面試，因為我想要看到應徵者的臉孔跟肢體反應，這樣我比較容易判斷個性。

---

電話面試有幾個好處：
(1) 去除偏誤：尤其是對外表的偏誤。已經有太多研究證實，沒有人能夠避免對外表的偏見，只是多或者少而已。也因此許多研究指出，履歷表不放照片才是最好的方法。當然也有人持反對意見，不過整體來說，雖然遲早會見到本人，但電話面試的確可以去除主管對外表的偏誤。案例中的主管K試圖去判斷個性，但容易流於自我偏誤。

(2) 節省彼此時間：一般面談起碼也要花2個小時，而電話面試至少可以先過濾掉10~15%的明顯不適合的應徵者。許多資深的軟體職位起碼要收20個履歷表才能找到1個人。換言之，電話面試，在表面上起碼可以少讓2個人來辦公室，但其實背後意義不僅於此，操作得當可以讓另外18個人對你的組織更有興趣更能在面試中努力表現，而非因為獵人頭介紹隨便來試看看。

(3) 其他：其實還有很多好處，例如再度驗證履歷表的真實性等等。

電話面試的技巧：

一：結構性問答而非開放性討論

電話面試必須要「固定詢問有意義的結構性問題」，而不是開放性討論。透過結構性問題收集了解事實。

結構性問題例如：
* 你為何想要離開現在的公司
* 是從什麼管道知道我們有在找軟體開發人才
* 你最近一次跟主管起衝突的時候，當時你做了什麼
* 最近三個月，你學了什麼新的資訊技術是跟工作無關的
* 你最近一次code review是什麼時候

這些問題回答不要評論好壞，只是記錄最為後續判斷。

不要問開放性的問題，除非你要找的是很會唬爛的人，開放性的問題通常都是假設性的問題，例如：

* 如果你跟老闆吵架了你會怎麼做
* 要是你加入一個有大流量的公司，你要怎麼做分散式系統設計

二：基本的事實查核

事實查核比想像中重要，倒不是因為履歷表造假的問題，而是在看履歷表的時候可能會有自已的假設，這些假設可能會有認知偏誤。

簡單的事實查核問題
* 請問你想要離開現在公司的原因
* 請問你當初加入這個公司的原因
* 在2013/3~2014/10年這段期間，你履歷表中似乎沒有在任何地方就業，請問是什麼原因呢
* 您在2012年某公司A的離職原因是什麼

進階的事實查核
* 在履歷表中，您有描述溝通是你的強項，請舉一個最近一次你解決非常困難溝通狀況的例子好嗎？
* 您剛才說在某公司A的離職原因是公司內部高層政治鬥爭很嚴重，可以舉一個政治鬥爭的然後影響到你的工作的實例嗎？

三：回答面試者對公司以及團隊所有問題

優秀的人才鐵定會想要再加入一個團隊時，了解一些事情。讓面試者詢問問題，不對問題做衍生性的回答，也不做假設，只是誠懇地回答問題。並且在最後再詢問「請問你還有任何想要了解的問題嗎？任何問題都可以現在詢問」

當面試者問了廣泛性的問題，請必定要他縮小範圍。否則，廣泛地回答對他也沒有好處。舉例來說：常遇到面試者問「呃 ...我很重視軟體工程文化，請問一下貴公司的文化是怎樣」這種問題太過空洞，可以直接告訴面試者「我們也很重視工程文化，但你的問題太過籠統廣泛，這樣我也會回答的籠統廣泛對你也不好，可否你縮小問題範圍，或者問實際的某件事情，透過實際上事情你就可以判對我們的文化對你來說好還是不好」。如果是容易溝通優秀的人才，很快能了解，因而他們就會問類似這樣的問題：「喔 我了解，那我想問，請問你會進行code review嗎」這樣彼此就可以針對事實討論。

更重要是這樣的事實討論，可以讓他了解優秀主管通常是實事求是，而主管也可以了解他能不能馬上抓到重點。



藉由這三個項目，一個好的主管可以初步篩檢適合或者不適合的人。另外一個值得一提的是：電話面試中間盡可能不要提早判斷面試者適不適合，盡可能是電話之後才根據筆記來判斷是否要邀請來面試。

參考資料：HR一定要會的：如何肉搜一個人的基本資料

人手不足？資源永遠都是不夠的 (成為主管的31堂課)

大部分的情況下，所有研發與軟體主管都會面臨到人手不足的情況，特別是新創企業和快速發展的公司。資源有限，人手不足是必然的「現實」，能夠有效解決此問題也是普通主管和好主管最大的差異之一。解決的方向有三個：(一) 事實是事太多而非人太少。(二) 突破性思考，至少想出解決方案。(三) 必要的犧牲 

---

案例：主管V負責一個長期專案，已經有接近30個工程師是直接由V管理。然而，最近一段期間由於主要客戶的變更，加上CEO的臨時任務，讓這部門的員工疲於奔命。主管V也沒有什麼對策，只好和業務盡量模糊客戶需求以及驗收方式，看能不能減少工程師的工作量。

---

一：真正的事實是：事太多而非人太少

人手不足的真正意涵是「事情太多」。在以人才導向為主的組織裡，人力不足採取的短期策略如果是「增加人力」通常也不會真正解決問題。但如果短期採取「調配人力」也就是說某些事情先不做，有些事情先做，的確是可行的做法。

作為主管的你可能會說：我這些事情都很重要，每一件事情都要做。在營利組織裡，所有事情都很重要根本不可能發生。絕大部分的情況是：主管無法針對事情的優先順序做必要的排序。除非你管理的組織是急診室或者核電廠，不然不可能什麼事都很重要。要做必要的排序表面上很簡單，將事情列一個「優先順序的清單」，從1排到N，數字都不能重複，1就是最重要的事情。實務上，需要主管本身的本職學能判斷以及個人意志力。

二：突破性思考，至少想出幾個不同的解決方案

關於思考問題的框架，請參考這裡和這裡。在此就不重複。

但要提醒的事，在盈利企業裡面，不可能有什麼事情是「只能」這麼做的，一定會有不同的解決方式。問題只在於有沒有想到，還有這樣做效果好不好而已。

三：必要的犧牲 

必要的犧牲並不是指長期加班。長期加班最後通常也是三輸。必要的犧牲指的是幾種可能：
(1) 犧牲不必要的事情，請參見第一段
(2) 極短暫的加班，和長期加班不同，短暫加班是為了解決特定問題，並且要確定能盡快補假，讓團隊成員合理的休息
(3) 縮小範圍，犧牲部分功能
(4) 延長時程，犧牲時間 

然而請謹記，不能犧牲組織重要的長期目標的前進，以及不能犧牲組織文化價值。主管一旦犧牲不該犧牲的事務 （即便是無意間），就表示其領導方式有極大的問題。

陷阱

案例中的主管採取的作法非常糟。會直接踩到許多陷阱。要注意的陷阱是：
(1) 任何情況下降低品質都是飲鴆止渴，很少看到好下場。然而縮小功能範圍(例如MVP的概念)卻常常能夠成功
(2) 滿足政治因素(要和CEO打好關係)而非滿足實際困難，短期雖然可能有效果，但長期通常也不會有好下場
(3) 任何變化仍然要滿足組織整體方向，以此案例來說，必須要了解CEO這些臨時任務和目前專案比較起來何者重要

加入新創後 如何建立團隊 (成為主管的31堂課)

當你有機會加入一個新創公司，並負責建立某個軟體開發團隊，無論是哪種類型的團隊：QA，手機研發，維運，前後端... 你會面臨比想像中還要困難，但其實更有趣的挑戰。要達成這個任務，首要(一)先了解現況，其次(二) 對現況做短中期規劃，並且(三)依照情況定時調整方向。要注意的陷阱是：(a) 建立團隊不是憑感覺或過去經驗，而是憑計畫與努力 (b) 計畫和努力的投入是必然的，無論是2個人的小團隊或者39個人的組織 (c) 在不必要的壓力下更換人才選用策略

---

案例：

S是有10年工作經驗的QA，有1.5年的QA manager經驗和3年的QA lead經驗，曾經在兩個小型新創公司工作。因朋友介紹加入一個香港商新創公司，負責在台灣建立專門針對手機應用程式的QA團隊，這個團隊已經有2個不同經驗的QA。

---

一：了解現況

S應該要做的第一件事情是了解現況。
在還沒加入團隊之前，應該盡其可能列出各種大小不同的現況事實，並且針對事實在「還沒加入」之前釐清未知的現況。如果你無法在這階段列出20個關鍵問題，很有可能表示你對建立團隊的本質不夠瞭解。當然並不代表一定會失敗，只是代表成功與失敗本身有極大可能是靠運氣。

典型一定要知道的事實：

1. 這個職位是新開設，或者因前任離職而在找尋找替代者？
2. QA團隊預計在3-6個月內的團隊大小為何？
3. 其他團隊規模多大，公司規模目前多大
4. 直接主管的管理方式如何？
5. 直接主管本人最近3個月的加班情況
6. QA主管在未來3個月要達到的目標，未來6個月要達到的目標

常被遺漏的事實：

1. 權限：在招募QA上，能擁有多少權限？能決定薪資嗎？薪資上限為何？
2. 獲利容忍時間：新創團隊一般都有資源壓力，在未來6個月，如果沒有損益兩平，投資人仍然會持續投資？
3. 現有兩位QA團隊成員無法升任QA主管的原因為何
4. 公司對技術人員的選用是否有成本考量 ：如果現存軟體開發人員與QA人員大部分都是5年以下工作經驗，絕大多數情況是有很嚴峻的成本考量。
5. 公司對技術人才的選用以「先趕快進來，有人再說」，還是「選到適合的人才比較重要，願意等」。要謹記的是，這兩者在新創公司是無法並存。
6. 技術團隊過去6個月的離職率，過去12個月的離職率

類似上述的事實起碼可以在列出另外10個。而在面試階段，如果公司無法全部清晰正面的回答所有問題，並不代表這公司不好，只是代表變數和意外很多，在你的計畫中，需要控制與應變這些變數。然而，如果這些問題，有50%以上或者更多事實是模糊回答，那麼非常有可能新創公司的管理階層也都是沒啥經驗的人，加入這樣的團隊不見得讓你的管理經驗和知識能夠持續成長。

要記得，在這個階段是考慮事實回答，而不是事實的好與壞。舉例來說，如果有事實回答是：「未來6個月損益沒有兩平，投資人就失去耐心公司會倒閉」。那並不代表這不是好公司，而是代表6個月損益兩平是目標，所以這其實是好回答。但如果你獲得的答案是「只要我們大家都會努力做好自己的事情，未來六個月就一定會賺大錢」這是危險的模糊回答。

針對還不知道的事實，最好建立「無知清單」，也就是Known Unknows 而在加入的前期自然會對這些無知項目有心理準備。

(二) 對現況做短中期規劃

如果已經了解事實現況，就應該進行短中期規劃(0-3個月，以及3~6個月)。

短期規劃必須清楚具體。主要目的是確保與組織方向一致。並且列出還不清楚的事實，確保在到職的前三個月可以弄清楚。

舉例而言，該QA Manager的短期前4週計畫如下：

第1週：透過確定下列問題來瞭解公司環境：(1)確定未來三個月可招募的QA人數和經費，(2)(2)確定自己是否能確定薪資 (3) 確定能否招募比自己薪水高的QA (4)可否透過獵人頭 (5)是否有招募經費。透過與現有成員一對一面談了解目前個別成員最大的問題。透過和自己的老闆一對一面談確保期望一致。

第2-3週：建立面試流程。透過與開發人員面談，了解現在QA與RD的合作方式。了解目前品質管理相關系統(例如JIRA, testrail)。固定與主管至少每週一次面談。不管現存的測試方式好與壞，都先確定自己可以執行現有的測試案例。

第4週：透過直接與主管的檢討會議，確定自己的成效和主管期待一致。預測可招募到的新人到職時間。

計畫的本身最好不是用像上述的文字描述，使用mindmap展開概要是最好的方式。

(三)依照情況定時調整方向

加入之後，每週應該檢討計劃是否能被執行。

檢討是為了自己的計畫，可以自己檢討自己就好。檢討的方向有兩種。計劃不如預期，以及發生或者知道額外事實需要修正計畫。

(1) 計劃不如預期

例如，預期在第3周能夠執行現存的測試案例，但是到了第3周仍然無法達到。自己一定知道原因，就要針對原因來處理。是因為自己對產品不了解，抑或這些測試本身就過於複雜？

(2) 發生額外事實，需要修正計畫

這其實是最常發生的情況，也是最能考驗到創新公司的新主管的情況。如果在到職之前能羅列的問題越多，發生不受控制的「額外事實」就越低。因為你既然事先知道了，就能有所防範與準備。

舉例而言，事先如果知道你無法決定新招募的QA的薪水，則招募流程就必然要讓「能決定薪水的人」參與。換言之，作為招募你的意見主要是決定NO，而非決定YES。既然事先已經知道了，就容易建構適合的流程。然而如果事先並不知道，而且也不再你的無知清單中，一旦發現你無法決定薪水，除了心理會略有不爽之外，你能夠調整適應的時間也大幅縮短。

因此，這階段是要處理不預期的未知(Unknow unknows)。一旦不預期的未知發生，必須要先分類嚴重程度，然後確實處理「嚴重的」，不應該是處理「容易的」。舉例來說，如果不預期公司其實是要快速有便宜的QA人力，大量手動測試就好，如果你覺得這不是正確的方式，就應該優先處理此事。

避免陷阱？

有興趣知道如何避免以下陷阱？還請留言或email (support@talent-service.com)： 

(a) 建立團隊不是憑感覺或過去經驗，而是憑計畫與努力 
(b) 計畫和努力的投入是必然的，無論是2個人的小團隊或者39個人的組織 
(c)在不必要的壓力下更換人才選用策略(例如CEO說要不要早點有人進來)

自我感覺良好的能力不足: 預防與解決之道

在軟體開發團隊的招募中，技術能力當然是不可或缺的一環。候選者如何自己評斷技術能力，也許和如何評估候選者的技術能力一樣重要！

換言之，謙虛的人比自我感覺良好的人，可能實質上的能力更好。這在「達克效應」中說明得十分清楚。

達克效應簡單的說：是指能力不足的人通常會高估自己的能力 無法正確判斷自己能力的不足。不過經過提高能力之後，是可以認知到過去能力不足的事實。
這個理論雖然廣為人知，但真正去證實的人很少，因為大家總是覺得很合理，

該論文研究分為四例，無論是哪個例子，結果都類似下圖(註1)

本圖取自論文：Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments

該圖是取自研究案例二，研究者讓所有受測者考一個邏輯考試，這邏輯考試取自於美國的法律學校入學考(LSAT)，主要看一個人的邏輯思考是否完整，有興趣可以參看這個網站。

當然考試不是重點，考完試之後，將結果分成四組人，最差的就是bottom，最好的是Top。所以在上圖中，很明顯bottom組的結果當然是在最下方。但有趣的是在於，最爛的一組，在預測自己的成績與能力，卻是和實際上差距很大！次佳組(3rd)其實實際成績和自我預測最接近。而成績最好的那組，反而感覺非常「謙虛」！？是唯一反而預測自己考得不好，同時也自覺的不好的一組。但實際上考的成績卻是最好的。

研究有四個案例，考試的範圍跟內容各有不同但結果很一致。

這篇論文，雖然很直觀，但寫得有點幽默，所以竟然還得了搞笑諾貝爾獎，細想其實很有啟發性。尤其在組織中，員工的自我感覺良好是績效評估產生問題的最大因素之一，那麼在組織中有什麼樣的解決方式呢？

預防的方式：招募時的預防

尤其是軟體開發團隊，招募一個謙虛的人，比招募一個很有自信的人更容易找到真正有能力的人。倒不是說有自信是不對的，但自信心往往容易落入低能力的範圍（請參見上圖)。

要判斷自信與能力最簡單的方式有兩種：一者，就是根據過去實際的產出內容來衡量，例如詢問他過去工作中，實際上做了什麼事情，導致於貢獻的產生，而不是只問了貢獻的結果。其二，設定簡單的測試環境，例如直接在白板上討論演算法問題。

解決的方式：衡量產出而非能力

絕大部分的企業組織都知道，衡量員工的績效乃是基於產出，並非能力。當然，能力好的人自然有機會有更高的產出。

在軟體開發團隊中，衡量產出極其困難。每個團隊幾乎都因人而異。有幾個方式倒是可以適用於大部分的狀況 
(1) 員工自評，並且加上3位以上的同僚互評。
(2) code review
(3) quality

由於最近比較忙，關於產出的衡量有機會再寫。:)



------
註一:本圖擷取自該論文本身：https://pdfs.semanticscholar.org/e320/9ca64cbed9a441e55568797cbd3683cf7f8c.pdf

如何在工作中成長

過去招募時，常聽到軟體工程師的離職原因，是因為在公司已經沒發展空間，無法成長。在某些情況下的確有可能，但更多情況下是工程師限制了自己成長，並非公司已經沒有成長空間。

每個人所謂的成長有很多種類，有些人追求的是技術的成長，有些人則是職位的成長，當然每個人多少都會追求薪資的成長。無論如何，環境確實是職涯成長的重要因素，只是工作環境的選擇，通常只決定了個人成長的一部分，而非全部！

如何在工作中成長有幾個要點：

(1) 培養成長心態

成長心態與固定心態在過去幾年中常被討論，無論是ted還是書籍皆如此。

簡單的說，擁有成長心態的人會視問題與困難為自己的挑戰，知道克服了挑戰之後，自己會成功並且有所成長。並且，擁有成長心態的人，會審慎看到自己以及環境的問題，不會一昧地把問題歸咎於外在因素。並且，擁有成長心態的人比較容易知道努力不見得會成功，但是不努力鐵定不行。

關於成長心態還有很多常見故事，請自行上網搜尋。但在此舉個反面的例子：完全不具備成長心態的人，會將自己的問題歸咎於環境問題，直接的表現在職場上就容易極短時間換了許多工作，詢問過去做得不好的事情時常歸咎於環境等等。

(2) 建立能和現在環境結合的學習清單

只要是正常合理的公司，通常都有值得學習的地方。有時候，光是公司仍然還能賺錢這點，就已經值得學習。

然而，軟體工程師的天性就是學習「新事物」。對於已經熟練的技術和事物，久了總是會覺得厭倦。厭倦倒是無所謂，重點是厭倦之後怎麼辦？成熟的軟體工程師通常會了解，真實的環境需要的是「能正確無誤並且低成本有效率的工具與環境」，而非需要「最近好像很熱門的嶄新技術」

成熟的軟體工程師能找到環境與自己的平衡，如果要學習新事物，就應該建立學習的方向，最簡單的方式不外乎就是建立學習清單。

技術上的學習清單容易取得，但是，能和個人現在身處的環境結合就需要認真的想一下。

(3) 主動執行

執行自己的計畫聽起來容易做起來難。大部分的情況下，軟體工程師(特別是處於大公司中)都會認為自己在為別人工作。

事實上，至少在台灣就業市場上的勞工都是在「為別人工作的情況下為了自己而工作」。因為現行的台灣就業市場，已經非常接近自由透明的市場，只要「有能力」通常都可以有非常大的選擇。

執行各種學習計畫的要點在於「這是為自己而做」而非為了別人。

一個考慮離開目前環境的軟體工程師，通常會將「能在工作中成長列為尋找新公司的重要條件」。但其實更重要的是要讓自己有能力「無論在任何環境中成長」是為更重要要做的事情。

軟體工程師的職稱頭銜重要嗎？

軟體工程師根據所在的環境不同，通常有不同的職稱頭銜。例如：程式設計師，工程師，技術經理，架構師，策劃工程師，平台工程師等等。對應於英文可能會有：programmer, engineer, technical manager, architect, principle engineer, platform engineer。 在大組織中，升遷可能是職稱上的轉換，例如在前面加個「資深」，大家就都知道你被升遷了。

對於轉換新的工作來說，職稱頭銜是否重要呢？

1.以工作的本質來說不重要

就技術為主的軟體工程師來說，(假設並沒有直接負責管理員工)，職稱頭銜幾乎不重要，更重要的是做事情的內容和能力的展現。

假如在一個組織裡，一位新進員工的職稱是「sr architect資深架構師」，但他的工作內容實質上是對客戶提案，撰寫業務報告。則其實他是做接近pre-sales或者sales-consultant的工作。在未來無論是組織內部還是他要對外尋找工作，通常還是評估實際做的事情為主，並非職稱。

2.以團隊角度來說可能很重要

職稱是公開的，一個團隊組織裡如果有工程師，資深工程師，資深架構師這三種不同職稱的人：一般來說，大部分的人會傾向遵循同意資深架構師的意見。特別是剛組成的團隊或者互相不認識的團隊。畢竟，職稱的功能有時候類似制服，當你在路上看到穿著警察制服的人，在需要協助的時候自然而然會傾向找穿警察制服的人幫忙。

然而，就軟體開發組織成長來說，職稱的重要性是伴隨組織成長的缺點。這個缺點和人類的認知偏誤有很大的關係：團隊貢獻中，絕大部分的人會認為自己佔比重比較大，因而，在決定升遷或者其他公開獎勵時，一定會有很大比例的人覺得自己沒被升遷是不公平的。

團隊貢獻中，大部分的人會認為自己佔比重比較大：許多實驗（參考這裡）都說明，假設一個團隊的總貢獻是100分，有10個人自己評估自己佔的比重，並且加總起來，很容易就超過150甚至250，但這實際上是不可能的。

也因為大部分的人都有這種偏誤，導致於職稱很多時候對軟體開發團隊有負面影響。如果有重新建立軟體開發團隊的機會，可以採用「無職稱」或者「自選職稱」的方式。

3. 無職稱頭銜讓團隊與夥伴的三贏

當組織沒有職稱時，無論是中期還是短期發展，組織成員會更專注於「實質工作產出」而非「表面變化」。這對組織，對團隊成員，甚至對組織外的人都有好處：

- 對組織的優勢

在組織內，成員都知道自己「做出的事情」才是決定自己的「職稱頭銜」，而非「職稱頭銜」決定自己「做出的事情」。自然而言，團隊成員就會以提高自己的能力和對組織的影響力，並且使用的方式不會是以頭銜和權威。升遷和加薪兩者同時都變成機密，再也不會影響其他人的心情。

當組織要招募人才時，組織會更專注於了解應徵者「過去做的事情」，而不是過去有的頭銜職稱。過去我們面試的時候，常常在履歷表中看到非常驚人的頭銜，但是實際上做的事情可能非常基本。

無職稱會讓面試的效率提高，錯誤率降低很多。

- 對團隊成員的優勢

當團隊成員想要換工作時，在他對外面試的時候，很容易就專注於展現自己的產出。而非說明自己的頭銜。

同上一小節之說明，團隊成員專注於工作的本身而非頭銜的表面公平性不足時，更能發揮自己的潛力和提高產出。

- 對組織外部的優勢

其他外部組織在遇到沒有職稱的人前來面試時，更容易專注於尋找人才得要件。換言之，本來評估能力和是不是適合，本就不應該和職稱有關。已經有人自己不帶著職稱頭銜前來面試，就更容易避免錯誤。

企業巫醫：電商發展史代表人物貝佐斯(書摘)

中文譯名貝佐斯傳，第一次出版於2014年，在此前2年2012正是AWS成長最快速的驚人階段。許多台灣的軟體工程師認識亞馬遜(amazon)並非從零售業開始，而是從雲端服務開始。然而要瞭解自1995開始的網路電商發展，就不能不認識亞馬遜這家公司，而要認識亞馬遜(amazon)就不能不了解貝佐斯此人。因此，原書名The Everything Store(直譯為什麼都賣的商店)翻譯成貝佐斯傳，還頗為適切。

作者是商業週刊的記者(Brad Stone)，但此書很明顯的並非歌功頌德的講述一個厲害的人的生平。書裡穿插了貝佐斯Bezos的生平，和亞馬遜本身的起伏歷史。作者認真的考究當時發生的事情，留給讀者事實，但也不會一昧的鄉愿，冷冰冰的陳述數字，作者也會事實比較，不帶太多評論的給讀者參考。

Amazon發展歷史：亞馬遜成立於1994年，但是網站正式上線於1995年7月16日。並在1997年五月正式成為股票上市公司，當時股價18美金，在這快速成長階段，貝佐斯從各產業挖來各種空降人才，特殊的高選人標準蔚為趣談。1999年到2001年之間的網路泡沫化確實讓亞馬遜受到挫折，裁員與關掉物流中心都在此階段發生。然而，熬過第一次網路泡沫之後，亞馬訓似乎已經知道如何在複雜龐大的電商世界成長，透過併購可能的競爭對手(並購清單請參考這裡)，堅持「最低價策略」，研發Kindle電子書，讓亞馬遜在2008年金融危機時幾乎不受太大影響。2011年員工人數達到3萬人，然而2016年底已經成長到56萬人！

亞馬遜的經營策略是堅持給顧客最低價，換言之，犧牲供應商的利潤，打破任何約定成俗的現狀，是一直以來為人詬病之處。在書中講述很多和供應商衝突的例子很值得讀者細細參考。不過，在此更想探討的是其選人用人與組織管理的

特殊的人才選取與工作價值：

無論是前員工還是現在的員工，都會認為貝佐斯本人，幾乎代表了整個亞馬遜的意志，曾經在1999年找另一位執行長，然而隔年七月就離職，除那段時間之外，這24年來貝佐斯本人就等於是亞馬遜。

而他的做事風格極度鮮明，最著名的例子是，他認為「亞馬遜的員工必須要努力工作，聰明工作，長時間工作，而且不能三個只挑兩個」(You can work long, hard, or smart, but at Amazon, you can't choose two out of three) 這看似不合理的宣稱其實是在1997年才開始，在此之前，早期員工記得他說可以三選二。

他要的都是即時高手，而不要近來學習的人。然而，他選擇的人才，卻又通常不單只是該領域的人，而是他認為有突破性想法與實踐性的人！

此外，「勤儉」也是亞馬遜強調的守則。相較於矽谷其他公司，總部位於西雅圖的亞馬遜員工福利相對少很多。對員工錙銖必較的例子很多，例如：到職的時候發給一個背包，一台筆電，一些資料，然而離職的時候這些統統都要繳回，連同那個背包！

在2014年之前，溫良恭儉讓不存在於貝佐斯心裏，透過酸溜溜的語言咒罵員工是常有的事情。經典語錄有「你這個人到底是懶惰還是無能」「你為什麼要破壞我的人生」「對不起我今天沒吃傻瓜藥丸」「你自己講出這種話，自己不會驚訝嗎」等等。然而絕大部分的員工，無論離職於否，也無論喜不喜歡貝佐斯，都同意一件事：那就是貝佐斯的確很聰明。並且在2014年之後，由於企業變大，這類型不尊重人的對話也減少。

對於重要職位的僱用，貝佐斯會特別設立一個角色參與面試「bar raiser」直接中文翻譯是：提高標準者，基本上這個角色是用來提高進入標準。換言之，希望所有參與面試的面試官，都應該找應徵者是「比自己好的人」。但這個bar raiser本人是經過挑選，並不是每個人都可以擔任，而每個重要的職位，都需要有一個bar raiser參與。此人並非應徵者的主管，也可能不整個甄選過程出任何意見，但卻可以說對任何應徵者說「不」。很明想的是希望企業人才越來越好，而非越來越平庸？

然而，這樣的選人標準卻和福利相違背，在過去，普遍認為貝佐斯是所謂「傳福音」的角色，信他者就會加入，並且做牛做馬，不信者最好遠離這個環境。當然最近數年由於亞馬遜膨脹很快，這樣的標準不見得能在持續下去。

這本書的啟示？

購買在此。從有網際網路以來，貝佐斯幾乎是網路零售發展的最佳討論對象。他確實有遠見，也願意打破既有框架。然而，他也和越王勾踐一樣，可以共患難，難以共享福。不見得每個人才都適合這樣的環境，不過，不浪費時間的投入，根據事實來做判斷，不讓自己做限制的精神，才是這本書為何值得一讀的原因。

軟體工程師：換工作時如何談判薪資

是故勝兵先勝而後求戰，敗兵先戰而後求勝 - 孫子兵法

軟體工程師：換工作時如何談判薪資

已經拿到Offer就沒啥好談了

軟體工程師在經過繁瑣面試之後，一旦從某公司HR（人資）拿到offer，其實薪資談判已經結束。在台灣，無論是本土還是外商，大多數都會由既有資訊：也就是履歷，面試評核，薪資市場參考，工作本身價值等等，給出一個數字，這個數字在給出之後，就表示此公司認定的市場價值。

薪資福利經過「談判爭取」有可能改變嗎？當然有，也因此許多企業巫醫，都會提供一些意見，例如包裝。但以軟體工程師而言，頂多是幾個%的差距，這樣的差距，遠不如這工作本身的意義來得重要。

另外一方面，倘若拿到offer時，無論經過什麼方式爭取，竟然可以取得15%以上的薪資差距，通常表示這個組織並不確定這職位應該帶給組織什麼樣程度的「價值」，換言之，組織裡面很可能因人設事。如果是在研究機構，這可能是一件好事。但如果是在盈利企業，可能是個警訊，表示用人主管與人資並不確定公司政策，更有甚者，公司其實沒有政策！

談判薪資的兩方向

因此，所謂談判薪資，其根本在於：在還沒談之前，就已經站在談判成功的立場。

方向一：人才市場。

同樣是軟體工程師，即便在同個城市，也因不同產業有極大的差別。在台北，如果求職的方向是傳統產業的IT部門，其薪資就大概不如銀行業的IT部門。

同樣的產業，在不同的地理環境也有極大的差別。同樣是智慧手機應用程式開發，在印度外包城市班加羅爾，其薪資就遠不如新加坡。

同樣的產業，同樣的城市，同樣類型的工作，也會因為企業組織的市場定位而有所不同。組織急於擴張，自然就會提出高於市場的薪資水準。

方向二：個人價值

所有人都知道，「自己很厲害的話，薪水自然就會高，就容易找到薪資高的工作」。然而，許多軟體工程師常忽略價值的兩個重點：

(a) 其他人所認定的價值才是個人價值

自己認為自己很有價值，不見得是真的，很有可能是自我感覺良好。根據其他人所「實質認定」的價值才是真的。舉例來說，一個有N年工作經驗的軟體工程師，過去9個月，都只能找到月薪3.5萬的工作，那麼他在市場上實質價值就是月薪3.5萬。反過來說，如果一個有N年工作經驗的軟體工程師，他已經在目前的公司服務N年，最近的薪水是月薪10萬，然而，過去9個月他四處尋找更好的機會時，始終都沒拿到offer，或者拿到offer但是遠少於月薪10萬。這就表示他很有可能在現在的工作薪資是overpay，也就是目前企業可能高估其價值。

(b) 對組織有意義之產出才是個人價值

在徵才的過程中，偶有軟體工程師會覺得「自已都做一些沒有成長性的工作」或者透露「這工作無法讓自己持續成長發展」

這當然表示龍游淺池，組織可能受限於先天環境，沒辦法給這個軟體工程師更大空間。然而，這必須是此軟體工程師對組織已經有「大幅超乎期待」的產出，並且有「實質事實」才行。

建議的行動

作為軟體工程師，如果對你現有的薪資不滿，或者在目前工作領域上做得極度不開心。建議有以下實質行動

(A)  面試自己想去的公司


面試會讓你有機會知道「其他人」對你的價值判斷

(B)  把現在的工作做到超乎所有人的期待

如果無法做到這點，怎麼會知道自己的價值是提升的？又怎麼會知道下次換工作時，薪資談判已經處於不敗之地？

(C)  找到自己喜歡的市場缺口

這幾年來許多軟體工程師會前往中國，或其他成長中市場。這當然也是一種薪資成長的方式。然而，市場的缺口不見得只有成長中市場，即便在台北，也有許多職位和產業有明顯的軟體人才缺口。

找到自己喜歡的市場缺口，或許是個突破的行動。

舉例來說：過去半年來，DevOps在新創和有對消費性市場服務的公司就是個很大的缺口，此外，大數據在銀行產業似乎也是同樣缺口。

---

在多個工作機會中的選擇

只要有數年工作經驗，一個還不錯的軟體工程師，在轉職的時候，應該都有可以拿到3個以上的錄取通知。然後，從中選擇一個最好的工作變成另一個快樂的問題。

如何在獲得錄用的公司中選擇？

扣除掉工作距離，家庭因素，法律因素之後(註一)，有以下幾個方向可供在多個工作機會中選擇的參考：

(1) 優缺點列表

將你的選擇寫在紙上，例如Ａ，Ｂ，Ｃ三個公司。並且將你認為的優缺點條列出來。

這雖然是很基本的做法，但將腦中的思緒，用另一個方式呈現，會讓思考者以較高而且抽象的角度思考選擇性問題。

大部分的人，會列出條列項目大概是：使用的技術，工作內容是否有趣，薪資，工作時間，壓力大小，未來發展性等等。

除了薪資與目前使用技術之外，這些項目大部分都「主觀的判斷」。盡可能在優缺點列表使用客觀的資料。

以未來發展性為例，一個成立不到一年的新創公司，無論其產品有多厲害，它的未來基本上有90%的機會會在2年內倒閉，這到目前為止是鐵的事實。而上市上櫃公司，未來發展性應該優先調查過去3年的財報來判斷，而非看目前的股票價格。

再以工作內容是否有趣為例：必須要是「你到職之後會做的工作」來判斷是否有趣，而非是這公司產品很有趣。因為，即使是資深軟體工程師，到一個新地方也有可能會先做最無聊的工作。

最後，壓力其實因人而異，但客觀的判斷也不可避免，應該以「過去一年有多少比例的人離職」這類型的數字做為判斷的依據。

(2) 自身能力所帶來的影響力

除非是你自己就是這公司的老闆，否則，當你加入一個工作時，透過自己能力的產出，對公司造成正面影響力，是唯一你能做得好做的開心的原因。其他皆屬次要。

某些工作的特性，讓軟體工程師本身的影響力比較低，舉例來說，所有傳統的IT工作恐怕都是如此。即便IT工作非常重要，但通常被歸類為「保健因素」：也就是沒有會死，但太好也沒用。

某些工作看似很重要，但由於組織結構龐大，讓資深軟體工程師發揮空間較有限。例如在超大型軟體公司，有上千名員工，即便是非常厲害資深的工程師，其實對組織而言相對重要性也低。一個超過千名工程師的公司，不會有任何一個工程師特別重。

小型公司對大部分的軟體工程師來說，都比較能透過自身能力，發揮較大的影響力。這也是為什麼過去數年，新創公司能蓬勃發展的原因之一。但的確也有可能，大型公司的某些小型部門，工程師反而會發揮巨大影響力，line的故事可作為參考。

(3) 未來的主管

英文俗語： people quit their bosses, not their jobs.  
在有多個工作機會選擇下，未來的主管是誰變成是重大的考量。

(a) 不知道是誰？

特別是超大型企業，新建員工會有「儲備培訓期」因此有可能在加入此公司之後一段時間，都不太能確定未來主管是誰。這在軟體開發的領域機會不大，尤其是對資深工程師來說。

(b) 考量的方式

盡可能以「事實」來考量，而非憑「感覺」。面試時通常會有問問題的機會，此時可以探究事實。基本的事實像是：團隊有多少人，最近三次加班是什麼時候，最近一次績效評估中，產出最好的員工做了哪些事情。感覺則是「這裡看起來好像很溫馨」，「面試我的主管看氣來很溫和」。

大部分的情況下應徵者期待的是「一個好主管」。然而，人非聖賢，要考量的其實是管理風格上最適合的主管。因此，詢問管理上實質作法，就是考量的最大因素。

當然，這些考量的事實，也應該呈現在比較的優缺點表格中。

---

註一：法律因素是指，即便有超高薪水，不合法的工作還是千萬別碰。

何謂：資深工程師

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

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

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

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

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

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

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

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

技術能力

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

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

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

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

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

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

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

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

實質經驗

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

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

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

團隊合作

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

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

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

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

企業巫醫：強人不受環境影響，很遺憾大部分的人不是

TED眾多演講中，有位經濟專欄作家Tim Harford講了因挫折而成長的主題。

他用著名的科隆演奏會為例，告訴聽眾，一位爵士樂大師Keith Jarrett如何在一台誤送來的沒調音半殘鋼琴上，彈奏出驚艷的效果。科隆演奏會(1975)的錄音，甚至成為史上最暢銷的個人即興爵士鋼琴專輯。實際故事可以參考這裡。

演講者，接下來也提出在稍微困難的環境下：例如英文書本的字型都是粗體大寫，會讓學生為了解內容，刻意「用力」讀文字，讓文字內容更容易被思考和記憶。

些微困難的環境，可以讓大多數的人獲得進步，但極端的環境只有極端少數擁有高強度的技術能力和意志的人，才比較有機會不受環境影響，進一步從極端環境中創造更大價值。

以科隆演奏會為例，Jarrett大師是因為已經熟記樂譜到閉著眼睛都能彈，每個音調和效果對他來說都已經是無意識的動作。因而，演奏遇到即時問題時，他才有「閒暇」的即興創意產生，並實踐出來。一般演奏者，遇到半殘的鋼琴，鐵定是難以完全發揮能力。

在職業生涯中，每個人勢必都有自己擅長的領域，然而，實務上環境造就的問題，在大部分普通厲害的人，會產生難以克服的影響。而僅有在一些特定領域的強人，才能改變環境。

因此，在企業組織中，人通常會去「適應環境」和「控制環境」。就好像Jarrett試著去適應半殘的鋼琴，並且透過自己的能力，進一步控制它，讓它不成為發揮自己能力的阻礙。

幾乎所有的創業者，都是透過創造新的企業，來達到控制環境的結果。不過創業成功的機率相當低。

而在企業組織內工作的人，都需要適應環境，然而，適應了之後，鮮少有人不受環境影響。如果組織內部的氛圍是「保守」「部門壁壘明顯」「官僚」的話會更嚴重，這樣的環境，可能會直接影響一個人對工作的認知與態度 -  特別是剛畢業出來工作的人。最糟糕的是，即便這位新鮮人換了環境，可能還受前一個比較糟糕的工作環境影響。

要能不受環境影響，適應環境，進而控制環境的方式有許多種，但最有效的恐怕是「變成強人」，在專業工作領域上，要變成「強人」，遠比鋼琴大師容易許多。

在專業領域上，如何變成強人？

(1) 特定主題的實質經驗(深度)

無論是nodejs，VBA，還是對excel有非常深入的了解，都是一種特定主題。盡可能探究深入某個主題，當你認為這我已經會了，要試著問一下自己，「全部都很瞭解？」還是「我會用它做某些事情」。以簡單的excel為例，大部分的學生都會說自己「會」excel，但是大部分的剛畢業的學生恐怕連pivot table都不曾使用過。

(2) 和工作領域相關的學習(廣度)

在工作上，必然會遇到和自己工作相關，但可能是其他人負責的事情。這些工作領域，會逐步造就自己對工作上的廣度的了解。以程式設計為例，許多人都對SQL有使用上的了解，特別是由於MySQL, Oracle, MSSQL歷久不衰，程式設計師多多少少都知道SQL。然而，把SQL寫在履歷表上的程式設計師，其實有一半以上的人不了解OUTER JOIN。傳統上SQL的管理是屬於DBA的任務，但現在的程式設計師，越來越多會涉獵devops的領域，對SQL了解就是一個增加廣度的例子。

(3) 在目前工作貢獻

就像鋼琴大師一樣，必須要有「在目前工作上的產出」才是真正的貢獻。貢獻和能力並不見得有直接相關，但是，當具有深度與廣度的知識經驗之後，當然容易對組織有更大的貢獻。


簡而言之，持續學習，就是成為不受環境影響的強人的唯一途徑。

Self-complacency v.s. confidence

Recently, I've interviewed a candidate who applied for Sr. software engineer job and he did demonstrate an unusual character of Taiwanese engineer: self-complacency. 

The interview started from a quick technical review to know his skill set base on his resume.

At first, we quickly ask "How do you identify your Linux skills" and he said "I am very good at Linux". Then we ask a few basic Linux commands, for example: "How to know your current disk usage?". "How to know current Linux kernel version". He actually cannot answer much.

Then, we asked "How do you identify your level of SQL?" and again he said "I am very good at SQL". But he actually don't know any basic concept of "outer join" and "normalization". He explained SQL is what he is working on not the scope of his research area. Then we asked "how to avoid SQL injection in application" but he still can't say anything.

Since his resume said that he is "excellent" in English, we asked if we can continue interview in English. He took a deep breathe and then said "no".

Finally, he explained that he can quickly learn "anything" in one month but then forget that in next month. But he still emphasized that "I think I do have the talent of software development, give me a mission and I can commit the code". This might be true that he can learn "anything" quick and "commit code" for the job. But it is definitely also true that no one will hire such risky engineer.

To me, at first, I think it is extremely unusual to see an engineer with 7 years experience has such self-complacency and with such low actual skill set. But then his resume shows that he worked for 6 different companies in past 7 years. Change job doesn't means that the candidate is bad. But it is still a sign for Taiwanese programmer. Another sign is that he did have very good education background and also good delivery in first 2 jobs. But then, he seems stay in there. 

How to distinguish  self-complacency from self-confidence?

We do want engineers have confidence to take challenges. But how can we tell a candidate has confidence or just too complacency? 

During interview, our suggestions are

(1) Check skills by fact

Ask simple, un-ambiguous technical questions. Do not rely on his words on resume. For example, if his resume shows he has 10 years experience in Linux Operation, make sure you will ask at least 3 most simple questions and 5 middle level questions. If his resume says that he has 10 years in Java, make sure ask the last moment of his java coding. Sometime, the answer will surprise you.

(2) Check experience by real actions

Some candidates described experience like this "design XXXX system". This could be very important task but also could be a self-complacency thing in candidate's mind.

If this candidate lead design meeting, come out a design document - even a hand writing document or drawing picture from whiteboard. That means we can check the design and know how many of "special" things inside the design. 

However, if candidate couldn't say any concrete delivery (we don't need to ask him to provide right away, just want to know if there is), then it is very possible that he "believe" that he did the design job but actually the design was inside his mind. 

You need to heck the actual actions and delivery of it. You can ask "please let me know the exactly things you did on design XXXX system and also the delivery at that time"

(3) Find critical point by the actions candidates did

Always looking for fact of candidates did in previous jobs. It is very similar to (2). We will need to understand his behavior via his previous actions when face a critical situation.

However, I am sure everybody will prepare a pretty nice answer of "why you leave your current company". So just save your time, ask other question.

Check candidate's resume and you will always find some critical moment in his career. For example, a project which requires a new skill set, then you can ask how candidate learn new skills. Or, senior engineer might play leaders role in certain situation, then, you can ask what is the worst thing happened during his leading. 

Always Consider Facts

In short, always consider to gather fact during interview and identify if candidate fit your organization through fact, not to guess.

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

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

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

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

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

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

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

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

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

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

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

(2) 換！

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

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

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

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

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

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

(3) 避免帕金森法則

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

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

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

---

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

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

How to build a self-motivated software developer team

A team which all team members are self-motivated is a dream team where everybody want to join in. But, it is really rare. Well, maybe the 1992 dream team was one of the cases but we didn't see many examples in software developer's world.

Nevertheless, to build a self-motivated team is a major task of a manager. If you are the manager, this should be your priority-zero task, and should be only one zero, if you are going to build a new team.

Self-motivated might be the best way to drive software engineer's performance. Since high productive engineer works high involved in creativities and mental work.  These are hardly be gain or impacted by salary or physical award (reference: 1, 2, 3). Sometimes it could be driven by a noble target: save all poor children in the world, increase average human life to 200 years. But unfortunately, that kind of things normally happens in non-profit organization with a born charismatic leader. 

So how to build a self-motivated software developer team in a common working place?

Three key points: (1) selection (2) intersection (3) automation.

(1) Selection

If a member who is already a self-motivated person, then it will be easy to keep his good attitude. Since it is pretty hard to change a person's mindset, therefore to get a right person is the most easy way.

Do select a person who already has record on self-motivation. DON'T select a person who has good skill-set but has bad records on self-motivation and you believe you can change his/her mindset, I won't say it is possible but you need to understand that you really have much less changes. Since you can't be with the person 7x24 and his mindset is only inside his brain.

The key point of selection is try to understand his past. Do not judge his "self-motivation" by ask future question like: will you be self-motivated in our team? Understand his past working experience by asking the difficult moment. Especially, sometime he might not be in spotlight and what he did on that moment.

Again, identify a person's past is the best way to select right attitude candidates. And a best fitting person can really have positive impact for the team. 

(2) Intersection

There is no way to read team member's mind. People have left-hand-column, even if you already selected best people to join your team and you were very sure they all are honest. But they surly have things which can't tell or won't tell.

Some leaders or managers will try to dig it out, it is fine to do but not that easy. The best way is to admit the existence. And then leaders should focus on the intersection which is the area that covers the target of a single team member, the team and the organization. And that is also the area where creates win-win-win.

A self-motived member could find that area by himself. But if you are leader/manager, you should keep in mind that figure out the area and knowing the area is very different in each individual. To fine tune a bit earlier can largely reduce the risk of un-motivated situation.

For example, "Ken" is always in good performance and deliver pretty good result. And you believe that you knew that his career interesting is pure technical area. Which means he might want to be an architect in the future. However, if you see he is pretty happy to lead junior members to work out teamwork activities, for example : organize a study group, handle company travel, or year end party. That might be a sign of that he is actually want to be a manager in the future. If his actions is toward his goal then it is fine. However, if his actions didn't reflect your assumption, then it is your time to reset yourself or/and make a little changes.

The bottom line is to avoid lose-lose-lose situation. This sounds funny and should not even considered to happen. But there are too many true sad stories existed in the world. An usual/typical sample in software developer's world was: a team (which members are well-pay) worked over-time on an ambiguous project for months, delivered a product which didn't fit PM's expectation, company lose money, members lose life, customer didn't get result: no body wins.

To avoid 3-lose situation, make sure there is an intersection of all. If you were the manager, make sure you can guide your members into his own intersection. But if you really see that there is NO intersection at all, make sure to create one.

(3) Autopilot

Autopilot means a member knows exactly what to do, how to do. And most important thing is if there are tasks out of his current skill set, he will know how to learn. He can even do self-consideration of intersection and selection. Totally worry-free.

Again, if the selection was done good, to let team member become autopilot will be easy. All you need to do is coaching. Coaching is another topic of a few books plus lots of trainings/experience. If you are an experienced leader/manager then you already know how to do, just reminder to keep open your mind. And also please keep in your mind that open-your-mind is never easy.

The bottom line is to avoid micro-management.  Software development is highly brain consuming job. Micro-management never works in software development, it does work in other kind of job but it definitely doesn't work in software development. If you need to talk to your member about when to arrive in office, when to leave, what to update in Slack, how to write email. That means you are NOT trying to build self-motivated team or this specific person won't fit in a self-motivated team.

Sorry, No short-cut

There is no short-cut in for organization theory. However, practically do the right things normally will get the positive result in a few months. Of course, sometimes in a rapid startup environment, it seems no time to wait. But most of us in software developer world are running marathon not a sprint.

Skill sets and performance concerns:

There is one more thing. I didn't discuss skill sets and performance here. But this is actually extremely critical for a software developer's team. Without an excellent skill sets and performance delivery the self-motivated will be useless. However, this "should" be not difficult to identify during interview and resume check.

在台灣建立研發中心？

現代經濟學鼻祖：亞當斯密的國富論中，描述產品價值有三個主要來源：「土地」，「資本」與「勞動」。其中土地泛指自然資源，勞動在現代社會不僅僅指人力，更重要的有執行力和創意的人才。

而今資訊社會中，因為交通和電信費用降低，以至於人才流動成本也跟著巨幅地降低(註1)。資本主義當然會讓「看不見的手」運作，而讓企業組織的經營，朝向最低成本最高效率方向前進。人才的取得也不例外。

最近一兩年已經有太多企業巫醫在討論「台灣人才外流」的問題。其中不外乎以聳動的標題。例如：

＊「我在台灣看不到工作的未來」... 或許只有你看不到也說不定？
＊「低薪惹禍誰想待在鬼島」... 低薪是一回事，但是台灣在所有地球上居住人口超過1萬個人的島嶼裡面，絕對排不到鬼島行列，請想一下菲律賓印尼加勒比海這些島國。
＊「台灣小而亂普遍又低薪」...的確台灣不大，但是普遍低薪和亂這兩個形容詞，卻在該文中沒有任何支持的數據和研究，只是個人感想當作新聞來操弄。

有時候，單看客觀事實並不有趣，不太能成為焦點，然而客觀事實卻是，想確實進展的最佳依據。所以，我們應試著了解，就經濟學的角度而言，企業組織應該「移動台灣人才」還是「在台灣建立研發中心」比較適合呢？(註2)

首先，要簡單區分「人才」，「員工」和「人力」。人力泛指勞動力，在最基本的教育水準下，就可學習工作得稱為人力，資本主義天生會使用最低薪資，在當地合法的範圍內榨取人力。員工指的是企業內受雇的所有人，可能需要某種訓練過的技能，但其學習能在短時間達成。人才比較難定義，在此暫時指需要長期間的教育培養，並且已經有7年以上的實務工作經驗的專業人士。而在此要討論的，就是「人才」的移動，而非人力或者員工的移動。

最簡單衡量人才流動應該是看「實際獲利」，包含薪資，居住成本等等。衡量一個國家的薪資有很多方式，雖然沒有最好的方式，但是觀察GDP和NNI都可以考慮。

可是，更有趣的數字在於GDP和PPP的差距。

最最粗淺的說，人均GDP表示此國家平均每人在該年生產的價值。三大組織：聯合國，世界銀行，國際貨幣組織：每年都會公布此數字。彼此間資料收集方法略有不同，數字彼此有一點點差距。

讓我們專門看五個國家的2016 GDP：台灣，中國，日本，韓國，新加坡。

	GDP美金
台灣	22,453
中國	8,133
日本	38,917
韓國	27,632
新加坡	52,961

這和我們內心理解差不多，台灣似乎遠不如其他先進國家，不過大陸的「平均值」仍然很低(當然比較特定區域：例如上海，那結果可能不太一樣)

然而，更有趣的數字是PPP：平均購買力。PPP其實和GDP的計算方式雷同，只是將匯率和物價也考慮進去。而PPP才是在該國家裡面的人，實際上消費真實情況。將GDP和PPP之間的差距，除以GDP就是「購買力相對於生產力的增額」。參見下表：

(本文的數字都是美金計價，並由wiki節錄國際貨幣基金會取得)

	GDP(美金)	PPP(美金)	購買力相對於生產力的增額
台灣	22,453	48,095	114%
中國	8,133	15,399	89%
日本	38,917	41,275	6%
韓國	27,632	37,947	37%
新加坡	52,961	87,855	66%

這個表顯示幾個事實：

(1) 在這五個國家內，日本的GDP和PPP最接近，而台灣差距最大。

(2) 單純看GDP，台灣遠不如日本韓國。然而，單純看購買力，2016年台灣比日本韓國都要來得高。

(3) 假設這五個國家的人才能力差不多，則在台灣建立以人才為主的研發中心是「最划算」的選擇。因為同樣價格的人才，在台灣實質獲利是最佳的。同樣100單位的錢，在這五個國家中，台灣實質可花費214, 日本是106, 中國目前是189,韓國為137,新加坡是166。(註3)

(4) 購買力和物價很大的關係，然而購買力要和GDP同時考量，因為就算有極低的物價，GDP不高也是沒有意義。

(5) 絕大部分先進國家這兩個數字都很接近，某些國家(例如GDP一直都排名前三名的盧森堡)甚至購買力增加率是負的！


然而，單就這兩個數字，很容易看出缺陷。例如把菲律賓加入之後變成下表：

	GDP(美金)	PPP(美金)
台灣	22,453	48,095	114%
中國	8,133	15,399	89%
日本	38,917	41,275	6%
韓國	27,632	37,947	37%
新加坡	52,961	87,855	66%
菲律賓	2,991	7,696	157%

難道字面上的解釋，菲律賓比台灣更適合建立研發中心？吸引更多人才。這張表可以解釋菲律賓可以找到更多「人力」。無法解釋為什麼沒有更多人才。因此，需要再加上另一個指數：HDI 人類發展指數。

人類發展指數計算很繁雜，最粗淺的說，指數越接近1表示這個國家越先進，先進包含基礎建設，教育等等。(註4)

	GDP(美金)	PPP(美金)	購買力相對於 生產力的增額	HDI	HDI權重之PPP	人才庫 划算指數
台灣	22,453	48,095	114%	0.885	42564.075	90%
中國	8,133	15,399	89%	0.738	11364.462	40%
日本	38,917	41,275	6%	0.903	37271.325	-4%
韓國	27,632	37,947	37%	0.901	34190.247	24%
新加坡	52,961	87,855	66%	0.925	81265.875	53%
菲律賓	2,991	7,696	157%	0.68	5233.28	75%

將HDI的權重考慮進PPP中，並按照購買力對比於生產力的增加，計算出「人才庫划算指數」。在此指數很簡單的看得出來，建立以人才為主的研發中心，還是台灣最划算。(註5)

當然這個模型有很多缺陷和假設，但是起碼它是以確切的事實作為考量，並且可以具體的討論和修改。相較於譁眾取寵的喊叫人才外移的嚴重性，相信來得有用。


NNI, GDP, PPP三者的細節，請自行參考wiki

(1) NNI (國民收入)
(2) GDP(國內生產總值)
(3) PPP(購買力平價) ：要注意的是，購買力評價，並不是很好衡量生活水準的方式。此方式較適合用於國家間互相比較，不太適合同一國家不同時間內比較。
(4) HDI 人類發展指數 
(5) 人才庫划算指數：=((PPP*HDI)-GDP) / GDP

---

註1：就在不遠的15年前(2003)，當時出差到歐洲每個月要額外花上5千元台幣左右的電話費網路費，用以和家人聯繫。如今出差到歐洲每個月頂多花1千五百台幣元，就可以獲得比15年前更高品質的視訊通話。

註2：這裡有很多假設，假設國際企業需要的是人力而非人才，假設企業組織是理性的，假設台灣人才也是理性的。

註3：這裡的增額，和個人在單一國家內花費的感受會有所差異。換言之，要有所感受，必須要在差不多時間，同時在日本和台灣取得相同工作的類似薪資才能做比較。

註4：也因為HDI指數很大一部分涵蓋教育，因此數值越接近1，國民教育水準會越高。

註5：沒錯 人才庫划算指數 是自己的推測 並沒有什麼研究根據...XD