在多個工作機會中的選擇

只要有數年工作經驗，一個還不錯的軟體工程師，在轉職的時候，應該都有可以拿到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) 在目前工作貢獻

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


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

企業巫醫：市場領導者的鐵律 .(書摘)

Discipline of Market Leaders 市場領導者的鐵律。

不確定是否有中文翻譯書籍。

書中描述，要成為優良企業組織，必須將以下三件事，做到某種可接受的程度，並且必須要在其中一件事情變成市場的領導指。

(1) Operational Excellence 作業最佳化
(2) Product Leadership 優質產品
(3) Customer Intimacy 客戶關係


(1) Operational Excellence 作業最佳化

產出高效率，低價格，容易購買的流程與產品支援。盡其所能降低成本，盡量標準化，簡化各種控制，加上有精確的中央控制，與能做到整合性高速的管理系統，減低浪費。範例企業是Walmart和Dell。

(2) Product Leadership 優質產品領導

產出最好的產品或服務，專注於產品創新，產品開發，探索新市場的可能性。並盡可能追求未來的創新，領導未來的可能性。範例企業是Apple。

(3) Customer Intimacy 客戶關係

著重客戶關係管理，將執行面交由最靠近客戶的員工，縮短對客戶服務的距離，幾乎永遠以客為尊，願意在一般的產品或服務上，對個別客戶進行客製化最佳化，客戶滿意是最大的核心價值，影響所有流程。範例企業是Ritz Carlton(飯店集團)，IBM。


其他參考：富比世

沒有QA？如何確保軟體開發品質

任何軟體專案或產品，達到高品質是開發團隊必然的目標。不過高品質並非垂手可得，它需要團隊的共識和努力才能達成。

確保品質有很多方式。過去常見的方式是瀑布式開發方式(waterfall)中，在程式設計師確定code complete之後，靠QA/QT/QC(註1)來執行測試，並且在測試週期中，驗證是否符合設計規格，並記錄追蹤問題(bug)，有時候甚且扮演催促修復的角色。因而，特別是大型團隊，專門「處理」品質的QA角色十分重要。很多時候，團隊可能面臨沒有QA的狀態，此時要如何確保品質呢？

為什麼會沒有QA

有時候，環境造就沒有QA的局面。例如，新創公司可能也只有5個人，無法有專責QA。又例如，大型企業中因資源分配不均，導致某些專案無法有專責QA。

但更多時候，沒有QA指的是，沒有能做「真正QA工作」的人。也許團隊裡面有許多人持有QA的職稱。但很可能僅做到QC/QT的工作(註1)。實務上，在軟體開發團隊中，實際做的事情其實比職稱來的重要。就品質的角度而言，QA大部分的時間應該花在開發循環「前期」或者「中期」。以Scrum中的Sprint來說，在kick-off時，QA應該花最多時間在定義DOD，決定產出的評斷標準，在sprint每天活動中，QA應該花時間在檢視產生的程式碼(code review)並且透過每個工作產出，主動改善現有品質。換言之，QA應該比單純的程式設計師，更會程式，更知道系統的交互作用細節，並能透過直接或間接修改程式，直接影響開發過程中的品質。因為，開發前中期的品質修正，效果好，成本低，遠比開發「後期」再來幾個測試循環來的有效！

簡要的說，能真正做QA工作的人，必須能比程式設計師團隊更會寫程式。起碼也要是「曾經」非常會寫程式。

如果團隊不巧沒有這樣的人，有三種方式可以在沒有QA的情況下確保軟體開發的品質：

方式一：Scrum

Scrum方法論中，概念上每個Scrum成員都是「同樣質量」。換言之，Scrum進行中重視的是產出，每個SPRINT的結果是「可交付的東西」。而Sprint中間要完成的細項，應該將品質涵蓋入內，而由自行取得該任務的人，完成其保證。

有許多作法和上面這段熬口的說明有關。首先，DOD (definition of done) 除了涵蓋unit-test之外，其實應該也涵蓋整合測試。如果不涵蓋整合測試，就應該另外有一個任務是專做測試。並且，每個story完成中，必定涵蓋這個story應該要有的使用測試(用以檢驗規格)以及回歸測試(用以檢驗是否有副作用)。這些測試，可以單獨成為一個工作，也可以作為DOD的一部分。

無論如何，基本概念是：「人人應該都可以生產程式碼，當然人人應該都可以測試」。實際執行時，或許有些人比較常「拿到」測試工作，但這並不代表這些成員就只是進行測試而已。有些人比較常拿到「寫程式性質」的工作，但並不代表這些人不負責品質。

Scrum的團隊重視每個Sprint的共同結果，此結構也讓沒有QA也能達到高品質。因此Sprint的長度不能太長，太長就會落入「團隊中自行區分QA和Engineer」的後果。

方式二：Pair Programming

Pair Programming是指兩個人一起用一台電腦，一個鍵盤來共同寫程式。這作法在2000年左右發展的Extreme Programming被大大推崇，不過能有決心推動的團隊並不常見。

由於Pair Programming讓每段程式碼至少都會被兩個人看過，而且在頭腦中想過。它可以避免大部分的低級錯誤(拼錯字)，也可以避免懶人錯誤(程式風格，漏寫unit-test)，然而，更重要的是它讓兩個程式設計師的真實想法，在執行同件事情的時候被「好好溝通」。而這更大幅避免對設計或需求的誤解。

Pair Programming似乎有效率和產能上的疑慮，但無論如何，它確實是在沒有QA的情況下，確保開發品質的絕妙方式。強烈建議閱讀一下wiki上的Pair Programming最下面的參考論文。

注意！

前兩個方式雖然符合敏捷開發的精神，並且能從系統結構層面，解決問題。然而，這兩種方式都必須要有結構性的改變，除非是剛剛成立的新團隊，要造成結構性的改變很困難，而且，即便做的好，也得花上其他心血才能有「能見度」，有能見度，才有所謂的功勞。

有兩個古時候的例子：

(a) 鶡冠子扁鵲：扁鵲曰「長兄最善，中兄次之，扁鵲最為下。」魏文侯曰：「可得聞邪？」扁鵲曰：「長兄於病視神，未有形而除之，故名不出於家。中兄治病，其在毫毛，故名不出於閭。若扁鵲者，鑱血脈，投毒藥，副肌膚，閒而名出聞於諸侯。」

(b) 孫子兵法：故善戰者之勝也，無智名，無勇功，故其戰勝不忒。

然而，對於一個軟體專案的主管而言，這些結構性的改變才是自己真正的價值。即便價值很難被衡量，但價值會永遠存在自己的手上。

如果短時間難以改變環境，可以考慮以下的方法三：

方式三：Part-time & Automation

工讀生(part-time student)和自動化測試(automation)似乎是兩個不同主題，但就確保軟體開發品質而言，把他們當做「一件事情」來處理，會有驚人的效果。

簡單的說，就是雇用3至4個優秀的工讀生，每週上班2-3天，組成工讀生團隊，執行測試任務，並且在熟練測試任務之後，開始進行測試自動化撰寫，並且在小組長(team leader)帶領下視情況參與更多品質管理的事情。這聽起來是個繁複的事情，但執行起來，遠比方法一二簡單。

其步驟如下：

(a) 選定一位以後想要朝專案經理或主管方向前進的優秀資深工程師，讓他作為工讀生團隊小組長

(b) 到各大學相關科系徵求大四以上的長期工讀生，一般來說，只要能妥善說明對他們未來就業的好處，通常可以找到足夠優秀的人。工讀生至少需要在職6個月以上。

(c) 組成團隊後，第一個月僅只需要熟悉目前軟體系統，第二個月才開始讓他們執行測試計畫，回報並記錄問題

(d) 在此過程中，由小組長指定測試內容和範圍，換言之，這段期間，其實小組長才是扮演QA的角色。而其他成員都可以將繁瑣的測試交給工讀生。然而，程式的品質仍然是所有成員負責，工讀生不在Scrum的範圍內，因此不「負擔責任」。

(e) 當測試進行2個以上SPRINT，工讀生應該已經開始覺得測試是很煩人的事情，但也應該知道品質對產品的重要性。這和在學校做專案計畫有天壤之別。因此，就可以開始由小組長領導工讀生進行測試自動化。

(f) 測試自動化並不期望把所有整合測試/回歸測試，100%統統自動化。只要把「簡單瑣碎」的測試自動化，通常就能節省一半以上的時間

(g) 通常六個月後，3-4人的工讀生團隊就能完成部分整合測試，和大部分的回歸測試。而下一輪的新工讀生，可以選擇從頭開始打造新的測試自動化，也可以接手前期工讀生做到一半的自動化。打造新的自動化通常可以用新的工具，新的角度來測試既存系統，可以讓品質在一次提高。接手前期工讀生的自動化，可以讓自動化範圍更廣，空出時間來做其他的事情


工讀生進行自動化測試的開發，對組織，對小組長，對工讀生有三贏的效果。(參考：實習生的三贏)

組織：讓沒有QA的團隊，能確保高品質的產出。除了要花些微的工讀費用之外，讓團隊成員能把瑣碎的事情下放給優秀的工讀生，使團隊成員能集中心力，但又同時負責個人生產的品質。同時，由於利用工讀生來培養小組長，讓組織能了解這個資深工程師，適不適合作為領導者，萬一不適合，頂多也是犧牲工讀生而已。

小組長：沒有人生下來就會當主管，當主管必須要有經驗，而工讀生團隊是主管最容易讓資深工程師測試自我的地方。因此小組長可透過這獨立運作的團隊，練習各種管理技能。

工讀生：大部分優秀的大四以上學生，都猜得到業界和學界的差異。許多人可能會在暑假應徵summer intern，然而其實短短兩個月，通常會做比較獨立的專案，雖然都很有趣，但是和在學校有很大的不同。加入實際開發團隊，即便只是做測試，也能了解「現實和學校」的差距，並且體會到軟體專案開發時，品質的重要性。讓有此六個月經驗的工讀生，更容易在未來找到更好的工作。

---

註1：關於Quality Control, Quality Test, Quality Assurance, test engineer, SQA的各種工作角色的區分，請參見wiki。然而，誠如前所述，工作角色名字不重要，做出事情才重要。

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.

Scrum: Feature-boxing of Sprints

In certain scenario, a scrum project could allow different length of Sprints and still satisfies Timeboxing principle. It benefits an involving software product of build MVP, increase integration quality and make members even more focus.



Time-boxing is one of fundamental practices in Scrum methodology. Most of actions in scrum are time-boxed. It makes sure the project keep going and also lets members focus on current task.

Time-boxing is one of the cure of Parkinson's Law of Triviality for all kind of meeting. No matter it is Sprint kick-off or daily standup. I believe it should apply to not only project management but also other area of organization, as long as the timeframe is a consensus of members. 

You can easily find the definition or discussion of how important time-boxing (or timebox) is in google. For example: this one or this one.

Timeboxing in Sprint

A Sprint in scrum also apply to time-boxing. Normally it means when project kick-off, all scrum members will decide how long is a Sprint. The recommended length is 4 weeks in software development. After that all Sprint will be in 4 weeks, no matter how many stories have done or what changes happened between Sprints. That also means if a project is in Sprint-11, 40 weeks was gone. 

A fixed timebox sprint make process happens. But is it necessary to keep the same length of Sprint?

Still timeboxing but flexible in next Sprint

Timeboxing is still critical and should be applied in the moment before event start. Sometimes, we should not fix timeframe in project kick-off and keep for next 40 weeks or more.

In fact, every Sprint kick-off meeting should also discuss a timeframe of this specific Sprint.

Image a sprint-kick-off meeting. Everybody: Product Owner, Scrum Master, Scrum Members were together in this Sprint kick-off meeting, discuss stories and story-points. If PO select 3 stories: P1, P2 and P3 which needs 2 weeks, 1 weeks, 3 weeks. What team should do? The general practice should be keep P1 and P2 in this Sprint and also select a few lower priority task to fill up that one left week. However, there are a few drawbacks in this situation. Firstly, remember Parkinson's Law? members might extends the time for not select lower priority tasks which sometimes is not a bad idea. But secondly, if a scrum team keep doing select a lower priority to fill up time slot, it make the "priority" not "priority" any more. 

If all members have consensus of flexible Sprint length, they can easily setup next Sprint to 3 weeks. And that Sprint will done  P1+P2. Or with Product Owner's agreement, they can setup next Sprint to 6 weeks to complete all P1~P3. 

In some scenario, the most beautiful way should be keep P1 in next sprint only. And this Sprint will be just 2 weeks. 

Make MVP possible

Why do one story at one Sprint is a beautiful way? Well, in some scenario, we need to make MVP(Minimum Viable Product)...and keep make MVP for a while to identify market and make sure minimum waste. Unfortunately, no body can foresee the future. A quick/early delivery is the reason why MVP is useful and also the reason why it is good to stick a single story delivery in a single Sprint. To achieve that, we need flexibility in different Sprint.

The key person of MVP is Product Owner (PO). And to make MVP possible, the bottom line of scrum is to have PO's real participant. In reality, it is very very hard to PO to focus on what he needs to do. A single story delivery forces PO to make a decision of the real priority of backlogs. Since the team will really delivery a things in every Sprint and of course PO should then put the thing in the market. PO can't say: well, it is too early to go for market. Since this is his priority one! Priority one should go for market right away! 

Why Quality improved?

Very simple, each Sprint with only one story has its own QA process and due to the complexity of change is short. we can easily fix integration issue or new defeat much quicker than a sprint with more than one story.

Agile: Feel comfortable to Adopt reality

An agile team should be comfortable to adopt changes and those changes should reflect to reality. But should still keep the critical concept. There is always a way to enjoy both without compromise to an uneasy method. 

To be flexible in Sprint length doesn't mean to break Timeboxing. But it does break some rule from the regular Scrum training. Nevertheless, process is continuously improving is the bottom and spirit of Agile. Scrum master or organization leader should take responsibility to make sure the process could be tailored after retrospective.

Case Study

As developer manager of a enterprise software product, I modify a bit of product release method to make sure PO's backlog is a real priority to reflect market needs. 

The result is since 2016/July to 2017/Mar (8 Month), we delivery 5 releases. The longest Sprint is 8 weeks and the shortest Sprint is 2 weeks. We actually complete 5 major stories and achieve following technical result.

(1) Quality: no side effect in these 5 release. Compare to previous fix Sprint length model much lower technical defeat in beta.

(2) Productivity: averagely, more code conduct per engineer compare to previous fix Sprint length model. However, at the same period of time, we enjoy more team building activity then before and very very very few overtime.

(3) Motivation: engineer could see the result (no matter good or bad) few weeks after delivery. Previous fix Sprint length model needs 3 to 9 months to know if our works really matters.

If you'd like to know more detail, please drop me email.

軟體專案管理 - 版本控制系統內的程式碼基本分析

孫子兵法：夫未戰而廟算勝者，得算多也；未戰而廟算不勝者，得算少也。多算勝，少算不勝，而況無算乎！

任何軟體開發專案的基礎都是「程式碼」。即使，專案經理不需要親身撰寫程式碼，但是必然要能夠透過程式碼，取得專案關鍵資訊，作為專案領導管理的最佳參考。(關於專案進度，請參見這篇。)

版本控制系統(git, cvs, p4, svn等等)，則是有效控制程式碼的基礎，開發過程大部分的事情會發生在這裡，也應該發生在這裡。

如果你的軟體開發專案，沒有使用版本控制系統！！？？...呃....請參考註1。

版本控制系統「至少」可以提供以下這些重要而且基本的訊息給專案管理者：

(1) 截至目前為止，有多少人實質參與專案
(2) 截至目前為止，專案的實質規模(程式碼檔案數量 行數等等)
(3) 一段時間內，此專案程式碼品質的推測
(4) 一段時間內，例如過去48小時，軟體團隊的實質產出
(5) 一段時間內，例如過去7天，有沒有人在非上班時間內工作


專案管理者(或者Scrum Master)應該自己取得這些訊息。為什麼？？

---

"Доверяй, но проверяй" 
 - 俄羅斯名言，意思是 Trust, but verify  

冷戰期間美國總統雷根特別愛用此名言，根據wiki說明，雷根是受到一個作家的影響

---

因為，過去專案管理者常見兩種極端：

(1) 極端放任自由：在Scrum的精神下，雖然每天站立會議和燃燼圖，都可以揭露專案最確切的進展，完全相信成員的口頭回報
(2) 極端間接的繁複審閱：在沒有技術背景的情況下，透過頻繁而起瑣碎的會議，加上各式各樣文件追蹤，試圖了解目前進展。

這兩者都有明顯的問題，Trust, but verify才是正確做法。以Scrum的精神取得每日進展，並且，專案管理者應該「自己」想辦法檢查。專案管理者，如果沒辦法自己檢查，表示對此專案的本職學能不足。(註2)


專案管理者能夠做的程式碼基本分析有很多。好的專案管理者，至少需要能自己「動手」，利用工具或者程式，透過事實，了解下面三件事情：

(a) 基本專案狀態分析：哪些人寫了哪些程式碼
(b) 哪些程式碼檔案很重要：某些程式碼就是常有問題
(c) 哪些人需要額外關注：某些人工作壓力大常加班

以下以git為例，其他版本控制系統也能做到類似的事情。

基本專案狀態分析

靜態程式碼分析工具有很多。例如，gitinspector可以揭露整個專案的大致情況。gitinspector的安裝使用請參考這裡。
以github上的serverless.com為例，在github上clone這個專案，並且執行#gitinspector的結果如下：


首先會大致列出作者和過去的產出摘要，例如Aaron在這個專案一共commit了8次，包含170行程式碼跟刪除87行。這個表當然不能作為績效考核用途，但是可作為參與度的重要參考。很明顯的Austen鐵定比Chris的參與度高很多。




接下來隨即會列出還存在的程式碼行數。以Austen來說，他還有2713行的程式碼存在。和他的總新增行數與刪除行數有很大的差別。這很有可能是他參與了開發初期，而開發後期的版本沒參與。

哪些程式可能容易有問題？

程式設計師每天辛勤的工作，自然會知道哪些程式常出問題。而專案管理者必須要由技術面來獲取正確的資訊。版本控制系統會記錄每次程式修改的原因(如果commit的備註正確的話)。最簡單列出「要注意的哪些程式碼檔案」

git log指令，可以加上 --grep=<string> 來濾出字串，以下例子只用fix當作過濾條件，並且配合linux其他指令：sort, uniq 就做出簡單的報表：

~/serverless# git --no-pager log --name-only \

--grep=fix  --pretty="%s" | sort | uniq -c | sort -n

     19 lib/ServerlessState.js
     19 tests/tests/actions/ResourcesDeploy.js
     20 lib/ServerlessProject.js
     23 lib/actions/EndpointDeploy.js
     23 lib/actions/ProjectInit.js
     23 lib/actions/RegionCreate.js
     23 lib/SerializerFileSystem.js
     24 lib/Serverless.js
     25 lib/actions/ResourcesDeploy.js
     25 lib/actions/StageCreate.js
     25 tests/test_utils.js
     27 package.json
     27 README.md
     28 lib/actions/FunctionRun.js
     34 lib/actions/FunctionDeploy.js
     38 lib/actions/FunctionCreate.js
     55 lib/utils/index.js
    101 tests/all.js

當然，以上報表只是列出有fix字串的commit中，哪些檔案出現次數最多。 tests/all.js 明顯是最多的，但也很明顯這檔案本來就是會被一直修改。此外，README.md也是一樣，大概也不是真正有問題。不過其餘的檔案倒是可以額外關注一下。

程式有問題的的判斷方式有很多，除了在commit的紀錄中說明是[fix]或[bug fix]之類。但也可以考慮總行數，刪除的行數，增加的行數，並且配合QA/bug tracking系統，才較為完整。

哪些人需要額外關注？

「人的問題」，永遠是最難解決的問題。然而，卻也是要優先解決的問題。組織中必然有需要「被關心」的人。

專案組織中，最要被關心的人是「表現好且有潛在壓力大」，以及「表現不好且對團隊有負面影響」這兩種。其中，表現好的人更是要優先處理。

除了每天例行工作接觸之外，專案管理者應該要有確切的「數字」。假設，我們想知道在此專案中，哪些人常常「晚上」工作。最簡單的方式是分兩步驟，先用git列出作者時間，然在寫個簡單的統計程式，列出所有人的「晚上」工作時間和「平常」工作時間次數。

* 步驟一：先取得所有的branch, 然後, 以下git log指令可以列出作者和時間，並且輸出到檔案author_time_log

 

# for BRANCH in $(git branch -a | grep remotes | grep -v HEAD | grep -v master); do git checkout --track "${BRANCH}"; done
# git --no-pager log --all --pretty="%an,%ai" > author_time_log

檔案內容大概如下

....
Austen Collins,2015-08-05 18:28:18 -0700
Austen Collins,2015-08-05 17:26:26 -0700
ryanp,2015-08-05 17:04:37 -0500
Derek van Vliet,2015-08-05 09:31:56 -0400
Michael Friis,2015-08-04 18:54:03 -0700
Austen Collins,2015-08-04 15:04:46 -0700
Colin Ramsay,2015-08-04 22:03:48 +0100
Chas Warner,2015-08-04 14:53:59 -0600
Austen Collins,2015-08-04 11:19:31 -0700
Austen Collins,2015-08-04 11:15:44 -0700
Austen Collins,2015-08-04 11:11:06 -0700
Austen Collins,2015-08-04 11:09:24 -0700
....

* 步驟二：撰寫簡單的分析程式，設定正常時間是早上7點到晚上8點，其餘都算不正常時間。用人名為單位加總之後，就可以產出簡單的報表。簡單的統計程式原始碼請參考這裡。

此表中，Eslam幾乎有一半的commit都是在晚上產生，而Kamil則是標準完全正常時間工作。

Joe Turgeon [1, 0]
Erik Erikson [15, 7]
Ian Serlin [1, 0]
David Hérault [1, 0]
Peyton Zhou [2, 0]
Kazato Sugimoto [2, 0]
Nick den Engelsman [1, 0]
Kiryl Yermakou [0, 1]
Austen Collins [575, 267]
Kamil Burzynski [101, 0]
Frank Schmid [9, 2]
Jacob Evans [13, 1]
Michael McManus [1, 0]
Eslam A. Hefnawy [158, 132]
Dave Newman [0, 1]
Ryan S. Brown [35, 6]
doapp-ryanp [129, 48]
Michael Friis [1, 0]
Matthew Chase Whittemore [2, 0]

當然這並不代表Eslam的表現好而且壓力大，這只是提供給管理者參考的事實。專案管理者，必須要事實層面，檢查軟體專案的狀況，因為很多時候「會吵的小孩有糖吃」，只單純被煩就會給糖的專案主管，其實對團隊是沒有價值的。

小心統計陷阱

統計數字都可能會有陷阱，程式碼的基本分析也是統計的一種，自然要小心陷阱的存在。專案管理者應該要善用統計數字，切勿被統計數字所左右。請參考統計與謠言。


 

---

註1：軟體開發專案不使用版本控制系統，會讓專案本身暴露在極端的風險中。如果你是專案管理者，讓專案暴露在風險中就是你的責任。如果你只是個開發人員，儘早離開高風險的環境才是上策。

註2：某種情況是，專案規模過於龐大，例如參與開發者超過100人，某些技術確實不見得能完全掌握，但專案管理者，仍然要保有部分自行檢查的能力。

在台灣建立研發中心？

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

而今資訊社會中，因為交通和電信費用降低，以至於人才流動成本也跟著巨幅地降低(註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

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

或許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調整」。而重大失敗，更是會變成具有成長心態的人，隱含的內心記錄的一部分。