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

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

簡單的路難行 - 人才的激勵與維持

資訊時代前的資本主義中，價值的產生來自三個要素：土地，勞動，資本 - 參見亞當斯密國富論。然而在資訊時代，絕大部分的人都知道，員工(也就是勞動力)，是最最能夠產生價值的地方。換言之，只要找到最厲害的團隊，就可以幫企業做出做適合的產品與服務，並最能產生獲利。

但是，簡單的路難行。

在壹週刊有一篇容易的路最難行中，黎老闆描述了早在40-50年前，即便是一個成衣小工廠，人才仍然是獲利的最高因素。即便付出比別人高3倍的薪資也值得。但是，簡單的路難行，即便全世界都知道簡單的道理，可是執行起來實在太難。

大致有三個原因(特別是在台灣)

大型企業敘薪

台灣大型企業的都有薪資結構，對於已經有工作經驗的人，不太可能提供比過去多25%以上的薪資。就算這個人過去已經證明是難得的人才，也很難以「倍數」成長，頂多是以「百分比」加上激勵獎金成長。

小型新創企業資金不足

這應該很容易理解。和壹週刊黎老闆的文章一樣，小公司為求生存，不得不盡可能壓低薪資（改用夢想股票激勵）。然而，壓低薪資會導致於找到「人力」而非取得「人才」。這變成惡性循環，小公司變得更難獲利。要突破困境，恐怕企業主必須要有決心和毅力維持「難行之路」。請參考黎老闆的這篇。

CP值的誤用

CP值用在買東西是很合理。用在專業人才的工作績效是非常扭曲的作法。例如，兩個很爛的程式設計師，其薪水加起來跟一個好的程式設計師一樣。甚至，做一些簡單的工作也跟優秀的程式設計師差不多。然而，遇到複雜，開創性的工作時，三個臭皮匠很難贏過一個諸葛亮。

解決之道？

如果你是新創公司的企業主。建議看一下黎老闆的「一個創業者的道白」系列文章。非常有啟發性。

如果你是大企業的主管，畢竟已經受組織本身的限制，能做的事情稍微受限，但只要緊記一件事情，一定會有所幫助

激勵方式：主管對於團隊成員的真正最好的激勵方式，是找到讓團隊成員能自己激勵的方式。

(這段話節錄自 Work Happy 一書，作者為Jill Geisler)

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

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

不管什麼原因，當一個軟體工程師下定決心要換工作時(註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：當然不應該「窺探機密」，因此可以在一開始的時候先說「如果這個問題不小心牽涉到公司機密，請告訴我，在這個時間點我無意探究貴公司的機密」

企業巫醫 - 得罪老闆怎麼辦 (人際關係的過度重視)

得罪老闆（直屬主管）怎麼辦？

眾多企業巫醫都有不同的說法：

某一類型的企業巫醫以案例和經驗強調「如何不得罪老闆」，試圖就源頭解決問題。然而，大部分的作法，都是為了造就謹言慎行的員工。例如「得罪老闆的六宗罪」「別惹十種人」「與主管相處之道」「職場人緣學七招」。這些說的都沒錯，然而 - 除非是在超大型組織或者公家機關 - 職業生涯的發展，大部分還是取決於能力與實質貢獻，有效溝通與人際關係是其中重要的一環，而非全部。

有很多企業巫醫都會引用這段不實謠言「卡內基美隆大學曾針對畢業的 200 位傑出校友進行一份問卷調查，結果發現，成功的重要因素裡，其中85%來自一個人的態度包括自信、熱忱、領導、溝通以及人際關係的能力，另外的15%才是專業知識。」作為開場白，似乎再再強調人際關係的重要。更隱含著，只要有好的人際關係，就解決了85%的問題。

隨意引用未經實證的事情，是企業巫醫的共同特徵。就如同在部落驅邪一樣，告訴群眾，根據某某以前的巫醫說法，現在就是獻祭品用樹枝鞭打驅邪治病的好時機。

大概也是這個問題太典型，可是真實研究內容又和各企業巫醫所引用的有所出入。因而，卡內基大學的官方Q&A只列出問題，但是並沒有直接說明答案，只說這是1918年某期刊登載之研究，但是太久之前了，請自己去圖書館找（參考這裡）。

在此特別感謝google的paper search 學術搜尋，很快的根據年份跟名稱，找到該研究發表的地方(參考這裡，請直接看106至108頁) 

實際情況是：

(1) 該研究並非針對200個傑出校友，甚至根本也不是針對特定學校的校友。研究對象為美國工程師，實際樣本超過7000人。

(2) 該研究，是以問卷形式，將因素是工程師升遷的重要條件分成六組(Character, Judgment, Efficiency, Understanding of Men, Knowledge, Technique)。結果，認為Character人格特質那組條件，是升遷第一重要依據的人數，是其他組的七倍。 眾多企業巫醫所引用85%，應該引用此依據，再經過時間以訛傳訛的結果。

(3) 該研究開宗明義的指出在1900前後，美國的工程師教育問題，認為過於著重技術教育，而在工程教育體系缺乏對人格特質的強化。然而！該研究的人格特質定義乃是指

「common sense, integrity, resourcefulness, initiative, tact, thoroughness, accuracy, efficiency, and understanding of men 」(註1)

光看字眼，也能夠體會到1918年 - 畢竟已經快100年前 - 和今日一般企業巫醫所指的「人際關係」有很大差異。例如：完整，正確，有效率，在現代社會通常是技術的一環，而較少列入人格特質的一環。

過度強調「職場成功85%要靠人際關係」就會讓「得罪老闆該怎麼辦」變成落在自己身上最痛苦的事情。因為，得罪老闆之後就會有「已經失敗了85%」的不實感受。

那麼，已經得罪老闆之後該怎麼辦？和處理問題的基本「事實三步驟」一樣：

(1) 確立事實

(a) 你的市場價值有多少？

必須要取得客觀的事實，而非自己心裡的感想。每個人都認為自己對組織可以產生很多價值，但事實上可能不然。最簡單的方式就是「試著去面試找工作」。在此m，並非鼓勵以換工作解決問題，而是以「測試自己的市場價值」來決定個人價值。如果在3-4個月內，無法找到比現在工作整體薪資高出10%的工作，那麼其實你現在在組織內部的價值是被高估。


其實不管有沒有得罪老闆，只要你受僱者，不是自己開公司當老闆，就應該要確定自己的市場價值。這是最重要最重要最重要，需要知道的事實。也是最大唯一根據。

(b) 得罪的原因是做了錯事，還是只是個性不合接連產生誤解，還是遇到一個糟糕的老闆？

也很有可能你永遠無法知道原因，不過如果有機會知道會比較好。

(c) 職業生涯的目標

(d) 對老闆的依賴程度

(e)...還有很多其他事實

(2) 建立選項

得罪老闆既然為既定事實，就要考慮「應該怎麼做」的選項。在完全被動情況下，人會有無限的壓力，選擇的權力讓有掌控感(不過太多選項也是壓力，參考 註2)。

無論如何，至少給自己產生3個應變選項，以下是一些選項參考。了解或者建立選項，並非一定要做，而是要給自己「清楚可見」的選擇機會。

(a) 不動作

每人都有機會得罪老闆，你不見得是唯一，也不見得是最重要的。不動作指的是不把它當一回事，繼續做好你該做的工作，繼續學習成長。

(b) 大幅提昇績效

如果你的工作績效清楚可見：要注意的是，清楚可見是指「其他人清楚可見」而非自己認為。那麼得罪老闆也並不是很重要的事情，因為你對組織的貢獻的本身，並不會得罪任何人。大幅提昇績效是可行的選項，不過前提是你「做得到才行」。既然你已經看到這篇文章，大概就隱含著這個選項短時間做不到。

(c) 組織內換部門

很多時候，你只是和老闆個性不合八字不合，在大組織內換個部門並非壞事。

(d) 換工作

換工作和內部轉移不太一樣。你必須把換工作當做「自己的選項」而非被動的選項。並且，不要欺騙自己。

有些人是在沒其他選擇的情況下，自己欺騙自己說「其實是我想換做工作」，這容易去找到一個勉強而不見得是自己喜歡的工作。換工作的選項在於，先確定自我價值，知道自己換工作可能犧牲的成本代價，然後視為眾多選項之一。當最後真的執行換工作選項時，在時間上和心態上就有很大的差距。

(e) 建立新技能範圍

自己開公司也屬於這個範圍。換言之，在維持現有工作績效的情況下，額外花時間開創可能性。

以資訊科技來說，主動舉辦workshop，參與opensource專案都可能是建立新技能範圍。然而，那怕是去取得水匠電工丙級執照也都是建立新技能範圍。(不建議直銷保險之類的工作)

(3) 執行選項

即便「不動作」，也是需要認知與執行。執行上有一些要件。

(a) 速度：除了不動作之外，其他的選項在「已經得罪老闆」的情況下，應該是要越快建立越好！

越快能建立選項，表示自己掌握了「時間」。不掌握時間的人，就容易被動的被時間掌握。當你覺得每天忙碌不堪，似乎被事情追著跑的時候，表示你需要先改善自己的時間掌握能力。

(b) 建立回饋方式：任何要執行的事項，必須要有自我檢查的方式確定執行的結果是否和預期一樣。因為執行結果有差異的時候，應該「儘速修正」。

(c) 符合最終目的：當得罪老闆這件事發生的時候，你的目的到底是什麼？

你希望「已經獲得老闆原諒了？」
還是「得罪這個老闆已經沒關係了？」
還是「得罪老闆所產生的後果已經最小化」
還是「....」

執行任何解決方式，必須要符合你本來的目的。這目的當然只有你需要知道，而不需讓那些無法幫你解決任何事情的巫醫當作他的「研究個案」或者「參考範例」使用。



參考文章：換工作的面試-軟體工程師如何展現價值

---

註1 ：節錄原文描述人格特質的「項目」，徵求比較好的翻譯
註2：然而，有許多研究顯示太多選擇也反而造成壓力，請參考這裡。

建立軟體開發團隊 (1) 計畫 組成

... of the 20,000 notable players for us to consider, I believe that there is a championship team of twenty-five people that we can afford, because everyone else in baseball undervalues them...(Moneyball 魔球)


軟體開發團隊的建立和運作，不可能有完美的狀況。但是，妥善的計劃，能大幅降低軟體團隊的運作風險，並且讓團隊成員專注於發揮專長和創意，減少不必要的浪費時間。

特別是浪費時間在於解決非技術性問題。


問題有可能來自各方面，例如：

(1) 目標極端困難。例如：要在3個月內完成類似AWS EC2的雲端運算平台。

(2) 目標不確定性極端的高。例如：團隊目的是要完成一個不知道誰簽訂的模糊合約。

(3) 團隊還沒組成，目標也還沒確認，就已經有時間壓力。例如：一個2-3個人合作的新創公司，剛剛獲取資金成立。

(4) 團隊的組成有時間壓力。例如：在大企業中，因為高層要求，一定要在某月某日找齊7個人組成團隊

(5) 團隊已經有部份是問題成員，在此同時還要因組織任務擴張而增加人力。

(6) 因為組織變動(例如企業改變目標，併購等等)，讓某個團隊大幅流失人才，而需要重整補齊人力。

(7) 因為文化與跨國合作困難，導致前期人力大幅流失而需要重整團隊。


負責組織團隊的人，最最基本的認知就是：

軟體團隊組成這件事情：本身一定會有困難與挑戰。不具備困難與挑戰的軟體團隊，其實沒有存在的必要。(註1)


以下三個步驟可以供組織團隊負責人參考：

(1) 了解探索事實，盡可能將事實攤在陽光下

許多新團隊一開始就建立在「各種假設」上。例如新創團隊「假設大家對Scrum都有相關經驗」，或者「假設在3個月後可以找到2個優秀的iOS開發人員」，或者「假設大部分的使用者都有fb的帳號」，或者「假設3個月內某個模組可以先行開發完成」。

在許多情況之下，很多事情的確有假設，才能進行下去。

但是，在建立團隊的時候，除了瞭解背景假設之外，先確認事實才重要。

以下事情必須要儘早確立。

(a) 團隊目標願景：

可參考下節「確切定義短期中期目標」。如果是非營利組織，團隊願景就非常重要。因為這可能是召集成立團隊的最大動力。一般企業，營利組織，除了獲利之外，也可能會伴隨其他更遠大的目的。例如：「讓人類可以移民火星」之類的(註2)。

一個有崇高理想的非營利團體，也就不應該將盈餘拿來作為績效獎金。而是以團隊能達到的願景作為激勵人心的最大方式。(例如Kiva)

相對的，如果只是單單純純想賺大錢的公司，例如某東南亞賭場在台灣的軟體部門。也就不需要唬爛一個崇高的偉大目的，就只要讓團隊了解「大家來歡喜寫程式賺錢吧」即可。因為有正確的認知，才能集合正確的團隊。一個誠實的宣稱「大家來寫程式賺錢吧」的團隊，自然不會將社會責任活動當作是團隊成員想要做的事(例如：到沙灘撿垃圾，協助獨居老人)，當然「培育企業人才」也不太需要，甚至Scrum裡面的「自己選取task來做」也根本不用，採用由上而下的軍隊式管理，讓工作以最有效率的方式完成，才是這種團隊的最好方式。


(b) 資源現況：

目前的現況是不可否認的事實，但許多人一開始的時候，會將現況和未來的希望混為一談。在此時此刻擁有的資源就是現況。

例如：現在有1個專案經理，以及1個剛剛到職的工程師，未來可以找10個人。...這就是資源現況。

但也有可能是：現在有1個專案經理，以及1個剛剛到職的工程師，未來可以找10個人，但是辦公室座位目前只有4個空位。...這也是資源現況。

更有可能是：現在有1個專案經理，以及1個剛剛到職的工程師，未來可以找10個人，但是辦公室座位目前只有4個空位。而團隊目前總薪資預算為1千萬台幣，其中還得包含筆記型電腦採用費用。扣掉已經到職的兩個人，年預算只剩下600萬台幣，所以可以找10個人，但是平均年薪只能為60萬，或者找6個人，平均年薪為100萬。...這也是資源現況。

作為一個建立並組織團隊的人，資源現況的瞭解和掌握，必須要越清楚越細節越好。實際上，絕大部分的情況下，只要稍微多花個幾個小時，就可以掌握到很多現況細節。


(c) 組成專長：

即使已經是軟體開發的專家，這仍然是一件需要擔心的事情。

如果團隊的短中期目標確定，組合的專長可能大致確認。然而，某些專長不見得是「團隊成員需要有的」，這些專長可能可以用「短期購買」取得。

團隊領導者在取得事實的階段，需要清晰可見的專長分佈圖。

以上圖為例：簡單地列出做一個購物網站可能需要的專長，並且也把目前團隊已經擁有的人才能力列在其上。未來在組合團隊時候就比較容易考慮周詳。

要注意的是，這樣的圖並不是要完全技術上正確，而是要做為未來計畫的參考。因此有可能一再修改，也不見得需要用了不起的繪圖軟體製作。


(d) 關鍵成功因素：

哪件事情做好了，會讓這個團隊成功。成功關鍵因素應該只有1-3個，不應該太多。 這個關鍵成功因素必須要很「實際」，能夠被「衡量」，當然也必須要是能「達成」。至於困難不困難就不一定。以xspace的火箭設計為例，他的關鍵成功因素不只是火箭能發射，還要能「掉回地球後，能自己站立，以便低成本回收」。

軟體開發團隊的「建立組成」的通常是願景能否達成的關鍵成功因素。然而，建立組成的本身也有關鍵成功因素。例如，在2個月內吸引3個具有5年工作經驗，並且容易合作的工程師到職。



....其他需要搜集以及展現的事實還有不少。完整清單請參考(註3)。當然，不可能花幾百天的時間，只是為了收集事實，只要在合理的時間內，盡量收集了解重要的事實。

(2) 確切定義短期中期目標

前段所述的事實如果了解的夠完整。定義短期中期目標就很簡單。

短期目標是1週到4週內「必須」完成的事情。中期目標則必須要能夠「完成一項的關鍵成功因素」。

以建構軟體團隊而言，八九個短期目標完成後，差不多就等於一個中期目標完成。

任何軟體開發計畫，必定會有目標，而讓團隊朝向「同一個方向」前進。所謂團隊，當然是一群人往同一個方向前進，才能叫做團隊。一群在同一個組織架構的人，或者在同一個老闆底下工作的人，不見得是一個團隊，很有可能每個人在軟體開發

(3) 根據目標擬定計劃和備用計畫- Plan B

兵法有云「夫未戰而廟算勝者，得算多也；未戰而廟算不勝者，得算少也。多算勝，少算不勝，而況無算乎！吾以此觀之，勝負見矣。」

計劃本身並不重要，但是做計畫這件事情很重要。

計劃要達到的目的要非常清楚。而且必須「至少」包含兩件事情！

*** 達到短中期目標的做法 
*** 實質建立工作環境與實際做法

建立軟體開發團隊的初始計畫至少需要涵蓋以下內容：

(a) 團隊目的，短中期目標

....請參考前兩段...

(b) 團隊組成

需要哪些專長的人在這個團隊。更重要的是，哪些技術背景的人的組成最適合這個團隊。最好的方式是將所需要的「實質技術能力」清楚地列個圖示，根據分佈圖，來劃分團隊組成。

切勿用想像的方式。

以上圖為例：這是一個打算建立電商網站的技術分布圖，和目前團隊成員(四個人)所擁有的技術連結。可以很清楚的看到哪些領域還沒有適當專長的人。也可以清楚地展示，團隊目前組成和未來最需要的地方。

這個草圖並非正確的描繪出細節，而且也把技術不相干的東西納入（例如裡面有個API doc，其實是還沒有去做的事情）。但整件事情的精神在於「視覺化」。透過視覺化，對團隊的變化才有整體性的考量和規劃，而不會落於枝節上。


(c) 團隊運作原則

近年來流行Agile的Scrum方式。可以參考這裡。


(d) 初始化工作項目

當團隊的成員是逐漸到職，最初的工作項目是能夠讓團隊快速形成共勢。這看似枝微末節，但是是隱含的關鍵成功因素。

初始化工作項目，在新成員到職的前幾天，最好是鉅細彌遺。規劃了新成員第一天到第五天，「每天」要做的事情和達成的結果。並規劃前4週，要達到的大項目，以及前3個月的必須要的貢獻程度。

團隊是由一個個單一個人組合起來。將個別成員的適應期縮得越短，對團隊的組成越有利。

規劃前五天的細目，絕對不會讓這個新成員變得沒有創意，也絕對不會扼殺他的潛能。反而是讓他可以在極短的時間之內，先擺脫掉和「智慧創意」無關的邊緣事項。因為這些邊緣事項，如果在前一段時間沒有擺脫，之後會一直出來煩大家。

以下是某個電商開發團隊的前三天初始化工作項目，同時也是檢閱清單：

Day-1  
    - Mentor介紹工作環境，取得電腦和其他硬體設備
    - Mentor協助取得email和其他必要的帳號
    - 取得目前程式碼版本控制系統權限，確定可以clone
    - 確定clone目前的程式庫

Day-2
    - 取得目前的UI/UX設計文件，Mentor協助了解文件內容
    - 參加Scrum會議，理解Scrum雞與豬的原則 
    - 在Mentor協助下，建立自己開發環境

Day-3
    - 在Mentor的協助下，在自己的開發環境確定能修改程式/簽入(commit)/建立branch，最後產生自己的build。
    - 了解基本的測試項目

以上僅是3天的範例，這些看似細節，但要在三天之內完成也不並容易。


(e) 定期檢討方式

檢討方式可以參考這裡和這裡。

簡而言之，建立團隊的過程也需要被檢討。

例如：

新加入的成員，在當初面試的時候所呈現的能力，和實際上工作的產出，是否吻合。

新的成員對於非技術類型的雜事，是不是很快能找到資訊。例如git的位置，目前各個branch的狀況，自動化建構的方式，建立開發環境的方式等等。

---

註1：如果這個挑戰對負責組織團隊的人來說太過困難，最好不要接受這樣的任務。一個失職的程式設計師頂多讓專案推遲幾天，或者品質降低一些；但是一個失職的領導者，會讓整件專案崩壞。


註2：例如xspace

註3：建立軟體開發團隊的事實搜集清單

(a) 團隊目標願景
(b) 資源現況
(c) 組成專長
(d) 關鍵成功因素
(e) 關鍵風險 - 一旦發生就可能會失敗
(f) 關鍵技術 - 是否有必須具備的關鍵技術，需不需要招募這樣的人才
(g) 利害關係人 - 哪些人跟這個團隊有實質的相關
(h) 外在環境 - 辦公室設備 是否有遠端甚至跨國合作團隊等等

企業巫醫 - 誰掌握你的升遷？

只有自己掌握了自己的命運。沒有別人。(註1)

升遷也不例外。只有自己掌握自己的升遷，沒有別人。

大部分無法獲得升遷的理由，都只是自己的藉口而已。常見藉口(註2)如下：

- 自己的努力沒被別人及主管看到
- 受到主管不公平的對待
- 主管不賞識甚至打壓
- 組織內制度有很多問題
- 負責的工作實在太艱難資源又少
- 負責的工作實在太簡單沒有挑戰性
- 景氣不好公司不賺錢就罷了，還在裁員
- 比我資深的還很多，很難輪到我


在大組織裡，個人升遷(promotion)仍然是職業生涯重要考量。因而，企業巫醫們的一些闡釋也頗有道理，例如這篇，或者這篇。但有些過於偏激，而且會舉一些憑自己想像的例子。這類型的巫醫頗多，在google上搜尋"升遷"就可以找到不少。


那麼，自己要如何掌握自己的升遷？

超乎期待：做出超越目前工作職掌的成績

升遷指的是企業組織認為你可以「增加」工作範圍或內容。而要讓企業組織，或者主管，要認定你可以承擔更大的工作範圍，最好的方式就是你「已經」做出超越目前工作職掌的成績。

超越工作職掌的方向有兩種，這兩種和雙因子理論/激勵保健理論(參考激勵保健理論)的概念相同。

方向一：保健因素

保健因素指的是，沒達成會有負面影響，但是有達成，且做得再好也不會是超越工作職掌的事情。換言之，有絕對的必要性，但是超過也沒有意義。

例如：

作為員工，準時參與會議，準時上班，按組織規定請假。
作為一個程式設計師，準時交付符合品質的程式碼。
作為客服人員，在時間內回復顧客問題。
作為專案主管，讓控制並管理團隊時程，沒有延誤

有些是屬於規定類型，有些是屬於職務範圍。這些都是歸類於保健因素。換言之「沒做到」是非常糟糕的！非但不用考慮升遷，甚至應該擔心被資遣。

要注意的是兩種對保健因素的誤解：

(a) 誤解一：消極應對

既然這並非升遷，或者有額外價值的項目，那麼也許我就做的勉強符合，60分就好。這樣的心態會讓這些的保健因素，很快的變成你自己的風險。保健因素的最佳處理方式是採用cynefin模型的「簡單因果」類型工作的處理方式。以最佳化，(或自動化)的方式處理。

消極應對，只會讓保健因素變得個人缺點，得不償失！

(b) 誤解二：這不是保健因素

在智慧型職業(例如程式設計師)最常出現的誤解是「這工作不是保健因素，我做到這件事情就是超乎期待」。

事實上，絕大部分的由上而下指派的任務，幾乎都屬於保健因素任務。

例如，你負責撰寫android app任務，根據自己的努力，確實在規範的時程內，以規範的品質上架完成。這「本來就是」你的任務。完成這件任務，的確是好事，但如果沒有做出超越任務的範圍，那就是預期內的職掌。既然是預期內的職掌，當然會取得預期內的「報酬」，例如薪水。自然也不會取得「額外」的報酬，例如鉅額加薪或升遷。

試想，你搭計程車，司機在合理的時間內，安全的把你載送到你要求的地點。你自然會付出正確的車資，不太可能付出「額外」的費用吧。

方向二：激勵因素

如果有做到，會讓人感到「很滿意」。

這個方向並不容易，但其實是「最能自己掌握自己升遷」的真正方式。

激勵因素根據工作內容而有所不同。以前述的搭乘計程車為例，如果計程車司機在車上「額外」提供一般計程車不會有的卡拉ok服務，並且未要求額外收費，在你開心的抵達要求的地點時，非常有可能自願的拿出額外報酬。

智慧型職業比較難找到激勵因素的方向。有幾個尋找方式可供參考：

(a) 參考方式一：擴增保健因素

這個方式比較基本。例如：一個app的程式設計師，被要求在6個月內完成app並上架，結果在5個月就完成，並且其品質也在要求的範圍內。對企業組織來說這個事件就算合理的「激勵因素」

(b) 參考方式二：額外的相關支援

類似計程車卡拉ok。例如：android app程式設計師，被要求在6個月內完成app上架。結果的確在時間內完成。並且，由於他採用react native，竟然也順便完成了iOS app。這就是額外的支援項目。

(c) 參考方式三：擴大 

主動執行擴大職掌範圍的任務。例如app程式設計師，其任務是開發app並上架，如果主動協助開發伺服器端，或其他功能模組，就算是擴大範圍。

更顯著的例子是：app程式設計師，其任務是開發app並上架，但主動組織團隊，做出新的實驗性質的計畫。那的確證實了擴大職掌和展示了領導潛力。

其他：

離開組織，以及自己建立組織-創業。 也是都是合理「自我升遷」的方式。

當然，離開組織之前，要先確定問題不在自己身上。如果問題出自自己身上 - 無論是能力或溝通問題 - 換到其他地方，也不可能解決問題，只是碰運氣而已。參考這篇，或者這篇，或者這篇。

創業是自己造成升遷的最簡單方式。在那一夕之間，你就變成董事長兼CEO了。然而，能不能生存並獲利，又是另外一回事。創業需要另一方面的能力與知識。要成功並不容易，參考這裡，與這裡。

---

註1：在某些地區，某些情況下，當然有不得已的時候。例如，如果你是生在阿富汗，伊拉克，索馬利亞等國家，確實很難掌握自己的命運。所以，本篇指的是一般在台灣的普通上班族。

註2：為什麼這些是藉口？請參考說明如下：

-- 自己的努力沒被別人及主管看到
-- 受到主管不公平的對待
-- 主管不賞識甚至打壓

(a) 短時間或許有可能自己的努力不被發現，甚至可能被瓢竊或者搶功勞。但長時間不可能！而且事實上，如果你真的能力極佳努力也夠，僅只是沒被看到而已？那你應該很容易可以找到更好，並且更容易看到你的能力和產出的地方！

(b) 爛主管的確有可能打壓好員工，但沒有人強迫你為某個主管工作，你當然可以離開。但是在離開之前，請先參考這本書(我愛白痴老闆)。也可以參考（得罪老闆怎麼辦）


-- 組織內制度有很多問題

(a) 大企業制度上不可能完美，因為制度目的通常是為了企業生存。只要企業符合法律規範(在台灣是勞基法)就沒什麼好抱怨。並且，適應制度也是能力的一環。當然你也可以自創一個擁有好制度的組織。


-- 負責的工作實在太艱難資源又少

(a) 如果你覺得能力不足負擔這個工作，那不升遷的確是合理
(b) 如果工作真的太難，那應該自己去換個簡單的工作
(c) 所有企業組織的資源都是缺乏的，資源缺乏不是問題，只是現實

-- 負責的工作實在太簡單沒有挑戰性

(a) 如果你覺得工作太簡單，可能是因為主管覺得你無法負擔更重要的工作
(b) 也有可能對你來說工作太簡單，但是對主管來說你沒把簡單的工作做好，以致於無法給你有挑戰性的工作


-- 景氣不好公司不賺錢就罷了，還在裁員
-- 比我資深的還很多，很難輪到我

(a) 如果升遷是你最重要的考量，應該離開這類型的工作環境

軟體專案的現實：解決人的問題

無論是否採用agile的開發方式，所有軟體專案，最大問題的來源都是人。

人的問題，通常會極現實的影響專案的進行。然而，妥善運用agile的精神和Scrum的方法，有機會讓人的問題降到某個程度。

某個朋友，姑且稱為K，在專案扮演專案經理的角色，遇到以下狀況：

我最近有遇到一個問題，不知道怎麼辦，下面的人一直做不到我的要求，或者動作很慢，即便壓日期給他，他還是沒辦法達到，但實際上它任務並不多，只是開test case，我不太知道怎樣push他，我又不想來硬...他只有這個任務 平常又常常看他在上facebook, line....覺得要當一個讓人喜歡的lead真的蠻難的....


這個問題非常典型。

以敏捷開發(agile)來說，解決方式似乎也很簡單。首先專注於優先項目，接下來根據事實檢視工作，最後才考慮能力問題。

一：專注於優先項目

每個人在Sprint之中一定有正在執行的項目。確保每個人都是「專注」於目前最優先的項目是Scrum master最基本的任務。

即便不是採用Scrum也一樣。團隊成員必然在某個時間點有一個特定任務。專案經理或領導者(leader)當然必須確保，在這個時間點他只會專注在這個工作任務上。

對於剛剛成立的團隊來說，要確保團隊成員專注於目前任務上的方式很簡單：就是腳踏實地的「問」。在該成員一來辦公室的時候，就坐到他座位旁，親切的詢問他昨天早上在做哪些事情，昨天下午在做哪些，並實際上「看」到做的結果。就可以確定他是否專注，而能確定是否做到真正的效果。

整個詢問的重點都是在了解事實，而不是監督細節。因此每天頂多也只針對「需要幫忙的成員」，一起坐著看實際上的狀況。

二：工作檢視

以Scrum而言，每天的會議(無論是不是站著)就是為了統一工作情況檢視。完成就是完成，沒有完成即便是已經達到99%也一樣是沒有完成。當然，前提是在Scrum開始時有定義「什麼叫做完成」 - Definition of Done。

如果不是採用Scrum，則應該盡可能在團隊開始時，就先定義何謂「完成」。

以開test case為例，完成是指把要做的功能的test case詳述在某個測試文件管理系統上？還是只要先用excel或者wiki列出來即可？test case完成後是否要先讓團隊成員審閱，看看有沒有問題？要不要先估計每個test case執行會花的時間？test case的前置作業 - 例如建立測試資料等等，是不是也要涵蓋在其中？

當有完整的工作完成定義之後，要讓負責進行工作的人「決定時間」，而非「被決定時間」。

以軟體專案而言，任何超過2天的工作項目(task)，都應該分階段完成。畢竟，就事實而言，一個人不可能「連續工作2天」，每天一定會停住工作，下班回家。而這些階段應該要有階段產出。以test case而言，假設有10個新的user story需要建立test case，則今天完成了4個，表示還有60%尚未完成。

三：能力分配

如果團隊成員的確很專注於工作，而且也對時間/產出有正確的體認。最後的問題就是「能力問題」

團隊成員的能力組成其實非常複雜而且麻煩，牽涉範圍廣。以軟體專案而言，能力並非只是撰寫程式，測試程式，理解規格等等。能否和其他人合作，也是能力的一環。

一個規模中等的軟體開發團隊(4-7人)，如果有一個人的能力「極端」的差，確實會造成專案很大的問題。

在Scrum的情況下，這樣的問題在前兩三個Sprint應該就可以被控制。因為雖然他的產出差很多，但未來的sprint的進度，是以團隊能力來考量，因此Scrum master仍然可以有效掌握專案產出和進度。

在不是Scrum的情況下，可以先找到該成員的相對優勢。排定一些學習項目，來提昇該成員在這個專案中的相對優勢，並且在未來安排相對優勢的工作。值得一提的是，根據經濟學的「比較利益法則」，每個人一定會有所謂相對優勢：請參考這裡，和這裡。

關於軟體開發團隊的個別能力，還需要注意以下幾點：

1. 每個人都會成長，但是....

每個人都會成長學習新知識和能力。但是！在中短期專案裡，必須先考慮個別能力與優勢。

換言之，團隊領導要像下象棋一樣，找到每個人的「專長」，能妥善組合專案，就是個好的領導者。

而差強人意的領導者，則是常常試圖規避個別成員的「缺點」，這樣比較不會出大問題，但也容易產生差強人意的結果。而最糟糕的領導者，則會把人當做圍棋，看到人非黑即白，見到專案漏洞時，看到有空閒的人就直接填塞。這在某些有數百個人的硬體專案或許可行(因為數量在此可以產生品質)，但在軟體開發專案鐵定行不通。

2. 能力是綜合考量...

能力必須綜合考量「全方面」：例如是否好溝通，是否能處理複雜的設計問題，能否開放心胸的就事論事等等。不能僅僅考慮寫程式的能力。

另外，如果覺得整個開發團隊能力都很差。作為一個能自我思考的領導者，應該先思考自己是不是「問題的來源」，甚至要思考自己是不是根本不適合作為團隊領導。

3. 讓不適任的成員離開...

讓不適任的成員離開，某些時候是個可行的解決方案。特別是某些企業管理派別認為，投入時間在不適任的人身上，他有可能變得適任，也有可能不會改變，然而投入時間太多，會造成專案延誤。

以Scrum的角度來說，這個情況不太會發生，因為2-3個sprint之後團隊速度已經確立，無論適不適任，專案產出速度不太會再改變。因此剩下的問題僅在於「換個人會不會更好」。而以中短期(3-6個月)的軟體專案而言，讓破壞性的不適任者離開，當然是解決方式，但不見得要「找另一個人進來」。

---

相關文章：人才管理，心智圖，為自己工作...

企業巫醫 - 人才管理...人才根本無法被管理

任何能在企業講幾個小時的顧問，都一定會說「在組織中，人的問題最重要」

雖然這句話說的似乎很有道理，但是等同於廢話。這和「颱風明天會來，所以會刮風下雨」一樣，人盡皆知，說了等於沒說。

但是只要是軟性的課程，例如：成功主管的教練技巧之類。都會開宗明義的，告訴虛心向學的主管們，「人的問題很重要」，並且在接下來的8小時，展示一些似乎有用，但很難執行；或者幾乎沒用，但容易執行的技巧，來讓經理們主管們理解：「人的問題很重要 - 但是也實在太難  - 請自己好好體會，好好努力吧」。比較好的顧問，會拿自己豐富的失敗經驗(註1)，用作為警惕 - 這樣還算有價值。但只靠講話的顧問，就只能如同電視名嘴一樣，以幽默的方式打發大家的時間。

既然知道困難，也應該認知困難的地方，透過承認困難，踏實的因應困難，才能在人才培育與經營上找到對組織有用的創造性作法。

對於眾多企業巫醫來說，讓事情變得越複雜，越困難，越不能解決，自然就容易強化巫醫的效果，並且萬一巫醫的作法不靈驗的時候，也容易找到推卸的方式。畢竟，是惡靈不願意配合你的祈求，不是巫醫的錯。

如果你恰巧是資訊科技的主管：無論是軟體開發團隊經理，或者資訊部門主管，只要你負責「管理」團隊，則團隊的人才經營策略，應該會是你最先要考慮的。

無論組織有多大，無論你的職位有多小，無論人資部門的策略是什麼，無論工作壓力有多大，無論專案團隊所使用技術多神奇......無論任何理由，團隊的人才經營策略，應該是團隊主管首要考量的事情！

每個困難，作為負責管理人才的主管，都應該試圖做出合邏輯的，可執行，有創造力的解決方式：

困難一：區別人力與人才

人才之所以難管理，是因為「人才」根本無法被管理。「人力」才能被有效管理。

所有大型組織，很難真實區分人力跟人才。即便是做機械性動作的生產線員工，在效率和品質上仍然有極大的差別。從早期豐田Toyoto的全面品質管理(TQM)開始，到1999年許多人的智慧統整出精實製造(Lean Manufacturing)：揭示了一件明顯的事實：

「實際做事情的人，才是真正知道怎麼做的人」

但是，這個事實卻也隱含著另一件事情：

「在實際做事情的人之中，有些人才，才是真正知道怎麼做才好的人」


但人力跟人才很難區分。以資訊科技為例，任何可衡量的指標，都只能短暫有限的區分人力和人才的差別：無論是寫程式的速度品質，完成任務的完整度時間，程式維護的難易度，對新技術學習的速度等等。這些可衡量的指標，可以很快挑出老鼠屎，可以有效的找到連人力都不算的冗員，但卻很難在短時間裡認出千里馬。

把所有可找到的指標，綜合起來，確實比較可以找到潛在性的人才。但是所花的時間成本太高，而且利用指標的做法，很可能會無意間讓組織朝向「指標」前進，而非「目的」前進。

例如，以軟體專案為例，如果指標是「完成code行數」，配合「每千行code發現的bug比率」，則有可能會產生一個大而無用的系統，程式碼很長，而且根本不會被用 - 當然也不會有bug。

任何在人才策略上，所使用參考的指標，最好都是「隱性」指標，而且必須是簡單有用，常常可以反覆檢驗。例如，這個員工，過去12個月，曾經「主動」提出並且「實作」過哪些軟體專案重要的模組。或者，這個員工，在過去12個月，曾經「主動」做過哪些和軟體品質相關的事情。


此外，以過去的貢獻和產出為區分的標準：這在軟體產品開發上是一個稍微可行的做法。但是，所謂的過去貢獻，不應該是過去35年的貢獻和產出，頂多是過去3年的貢獻和產出。而也必須要確保，這些產出，能有效被歸屬。

舉例來說，一個軟體團隊有10個工程師，共同完成一個很了不起的產品，然而因為市場的關係，產品銷售不好，最後也停止銷售。這10個工程師，仍然擁有產出的貢獻歸屬。但是！這個軟體專案的專案經理，就應該承擔產品錯誤的責任歸屬。然而，由於大部分的產品經理都能言善道，因此，最常看到的是產品經理拿著過去失敗的經驗，拿來宣稱他「從錯誤中學習」，「得到寶貴的開發經驗」，更糟的是宣稱「產品的方向沒問題是公司策略改變」。

從錯誤中學習當然是寶貴的經驗，但是「必須真有學到，然後在爾後，因這些錯誤經驗而成功」。單只有「失敗的經驗」對未來毫無意義。請參考飛鼠裝跳傘(註2)。


在科技軟體產業，最踏實地的區分出人才的方式是：

(1) 面試時以情境實例面試法，了解他過去「做過的事情」，而不是未來「想要怎麼做事」

(2) 衡量工作情況是以「做出來的結果」，而不是以「講出來的結果」，當然也不是以待在公司時間長短，請假的多寡，發表的意見等等...

(3) 盡量試圖找出人才，而不是找天才。換言之，每個人都有某些能力和特性是組織所需要的，只要這個人可以把能力和特性「貢獻並且產生」出來，那麼他就是人才。反過來說，如果他會10種程式語言，還專精6種作業系統，並且還可以解決NP compete問題的難度。但是，卻因某些因素，沒辦法貢獻他的能力到組織或專案中，那麼他依然「不是人才」

困難二：培育或取得人才

資訊科技產業大部分都會宣稱自己很願意培養人才。少數倒是很誠實地說，他們想要直接用挖角取得人才 - 特別是最近幾年的中資企業。

由於培育人才表面上會遇到「培育後被人挖角」的風險。並且，取得人才，表面上通常能在比較短的時間，開始貢獻到企業。因此，許多在成本上沒有限制太多的企業，對於中階人才使用直接取得，也就是挖角，的機會越來越大。

這兩者都有很大的困難，但就資訊科技的角度而言，無論打算培育，或者直接到人才市場找到最適當的人，都不可能避免要「人才培育」。

資訊科技人才無法由人力資源部門統籌培育，必須要由技術性的部門執行，但是技術性的部門卻不見得有空，也不見得會知道重要性。

因此，常見情況是：「我們是on job training，有問題盡量問」。

代表事實就是：「我們不會，也沒有時間訓練你，將工作交給你之後，你就要自己想辦法學習，並且搞定它，當然有問題資深的人如果有空就會回答你。過一段時間你能生存下來就是好員工」

這表示，這個組織對人才培育的策略是......沒有策略，完全看個人造化和運氣。當然，最後的組織在人才運用的結果也是看造化和運氣。

對於規模夠大的組織，其實是可以用所謂沒有策略的方式，因為人數夠多的情況下，某些人才常常能夠單靠自己的能力，脫穎而出。但是在這種情況下脫穎而出的人才，很容易就會被其他組織「取得」。

雖然人才培育很困難，但是比較腳踏實地的做法是：

(1) 對剛加入的人，無論資深還是資遣，根據組織的現況，給予1-3個月的足夠學習期間，訂立學習計畫，在還沒有正式給予任務之前，有對整個團隊，先有全盤性的了解。

(2) 對於已經在組織很久的人，盡可能就現有的專案，進行延伸學習，這個延伸學習不見得是要去上課，可以提供他們「考證照」的經費，讓他們透過「考證照」來主動學習。請謹記：考證照不見得要考很貴的，因為重點不是在於證照本身，而是在於學習。

困難三：薪資獎勵

對於白領技術人才而言，薪資獎勵難以取得真正效果。

首先，傳統的增強理論，對人才：完全沒用！完全沒用！完全沒用！

但是對人力或冗員倒是有些效果。但企業組織為了表面上的公平，通常會試圖制定一體適用的政策，因此，大部分的傳統企業，或多或少都會運用蘿蔔跟棍子。

薪資獎勵，無論有多驚人，都屬於保健因素。換言之，如果不滿意，就很難留住人才，但如果滿意了，也只是「錢有到位」如此而已，一旦不能滿足激勵因素，換言之就是「心委屈了」，仍然無法用薪資獎勵來留住人才。

但反過來說，用夢想，希望，成就，甚至改變人類的命運等等「自我實現」的理念來作為取代薪資獎勵，恐怕也絕對行不通，因為激勵因素和保健因素，兩者無法互相取代。參考：雙因子理論。

大型組織中的某部門，或者某團隊負責人，通常也無法對薪資有大幅改變的權力，頂多是在年度考核的時候，決定某個人加薪的多寡，或者紅利的多寡。薪資獎勵，對有足夠規模的公司而言，整體結構早就是固定的，第一線主管僅有調整的空間。因此即便可以透過薪資獎勵來激勵員工，也不可能巨幅調整。即便可以巨幅調整，也不可能長期滿足。

因此，資訊科技根本不可能用薪資獎勵的方式激勵人才，留下人才，讓人才持續對組織貢獻。

既然不可能，就要換別的方式：

無法用薪資激勵人才的解決方式：

(1) 選擇

提供選擇，或者讓團隊了解選擇。

早在2008年，Zappos就已經設立了離職獎金。讓想要離開的員工，更容易選擇離開。因為，一個勉強留下工作的人才，肯定不會認真付出，他就會成一個人力，更慘的是會變成冗員。而組織要花更多的時間成本。

在台灣作為第一線主管，大概很難說服人力資源部門執行這麼激進的作法。但是，在職權範圍之內，可以清楚的告訴成員，離開組織是一個選擇，當然很歡迎你做出「貢獻」組織的選擇。大部分的人才，在被鼓勵自由選擇的情況下，一旦做出留下的選擇，其貢獻一定會是「人才」的貢獻。

這也不是什麼新鮮事。

從1945-1962年間，不斷重複進行蠟燭實驗。到最近一本很紅的書：如何讓馬飛起來，之中提到的Amabile所做的獎勵 vs 選擇研究。都不斷指出，有創造性的工作，在事先已經知道有獎勵的情況下，其實績效比較差。

以下摘錄自「如何讓馬飛起來」一書：

60名大學生，他們將參加一項人格測驗才能拿到學分，測驗過程中，研究人員假裝錄影機壞了，無法繼續進行。然後她告訴其中一組，稱為「無選擇─無獎賞」組，他們必須完成拼貼畫來代替測驗。另一組「無選擇─有獎賞」，必須完成拼貼畫，但是可以得到2美元。詢問第三組「有選擇─無獎賞」，是否可以做一幅拼貼畫，但沒有任何獎金。再問第四組「有選擇─有獎賞」，是否願意做一幅拼貼畫，拿2美元獎金。為了加強獎金效果，她在獎賞組創作時，把兩張紙鈔放在他們面前。最後全部的作品由一組專家進行評審。這次實驗裡，獎賞果真激發出最有創意的作品──來自「有選擇─有獎賞」組；但最沒有創意的作品，也與獎賞有關──來自「無選擇─有獎賞」組。沒有獎賞的兩組，得分在兩者之間。就創作而言，選擇改變了獎賞所扮演的角色。創意表現最差的那一組，問題顯而易見：他們感受到的壓力最多。

而「無選擇─有獎賞」，正是大部分上班族工作時的實際處境

但是，如果這個獎勵，是事先有選擇性的，也就是可以選擇，那麼績效會更好。文中所提到上班族工作的情況是，無選擇-有獎賞。

其實第一線主管，是有機會加以改變：只要坦然的羅列選擇，不斷的提醒團隊成員：「這是個全然自由的世界」，「你可以去你想要去的任何地方」，「我絕對不會阻止任何人離職，甚至會幫忙寫推薦信」，當然也要提醒：「我不想要任何人離開，在這個團隊我們會讓每個人有機會成長為人才」，「雖然我不能保證薪水，但我能保證你必有成長」

(2) 人才合作 vs 人力合作 

團隊如何合作，是主管最能影響團隊的事情之一。簡單的說，資訊科技團隊必須要能先考慮彼此優勢，透過發揮彼此長才合作；而不是考慮彼此的劣勢，透過避免發生問題的方式合作。

只要參考經濟學上的比較利益法則，找到團隊成員彼此間比較利益的優劣，就有機會讓大部分的人「變成」人才。

但如果在工作分派是以「剛好誰有空」這種區分方式，就會讓大部分的人變成「人力」。

(3) 成長優先 vs 產出優先

人才的成長培育優先，或者產出也就是績效優先？乍看之下是二選一的問題，其實是必須要獲得雙贏的問題。

請參見：工作太忙沒時間

作為第一線主管，必須要透過培訓以及帶領的方式，有效讓人才成長，透過人才成長，讓產出更有效率。

如果面臨二選一的情況，在短時間當然選最適合的。但是中期長的規劃，必須一定要能滿足兩者。

---

註1: 通常不太會有成功經驗的分享，因為在人才管理有真正成功經驗的人，很難有機會變成企管顧問。

註2: Franz Reichelt， 飛鼠裝的先驅，然而他過去的飛鼠裝實驗都沒成功過，就嘗試從艾菲爾鐵塔跳下，結果當然是...