如何用教練(coaching)的方式引導團隊成員

作為主管，帶領引導團隊朝組織期待的方向前進有很多種方式。其中，「教練式引導」針對特定團隊成員行為改善的其中一種方式。

主管對於團隊成員的引導方式大概有四大方向：教練coaching, 導師mentoring, 領導leading 與管理management。在軟體團隊中，領導與管理是主管一定會做的，而教練coach與導師mentor就會視團隊的實際情況而定。

管理management：簡單的說，是直接或間接以組織所賦予的權力，以具體的方法，要求成員達到結果或者某種行為。舉例來說：「某甲，明天早上十點請到會議室去和某乙討論某專案」就是個具體的管理作為

領導leading：簡單的說，以自己的行為加上組織賦予的權利，以身作則的達到團隊合作的結果。舉例來說：「某甲，我明天早上十點會到會議室去和某乙討論專案，一起和我去吧」

導師mentor：一般來說是比較有經驗的成員，在執行自身的任務的時候，順便分享給相對沒經驗的成員。也許會回答問題，也可能教導做法，或者也分享經驗。通常由主管指派資深成員做mentor，但主管也有可能自己作為mentor角色。導師通常會比學生更厲害或更有實質經驗

教練coaching：以「口說」或者「間接」的方式，激勵或指引成員達到具體的結果。這具體的結果，幾乎100%是有成員直接完成。教練不一定比學生更厲害或更有實質經驗，但通常會更有「口說教學」經驗。例如在世界排名頂尖的職業網球選手，都有雇用教練陪伴指引戰術與練球，但那些教練過去甚至不見得是職業網球選手。

角色區分有時候並不那麼重要。例如管理與領導常常是混合進行，而在軟體團隊中mentoring coaching 當然也常混用。更常發生的例子是，主管指派一個導師mentor給新進同仁時，實際上常常混合了leading/mentoring/coaching。混合並不是壞事情，但如果資深同事，可以透過區別自己的角色，進而使用不同的工具達到目的，那效果會更好！

這篇文章僅只專注於教練式引導。

教練式引導的基本方式: GROW

最最基本的教練式引導模型是Grow，它有四個循環的階段：

GROW: Goal, Reality, Options, Will (what)

目標Goal：

教練和學生要決定一個具體的目標。這個目標可以是組織需要的目標，也可以是學生個人的目標。目標必須是可清楚辨別結果的。例如，網球選手想在四大公開賽進入前四強。在學生剛加入團隊時，可能會訂出目標是「了解現在的系統」，這其實並非清楚可辨別的結果，教練應該和學生花時間，討論具體的結果，例如「根據現在bug清單，修好一個bug並送出Pull Request之後通過團隊所有其他成員的code review並且合併到master branch」。雖然一次可以訂多個目標，但建議還是少量目標為主。

現況Reality：

教練和學生列出和具體目標相關的現況。例如網球選手此時世界排名是200，過去平均多久打一次正式比賽，平均練習時間等等。

以軟體開發團隊來說，現況可能是剛剛加入團隊，才剛剛有git的權限，過去的文件還沒看完，對某些專業領域還不了解，還不知道哪些問題應該問哪些人等等。

現況的描述是相當私人化，對於某些人來說可能還先牽涉到部分自我敏感的資訊，尤其是自己弱點。在還沒有互信的時候，此階段執行要特別謹慎。

執行選項options

了解現況之後，教練就要和學生討論選擇做法。這些做法當然是「學生」要去做的。以網球教練為例，可能會建立心肺功能的健身菜單，也可能會安排練習賽，也可能會為了強化發球。通常可執行的選項會多過可用的時間。當然就要和學生討論哪些選項應該要做，那些不做。

軟體開發團隊也會設定這些選項，但更著重要選項的優先順序，也就是哪些要先做，那些之後再做。

意願will/what:

監控執行，特別是監控執行意願。一個剛加入團隊的新鮮人，初期在意願上通常不是太大問題。如果已經在社會打滾多年，因為換工作的關係加入一個新團隊，作為教練或主管，就要稍微留意一下是否有意願或者動機的喪失。

這GROW是個循環，教練不見得一定要告訴學生這個模型，如果可以說明清楚是最好。根據實際情況，循環的長度會有不同，可是軟體開發團隊中的教練應該盡量控制在1~2週之間，切勿太長。

教練的功能

GROW模型優點是相當簡單，容易理解。缺點是教練實質功能在這個模型比較隱晦。在執行此模型時，也可參考以下重要功能：

建立互信

建立互信是教練最最重要的功能，沒有互信的情況下，很難達到教練完全的功能。

軟體開發工作上的互信應該會比運動型的教練容易一些，只要執行以下三點：(a)自己保持清楚明確的溝通 (b)永遠花時間跟確保完整傾聽對方 (c) 固定時間回饋  通常就能有一定的互信

因材施教

在軟體開發團隊中，教練vs學生，通常是一對一。而每個學生的情況截然不同，因材施教是顯而易見要達到的。因材施教在非技術的領域比較難，最好的方式可能還是縮短GROW的循環時間，如此可以在短的時間修正互相之間的不了解。

建立安全網

運動類型的教練都有其專業能力，可以判斷目前學生是要突破肌耐力極限，還是快要受傷應該休息。甚至某些運動項目，例如體操，就還真的有實際上的"安全網"，因為受重大傷害絕對不會對目標有幫助。

就軟體開發團隊來說，安全網其實很重要，但相當隱晦。例如對於相對沒有工作經驗的人，教練應該在「現況討論」時，列出更細節的項目，例如估計時間的時候要估計完整的時間，包含unit test跟撰寫文件的時間。這些實質細節項目，其實會讓新鮮人更清楚並且有信心的做事。

安全網也有可能是透過工具，先行體驗犯錯，而減少日後在真實情況下犯錯的機會。例如，即便團隊沒有要求，教練也可以和學生討論使用某些靜態程式碼工具，在送出PR review先自己找看看有沒有顯而易見的問題。

建立安全網在某些時候是個極為重要的任務。一個教練要謹記，教練成功的原因，是因為學生成功了！不會有一種學生失敗了但是教練成功了的情況。因此安全網是個避免災難式失敗的保險方式。

鼓勵人心

真誠的鼓勵其實對大家都有幫助。尤其是在完成目標之後。因此目標的設定，最好是許多短期目標構成長期目標。舉例來說，如果網球選手的目標是進入四大賽的前四強，但目前世界排名還200，短期目標可能是先在最近的幾次三級比賽獲得冠軍。

軟體專案的目標甚至可以是逐日設定，所以鼓勵也可以逐日發生。所以當教練必然要花一些時間陪著學生。

時間分配

軟體團隊身兼教練的人，通常不會和運動類型的教練一樣是全職的工作。每個人在團隊都應該要有產出，兼職的教練也不例外，所以時間分配在學生的身上恐怕要特別注意。

最基本是要和主管討論時間分配。如果要不影響工作進度，一般的原則，每天15~20分鐘，再加上偶爾中午一起吃飯的時間就應該是上限。

這裡的15~20分鐘，指的當然是學生和教練一起執行檢討GROW模型的時間，並不包含假設教練身兼導師一起和學生工作的情況。

尋找外援

以有世界排名網球選手來說，年紀稍長的教練幾乎不可能跟他打練習賽，所以教練可能會透過自己的人脈（例如同個經紀公司）找到同等級的職業選手來打友誼賽。而更厲害的教練可以說服更高一級的選手來和自己的選手練習。

就軟體開發團隊來說，教練有可能比學生在專業領域還要厲害很多。然而也有可能由於教練資歷太深，反而對最近幾年的新的開發工具並不了解，教練也可以直接安排其他成員專門對某工具對學生直接教學。

其他教練模型

市面還是有很多不同的教練課程與書籍闡述不同的工具和模型。可以參考這裏 

新手主管的準備 - 2 (軟體主管的31堂課)

當新手主管認知到改變之後，更重要的當然就是準備應對改變。每個組織可以承受的改變時間長度不同，但越快能夠自主地以透明的時程提出改變計劃越好。計劃本身是可以隨著間改變的，因此，做這件事情的重點在於讓自己以及相關人等，對未來你打算要做的事情能有一致性以及能有差不多同樣的期望！

(1) 在幾小時之內，建立三個月時程表

當確定你會變成新手主管，假如你的主管已經幫你擬定好一個轉換計畫，那恭喜你，你自己遇到一個非常好的主管。應該詳細看過他的計畫，並且延伸出自己覺得該做的事情或者細節。

如果你手邊沒這樣的計畫，那麼最好在幾小時之內，趕快做出一份三個月的時程計畫，並且和你的主管討論計畫可行性。

為什麼需要在最短時間有三個月時程計畫？因為一旦你轉換了角色，你勢必會遇到很多新的事情，新的優先順序，而你的時間很快就會被佔滿。如果不能在一開始先有所規劃，一旦事情接踵而至，很容易就會落入被事情追趕的情況，屆時要重新調整只會事半功倍。

計畫內容至少要涵蓋：

a. 確切的轉換職稱的時間點，會用哪種方式公告。

b. 未來幾週內的哪些時間點約好和團隊成員1vs1會談，以及會談的基本內容。基本內容至少會有涵蓋，當你作為主管的時候，他們對你的期待，以及你對他們的期待。哪些具體事情是他們需要你馬上去做，哪些事情他們希望你不要做等等。

c. 跟自己的主管（無論自己會不會換主管)：至少每兩週約一個小時的時間討論你擔任新主管的後的進度 

d. 建構利害關係人的溝通方式(參見下一節)

e. 建立衡量團隊成員期待的方式(參見下下一節)

f. 列出在領導與管理層面上，自己還需要學習的地方。並且自主安排時間學習。如果列出不來，必須要和自己主管討論學習清單。

g. 固定時間檢討本計畫內容

(2) 建立利害關係人溝通方式

所謂利害關係人(stakeholder)就是跟自己成功息息相關的人，自己的主管和團隊成員，必然是在其中。但還有其他重要的人，例如主管的主管，產品經理(PM)或專案經理(PM)，其他研發或工程團隊的主管，公司其他部門，甚至客戶都有可能是利害關係人。

當然根據公司規模大小不同，利害關係人數量可能不太一樣。然而，就像所以事情都有重要/緊急程度不同，應該有不同方式以及不同時間順序處理。

利害關係人也一樣。請參見下圖：

簡單的說，互相之間工作決策影響程度，就是利害關係人彼此應該合作的方式。以第一型為例，如果互相都有巨幅影響，那麼互相參與實質工作就是你的第一要務。舉例來說，如果QA和RD分屬不同主管，你扮演QA主管的角色，那麼在同一個專案中，讓RD主管某種程度參與你的工作就會是你的管理利害關係人的成功因素。

又例如第二型，最常見的就是大公司的主管的主管，或者CEO，其實你現在的工作對他影響不大，但是他的任何決定，可能突然之間會對你的工作有巨幅影響。然而，花很多精神和時間去影響他也是不智的選擇，因為你也很有可能反而浪費時間沒有將精神和時間投入在工作本身。因此，定時通報現況，並用最短最少的時間讓他滿意你的現況，就是最好的管理方式。

(3) 建立衡量團隊成員期待的方式

團隊成員都對新主管有不同的期待。這件事情比，實際上比看起來還要麻煩。因為每個團隊成員對你的期待不同，會導致於，你很難有同一個方式對待所有人，如果不小心拿捏不同的方式，就會讓別人「覺得」你不公平。

最簡單的建立方式，就是透過1 on 1，直接詢問團隊成員對自己的期待，並且在每次1vs1的時候，了解自己有沒有達到他的期待。

但這個方法不保證有效，因為團隊組成的方式，團隊成員個別成熟度，以及新手主管對他們的了解程度，有很大的差異時，1 on 1需要一段時間才有效果。

很遺憾的是，這一點沒有最佳做法，只能根據團隊的不同來建立。

(4) 建立一致性

所謂的一致性，指的是其他人對你做事的理念有一致的感受。無論好或者壞。

嚴格上來說，人類自己會建立自己的一致性。說得更直白的就是人的個性和價值觀其實很難改變，然而，作為軟體主管卻要特別花心思，刻意建立某些事情的一致性。並以此為基礎，溝通許多困難的問題。

舉例來說，假設團隊都是資深工程師，也許你會想建立管理的一致性叫做「自主性透明，團隊合作優先」。

透明可以是：所有人寫的code都應該送出給大家review，所有技術性質的內容，都需要放在組織的wiki上或者是公開的文件管理中。任何非技術的討論當然可以私下進行，但是最終結果，和決定最終結果的方式，一定會放在公開的地方。

自主可以是：當任何人來詢問你問題，在你回答之前，你一定會詢問「那你覺得應該如何處理？」無論事情簡單與否。同時也可以是，交付任務會盡量以自願者優先。

團隊合作優先可以是：任何產出必須優先考慮可維護性，在任何時間點都要考慮一件事情是不是只有一個人會做。

簡單的說，只要對事情有一致性，你未來在複雜事情上就有一致性，這樣的一致性會讓所有人都覺得你容易合作並且也容易讓事情完成。

(5) 建立成功策略

最後，在這個新主管準備計畫中，會被歸納成幾個成功策略，並且在未來幾個月檢討策略執行情況，如果只是執行問題必須要堅守策略。如果策略不行，也要知道改換的方式。

每個人的成功策略不同，可能只是幾句話，也可能很複雜。無論如何，有策略不見得會成功，但沒策略幾乎保證會失敗。

例如，打算打造新團隊的策略可以是如下：

「打算招募已經有豐富經驗的人才加入團隊，希望團隊成員一開始就是會自動自發地搞定任務，並且也都容易合作，會自我學習。預期這樣的人可能是工作7年以上，並且招募的速度會拖慢很多，不過一旦找到適合的人，離職率也不會高。建構團隊我們打算不計成本得找到最好的人才，專案甚至為此延後6個月也在所不惜，因為一年之後，團隊會非常穩定而且也少有問題」

也可以是如下：

「打算自行培育人才，希望找有熱情，會自我學習，對軟體開發有基本知識的人。預計這樣的人可能剛畢業或者工作一兩年，招募速度應該蠻快的，只是新鮮人遇到挑戰可能離職率會很高，另外我們知道要預留學習時間，因此不會馬上上手。專案可能可以很快開始，但是中間的產出可能要看找人的運氣，6個月之後是能否穩定的關鍵期，一年之後預計會有個還可以合作的團隊，但可能會有管理上問題，成本可以控制在XXX萬元之內」

如果已有現成團隊，新手主管不需要建構團隊策略的話，還得建立自己的執行任務的成功策略。重點永遠在於，有計劃/策略會比沒有好太多！

新手主管的準備 - 1 (軟體主管的31堂課)

沒有時間嗎？可以直接看這個清單

沒有人生下來就知道如何作為一個領導者，軟體開發的主管也不例外，即便是資深厲害的主管也都會遇到第一次當主管的困難。

無論是什麼原因，當你有機會變成主管時，需要有意識的認知到，主管的責任和義務會跟你過去的工作截然不同。越快有這樣的認知，並且越快做好準備，你就越有機會成為一個好主管。反之，沒有這樣的認知並且也不做準備，就會有很大可能變成傳說中的壞老闆。

工作本質上的改變

以軟體開發的主管為例，在你變成主管的那一天開始，工作就有本質上的不同。無論之前是不是擔任團隊領導(team leader)的角色，作為主管之後，你的責任範圍就會自己擴大為「團隊」，並且近一步擴大到「其他團隊的互動」。

根據團隊的規模大小，在人數很少的團隊，主管也會進行實質工作，例如撰寫程式，測試等等。然而，工作本質上會讓主管必須要更關注「團隊其他成員」如何完成自己的工作。表面上，簡單的方法，是透過code review。實際上，更推薦新手主管至少每週要找一小段時間，直接坐在某些團隊成員的旁邊，和他一起pair programming。這並不只是兩個人一起看著同一個螢幕寫程式，同時也代表可以了解團隊成員是怎麼完成周邊任務，例如撰寫文件，撰寫測試，執行測試，檢查是否符合規格等等。

工作本質上的改變必須要真正被「實踐」。實踐的方式就是必須要認知時間的重新分配。

工作時間的分配

大部分的人會傾向做自己「喜歡」做的事情。很遺憾的是，如果新手主管只做自己喜歡的事情，那有很大的機會會造成團隊的失敗。

一般來說，新手主管至少每個月都要和團隊成員進行一次1vs1的懇談。至少每週要花1小時，重新檢查一次目前重要事項的進度，以及風險評估。至少每週要花一小時，和重要相關的其他團隊主管溝通。至少每週花一小時，和自己的主管溝通......這些零零總總之的「至少項目」，如果沒辦法有效進行，那麼會花上起碼1/3的工作時間，而且可能也達不到該有的較果。這也是為什麼許多新手主管看似忙得要死，但卻常有溝通問題。

時間，是軟體開發裡面，最需要被控制的資源，但也是最不容易被控制的。主管會比工程師更需要知道怎樣有效分配時間。

衡量成果的改變

作為新手主管，必須要認知到衡量自我成功的要素，會是團隊的成功。換言之，任何團隊的問題，無論是不是自己造成的，都會是自己的問題。誠所謂權力越大，責任也越大。

認知到衡量成果的改變，也代表你需要追蹤和關注的，不只是個人的產出，還會是團隊整體的產出。並且，規模團隊越大，個人產出會變得越不重要。舉個極端的例子：假設一個大型軟體產品開發團隊裡面，有前端工程師，後端工程師，手機app工程師，維運工程師等等，每個工程師小組表面上都按照標準完成任務，但是整合起來就是會有各種問題，那麼這仍然是個失敗的狀態，而軟體主管是這個失敗狀態的主要負責的人。

要做好資訊相關的主管任務，其實相當不容易，當至少有認知到以上的改變時，就可以開始進行準備工作(參見 新手主管的準備 - 2)。

如何成為主管 (軟體主管的31堂課)

一般資深的軟體工程師，或多或少都會有思考過也許自己可以當領導者- team leader, manager等等。

主管people manager的定義很簡單：就是有人直接對你報告，並且你負責直接管理團隊裡的人，包含考績評估，工作指派，以及，最差的情況下要解僱某人。

沒有人生下就會寫程式，當然，也不會有人生下來就會當主管。然而，和寫程式不同，主管很難事先「練習」。所以這就變成雞生蛋，蛋生雞的問題。

在組織趨向扁平的情況下，如果有心想要往主管方向前進，最好要做到以下三件事情：

自動擴大責任：

也就是，主動做跨出自己工作範圍的事情。這裡並不是指自告奮勇擔任福委會主委，或者安排一些團康活動，雖然這些對大企業來說也很重要，但如果時間有限，應該優先考慮：跨出自己工作範圍，但仍然還是在軟體開發工作的本質上。

這件事聽起來容易，但做起來相當難。尤其是資深的工程師常常手邊已經有忙不完的任務，自請擴大任務搞不好吃力又不討好。然而，這卻是成為主管的最必要且最實際的路。

要擴大責任範圍，最簡單的做法是先了解自己的主管現在在忙什麼，可以先幫他處理必要但是瑣碎的事情：例如，撰寫例行報告，安排會議，會議結束後的記錄和執行事項的追蹤，列出現在正在進行的風險控管等等。有些事項，表面上看似秘書類型的工作，實際上對掌握大局有相當大的幫助。

其次是針對雖然不在自己任務範圍，但是是很重要的技術事項，花額外時間的主動幫忙解決。在稍具規模的企業中，這種事情多如牛毛，問題只在於有沒有人有空去解決它。

尋找業界導師：

如果你覺得目前主管是個好主管，那麼可以主動要求他擔任你的導師(mentor)。其次是尋找在同公司中的其他主管，真的找不到再去尋求其他公司的主管。你所需要的導師最最最起碼要符合這些條件： (1). 工作經驗至少比你多5年。(2).至少在同一個組織裡有2.5年以上的管理經驗，(3).必須是樂觀進取的人。以上這三個是最低門檻，最佳的情況會是7~10年差距。超過13年可能會有反效果，最好要有數個成功的軟體專案經驗，起碼有10年以上的工作經驗，並且有至少雇用10人以及解雇人的經驗。

找一個自己的導師，聽起來難做起來相當簡單。重點在於只要去做就可以了。有幾個基本的事情要注意 (1) 誠懇地請求幫忙，並約定這幫忙的時間每週1小時而已，並也約定為期僅有6~24個月 (2) 不要一次找很多導師。一段時間(6~24個月)有一個導師即可 (3) 約好固定的諮商時間：每週30分鐘，或者，每兩週1小時都可以，聚焦於過去一兩週的實質問題的建議 (4) 誠摯的感謝和長遠的關係，比實質的利益來的重要太多，強烈不建議付補習費，遇到需要索取補習費的導師就表示你可能找錯人，但是每週的諮商時間，請杯咖啡之類的小事倒是可行。(5) 如果可以的話，最好是12個月以上，但如果可以的話也不要超過24個月

在工作上遇到的問題，尋求業界導師過去的類似經驗，是最佳的參考。

留在還不錯的公司：

這個世界上沒有完美的公司，每個企業組織都有好的地方和不好的地方。只要覺得自己現在的環境沒有特別糟糕，目前所在公司仍然願意投資資源在人才培育，自己的主管是可學習的對象，那麼應該起碼考慮未來3~5年留在同個組織發展。一般而言，內部升遷的機率是大於外部空降。尤其是，如果你現在還未曾擔任過主管職，從外面招募一個沒擔任過主管的人來當主管的機率微乎其微。

大部分的人，總有看到別人碗裡面肉比較大塊的感受。然而，一旦發現自己目前的主管非常糟糕，組織文化負面而且破碎，當然要儘速離開的好。

最後，如果連續數個公司都待不到2年，應該是要檢討自己，而非檢討環境。

管理能力是可學習的硬知識技能 (軟體主管的31堂課)

許多軟體部門主管之所以成為主管，是因為工作上技術能力表現良好，並且似乎也沒有團隊合作上的問題，因緣際會就成為帶人的主管。成為帶人主管(people manager)之後的技術人員，對於管理能力一開始通常不會有正確的認知。這其實很合理，畢竟領導與管理的工作和技術性質的工作有很大的不同。

其中認知差距最大的就是誤認管理能力是一種「軟技能」：需要有耐心，能夠團隊合作，能夠激勵大家，會看人臉色講話，能夠傾聽等等。然而，大部分的情況下，管理能力是一種「硬知識技能」(hard skills) 。換言之，管理能力是可以被有效學習，並可以被客觀評估的。

以英文能力為例，如果你想要當英文小說作家，那麼大部分的時候你需要具備軟技能，寫出能打動人心的故事，而且這樣的能力，沒辨法被有效評估，你對英文文法的了解以及考試分數，跟能不能寫出動人的小說根本沒關係。然而如果你是要能流利使用工作上的英文，那麼鐵定是屬於硬技能，現在社會上會以類似TOEIC的考試，客觀的評估你的商用英文能力。換言之，商用英文是一種硬技能，至少可以相對的被衡量：例如TOEIC 950分 和550分就很明顯的有差距，你大致相信TOEIC950的人有合理可商業溝通的英文能力，同時你也大致相信550分的人只能講簡單的對話。

既然管理能力是硬知識技能，那麼也就是可以被學習以及有效評估，應該用哪些具體的方式評估自己管理能力呢？每個組織情況可能略有不同，但是軟體開發類型的可以考慮以下方式：

(1) 360 survey或者匿名員工問卷評估員工士氣

可以參考這篇

(2) 過去12個月的離職比率

然而這需要內部與外部比較，也許組織離職率本來就高。

(3) 每次1vs1的獲得正面資訊的次數比率

這有點敖口，簡單的說就是記錄每次和團隊成員1vs1的時候，在對談中獲得團隊成員對組織的正面資訊的次數。

(4) 花在解決工作溝通問題的時間比率

當然是越低越好

(5) 臨時加班次數

當然也是越低越好‘

絕不犧牲品質 (軟體主管的31堂課)

無論是大型軟體公司，還是小新創公司，軟體主管常會面臨到時程壓力。畢竟快速交付產品並且到市場驗證，遠比花個數年慢慢搞出一個可能沒有市場的產品來的有用。速度絕對是成功的關鍵因素。再者，孫子兵法有云：兵聞拙速，未睹巧之久也。似乎都在說速度比任何事重要。

然而，做完軟體主管，唯一不能做的事情，就是犧牲品質，現在犧牲品質，下一個犧牲的就是自己和開發團隊，接下來就是公司本身。

兵聞拙速，未睹巧之久：指的是快速決定一個方向，並不指隨便打一場品質低的仗。品質低劣士兵前往戰場只有死路一條（或者只能期待對方更差）

為什麼不能犧牲品質？

(1)如果PM/Sales/BD說可以不再太在乎品質？我需要在乎品質嗎？

當然要在乎品質，事實上，負責任的人會是決定的人。當軟體出現問題的時候，難道PM會負責改code上patch？最終負責的人就是會真正感受到痛苦，並且付出代價的人。軟體品質有問題，會付出代價的一定是軟體開發團隊。其他人既然不能承擔代價，當然就不能決定品質。

(2) 這次改動範圍大，但是有環境上的時間限制deadline-driven的開發，難道我能說品質不好就不上線嗎？例如耶誕夜12/24要上線，無論如何耶誕節都會來，已經做得差不多了難道就不上線嗎？

品質是可以有範圍定義，畢竟不能可能期待大型系統完全沒有bug。但是，即便是有環境上時間限制，如果品質真得無法達到要求，上線只會讓事情變得更糟糕。最近的例子是7 pay，而我們其實可以輕而易舉地找到很多過去的例子。

那麼，為什麼還是會被「逼」上線？許多時候軟體專案主管會認為「這是上面高層交代」他們應該理解時間這麼短，大家工作這麼拼，每天都加班，品質要是有問題應該「高層能理解」！ 這絕對是錯誤的認真，品質有問題的話，「高層」只會知道你們做得不好，更糟的是，你自己已經知道做得不好，連自己的良心也都過不去，而使用者拿到品質差的軟體，當然只是浪費他的時間，這會是個lose-lose-lose三輸的決定。相反的，直接說品質不好無法上線，高層也是知道你們做得不好，但起碼你不會對不起自己的良心，最起碼不是雙輸決定。

(3) 真的沒有時間怎麼辦？

時間資源，品質，規模範圍：這三個軟體開發的要素最多只能要兩者。不可能三者兼具。要三者兼具的話，會自動犧牲品質。然而，其實品質是可以控制，但絕對不能犧牲，因為一旦犧牲，整個軟體不能做出本來該做的事情，有再多功能，用再快時間上市都沒有意義。
因此，其實最應該考慮的是規模範圍，簡單的說就是盡量減少不必要的功能。這其實完全符合Lean-start-up（精實創業）的精神。

如何指派工作 (軟體主管的31堂課)

作為團隊領導者，自然會遇到任務分配，指派工作任務的情況。軟體開發團隊也不例外，雖然敏捷式開發方式中的Scrum方法論，是希望在每個Sprint中採取「自己認領」工作，但其實極少有團隊可以完全做到這點。

指派工作任務最完美狀況是：團隊成員對主管有100%的信任，同時對組織中短期目標也有深切體會；並且都有完整的技術能力可以達成任務；而且所有人對於專案與時間管理都有經驗；而更重要的是，每個人都士氣高昂，迫不及待地完成任務。很遺憾的是，這種情況幾乎不會存在，好的軟體主管必然認知到的是，自己的任務必然是在於讓團隊成長前進，往好的地方邁進，而非期待自己「已經處於」一個完美的團隊。

如果你是個軟體團隊的主管，常常在夜深人靜時自己抱怨自己的環境與團隊，並且自認為委屈，那麼你就是屬於「期待自己已經處於完美團隊的主管」，這通常不會是讓事情變好的心態。

指派工作的方式看似很多，但重點只有幾個：

(一) 指定清楚的目標

指定清楚目標表面上很簡單，但主管自己其實需要考慮是這件事的真正目標，和指定任務的項目。

舉例來說，如果軟體主管指定任務目標為：「A工程師，請把某個AWS的一組VM，從micro升級到xlarge。」這看似清楚目標，但升級機器，必然不是目標，升級機器要達到的結果才有可能是目標，更有可能的是結果後的結果才是目標。

例如，稍微清楚描述目標：「A工程師，我剛收到通知明天由於行銷活動，我們網站流量應該會暴增，為了讓我們能處理高流量，請把某個AWS的一組VM，從micro升級到xlarge。」

但是，更好的方式其實是，清楚目標先指定，然後再討論出來。例如：「A工程師，我剛收到通知明天由於行銷活動，我們網站流量應該會暴增，為了讓我們能處理高流量，我們在AWS上的各種VM和使用的服務，有需要做哪些改變呢？」

當然，目標本身一定要涵蓋作法/行動。沒有具體行動的目標也沒有意義。

(二) 時間視為最重要衡量方式

時間是衡量所有事情的最重要的方式，在清楚指定或者討論目標作法之後，所有的行動必須以時間為衡量方式。而時間除了長度，還有實際完成時間。

例如：「A工程師，根據我們剛才討論結果，我們需要升級所有120個VM，這需要2小時，並且是在後天早上10:30am之前完成」

(三) 寫下來！

指派工作的另一個重點在於，所有任務指派一定要文字化或者圖形化，即便是很簡單的瑣碎小任務，也應該用一張紙寫下來。現在專案管理工具其實很多，例如JIRA。當然也可以用它來指定所有任務。

如何建立信任關係 (軟體主管的31堂課)

一個好的主管，會讓其團隊成員高度信任，在軟體開發團隊中，如果主管可以有效地和團隊成員建立健康的信任關係，就容易達成三贏效果：對企業有利，對團隊有利，也對個人有利。相反的，如果團隊主管不受信任，那麼組織內部就容易內耗，很容易就形成三輸的情況。普通的團隊則是部分成員信任團隊主管，部分則不太信任，主管意識到這點，其實是很有改善的機會。

何謂信任？

信任並不是說團隊成員要變成主管的莫逆之交，在危急的時候就算赴湯蹈火也都在所不辭。當然可以達到這點很好，但在企業團隊內是不太可能。所謂信任是指，團隊成員對主管決策方式以及最做事方式，有預期感，並能相信這樣的決策和做事方式，即便自己不了解，甚至不完全贊同，也願意有效的合作。

如何建立信任。有些事情對於建立信任的雖然有一點點幫助，但效果有限，例如典型的團康活動。有些事情則是對建立信任有決定的影響：

(一) 傾聽了解個別成員：

信任是「個人」心理狀態，因此，有效地傾聽個別成員在組織的需求，針對個別成員的需求，量身定做互動的方式。

傾聽的重點在於「傾聽」，中途插話，表達太多意見都不是傾聽的要訣。

(二) 共同接受並完成工作上的挑戰：

這和傳統軍隊建構團隊的方式雷同。一小組人一旦一起面對挑戰，並且度過挑戰，就容易互相信任。在經歷生死戰場的退伍軍人戰友，特別容易建立長期的信任關係，就是因為如此。
當然在企業環境大概不會有生死攸關的情況，但仍然有許多挑戰。好主管的要務在於對挑戰的本身必須要是正面看待，

例如：在跨國企業中研發團隊總是對某國家的另一些工程師作法相當不認同，並常在討論中發生意見衝突。團隊常常對主管抱怨狀況。不適任的主管在此最容易做的事，就是一起跟著抱怨，並且將責任歸於其他人，試圖在團隊塑造共同敵人，這樣短期團隊成員或許會開心，但是衝突並不會因此解決。一個好的主管，會將這狀況是為共同挑戰，讓團隊成員明白如果我們可以一起解決這樣的衝突，不但對組織有好處 - 可以讓跨國團隊更有效工作，對自己也有好處 - 在履歷表中就可以多一項很難得的成功經歷。

(三) 建立一致性：無論任何事情的好壞

建立一致性是在不公平的社會環境中，讓團隊成員認為主管會公平處理事情的最有效方式。所謂的一致性，倒不是指不能改變作法，而是指作法本身有可預期的一致性。

例如，在營運團隊中常常有假日需要輪值的情況，最簡單的方式是直接按照姓名或者到職日期，輪流安排成員在假日值班。表面上看起來是最最公平，實際上有可能是公平，但也有可能不公平，因為每個人上班期間的工作內容可能不同。一致性並不是說不應該輪流值班，而是指輪流值班的班表如何取得共識。例如，每次班表都是每3個月前產生，產生之後，會在兩週內先逐一詢問個別的需要，個人的需求被滿足後之後，在隨即email公布並詢問有沒有需要調整，並且在一週後正式啟用此輪班表。幾次之後，團隊成員對主管的做事方法就有一致性，知道主管在困難事項一定會先詢問個人，調整每個人狀況，還會在所有人面前再度公佈一次，然後再做最後調整。

這樣一次一次建立一致性，無論事情的好與壞，也無論主管個性，就容易建構工作上的信任關係。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如何提昇士氣激勵團隊成員 - part1 - 幾件千萬別做的事 (軟體主管的31堂課)

幾乎所有主管都知道，一個技術能力不錯，且士氣高昂，充滿鬥志希望，正面能量強的團隊成員，幾乎必然帶來高績效的結果。並且，他對團隊的貢獻，鐵定遠遠大於一個技術能力超強，但是士氣低落，充滿抱怨失落，厭世能量強的人。

軟體開發主管最難的地方莫過於激勵團隊成員。因而，能否再困難的情況下激勵團隊成員，就是優秀主管和普通主管的最大差異。

有幾件千萬不能做的事情：

(1) 單純使用薪資福利激勵團隊成員

只要是人都喜歡越來越高的薪資，越來越好的福利。但薪資福利是典型的「保健因素」，利用薪資福利短期或許有些微效果，但長期一定沒用。最糟糕的情況下，高薪資福利會留住成員的身體，但靈魂早就不再貢獻於組織。對團隊其實有更大的傷害，因為如果單純只為了錢留下來，就一定會精算如何在最最少的貢獻下，拿到最最多的利益（參見：公務員官僚體系)

合理或者略高的薪資福利當然是最好的。並且也是不可或缺，然而它只會是保健因素，絕不能當作激勵因素。

(2) 樹立共同敵人

有些主管會試圖建立共同敵人，或許是其他部門的人，有些甚至是同個部門的其他同事。主管透過和低落的團隊成員，一起批判別人一起抱怨，表面上看似同仇敵愾，其實是飲鴆止渴的做法。

這聽起來非常普通，但是，在企業組織卻很常看到主管無意中做出「樹立共同敵人」的事情。主要起因於人類一開始作為群居動物，對抗共同敵人就是群居動物的本能，原始人群居成為小部落，分工合作對抗毒蛇猛獸與惡劣環境，會讓所有人的生存機率大幅提升。現代商業社會發展不過也才不到兩百年，要抗衡超過10萬年的人類演化習慣是需要一定的主管個人知覺和意志力。

(3) 瑣碎的微觀管理

所謂micro management (微觀管理) 是指主管重視各種支微末節，會透過枝微末節的檢核來判斷與採取行動 - 而這個檢核可能和工作本身無關。最最簡單的例子就是組織規定早上9點上班，主管一看到有人9:10才出現，就會主動前往詢問。

根據工作的形態不同，微觀管理其實在某些情況下非常適用，典型的例子是傳統軍隊，或者勞力密集度高的產業。

然而，軟體產業鐵定不能使用微觀管理，軟體開發相關工作，其實有極強的自主性，每個人的產出不可能像生產手機一樣在最末端測試所有該有的東西，這些自主性，會決定整體團隊績效的好壞，主管即便不能提高自主性，也千萬別降低高績效人人自主性。

要注意的事，作為主管其實應該能清楚理解code review並不是一種微觀管理，優秀且高績效的人才通常喜歡「被code review」同時也喜觀「review別人的code」。如果你不能理解這件事情，表示你大概不適合擔任軟體研發的主管。

Scrum的缺點 (軟體主管的31堂課)

當手上有榔頭，看到任何東西都像釘子 -- Abraham Maslow 1966
------

過去數年來Scrum明顯成為Agile軟體開發裡最常被討論跟使用的方法。

當然也有不少文章討論scrum的缺點(請參考這裡)。然而，Scrum是個在agile development範疇內的方法論，它是個很好的參考軟體開發流程的工具，而這工具有其「特性」，無所謂好與壞，當然就無所謂優點與缺點。

然而，這些特性不可否認，需要對該工具有一定的認知，特別是一些「預設要知道的事情」，以免誤用。舉例來說，當你使用榔頭的時候，大概會知道它是用來釘釘子，而不是拿來釘螺絲。此外，你也會大概猜到，右手拿榔頭左手扶著釘子時，要記得不要敲到自己的手指。

以下Scrum缺點（特性），也是常見的陷阱僅供參考。

(1) 團隊成員對Scrum的了解必須一致，工作能力最好也要差不多。

Scrum的運作中，高度依賴成員的自主性。Scrum Master雖然很重要，但僅在於Scrum本身的運作。對於任務完成的定義以及任務的品質，還是靠所有成員的能力。

換言之，如果有人技術能力特別糟糕，或者技術能力雖好，但對於Scrum的運用與瞭解和大家都不一樣，那麼有可能會有意想不到的長時間磨合期。

(2) Scrum並不會真正加快速度，只是讓速度透明，讓大家專注重要的事情。

許多企業導入scrum的目的是為了加速產出。事實上，Scrum並不會加快「某件事情的速度」。Scrum會讓事情變得透明，同時也讓團隊進行的速度變透明，讓大家更容易專注於正確的事情上。

整體來說，Scrum會減少各種不必要的浪費，讓整個專案效率提升，但就個別事情的速度而言，Scrum並不會提升。換言之，軟體工程師仍然需要有自己的方式來提升個人效率。

(3) Scrum並不會解決工作內容的相依性 

傳統的專案管理方法論，常常會提供類似甘特圖的工具。然而，Scrum方法論專注於某件任務(story)的完成，而隱含著希望每個任務的相依性，會在團隊成員的「成熟考慮」下被處理完成。

換言之，有相依性的工作就是有相依性的工作，軟體開發團隊還是必須要有自己的方式解決相依性。使用scrum並不表示相依性消失，也並不表示當有個寫得很獨立的story產出時，就一定會跟其他工作無關。這些都還是得靠團隊來處理。無論是使用Jira還是agilefant還是任何工具，都應該有自己的處理相依性的方式。

極端簡單解決問題的技術：check-list (軟體主管的31堂課)

軟體研發主管應該要能順手使用許多解決事情的技術，例如甘特圖，流程圖，心智圖，時間序列圖等等。然而有時候，簡單的check-list 檢核清單能夠快速統一想法，解決問題，特別是在情況複雜紊亂，但又需要統一某種結果的時候。

---

案例：S公司擁有橫跨數個國家的雲端營運團隊(devops)，但就如同許多創新公司一樣，營運團隊一開始並沒有統一的流程，許多devops會自行發布想發布的服務，造成其他人的困擾。更有甚者，在預期有大流量的時候，常常忽略許多小細節沒有處理，然而又常常有很多人在做同一件事情。

---

檢核清單check-list的概念很簡單，跟SOP有點類似，就是列出一串要有的事情，當有的時候就打勾。最簡單常見的例子就是旅行攜帶物品清單，如下：

[ ] 護照
[ ] 美金
[ ] 變壓器
[ ] 盥洗用具
[ ] 雨傘

你大概會覺得簡單到不行的東西有什麼好說得？在快速成長的團隊中，有許多工程師都想要以「自動化」的CICD以及系統監控來解決問題，這當然是合情合理，但是在完成之前呢？很多事情是需要「時間」來完成，在能夠自動化之前，人工仍然避免不了。更有甚者，許多事情可以自動化，但是決定的方式卻無法自動化。

以該案例的情況來說，預期有大流量的活動時，可以在前幾蔫由主管決定一個清單，例如googlesheet 或其他文件知會所有相關人，例如：

[  ] 在N月O日P時，所有人停止部署服務 
[  ] 在N月O日Q時，A負責檢查可承受的流量
[  ] 在N月O日R時，A與B討論並決定要額外擴增多少服務
[  ] 在大流量活動日的 D時起到E時止， C負責監控系統流量，
[  ] 在大流量活動日的 D時起到E時止， A/B/K 各負責某某系統的服務正常性檢查
....

這個清單可以很長，但是清楚揭示所有人在大流量時應要負責的工作，送出之後即便有問題，也可以就事實來討論。以軟體團隊而言，check-list必然包含三件事情 (1) 直接負責人，通常只能是一個人名 (2) 時間:預計完成時間 (3)產生的結果:衡量這件事情如何被完成。

如何處理抱怨 (軟體主管的31堂課)

只要是人都會抱怨，然而只要是有經驗的主管，一定也都知道處理抱怨的重要性。過度並且持續擴張的抱怨不但會降低士氣，而且對團隊，對個人都沒有任何好處。

抱怨有分不同的層級，如果僅只是抒發心情，發發牢騷當然無妨。其界限在於，在平常閒聊，抱怨的只會佔不到1/3的時間，而在平常正式討論事情，正式的會議上，抱怨應該只是會佔不到1/20 (5% 或2分鐘)的時間。
主管在閒聊時後聽到的抱怨，大部分應該不用特別處理，畢竟是閒聊。 然而在正式會議上的抱怨則應該妥善紀錄並處理。因為抱怨的本身可能是和工作流程有關，更有可能的是潛在的問題，必須要試圖檢討解決。

---

案例一：工程師E技術能力向來不錯，然而跟他一起工作的同事，總是會反應他是個悲觀的人。追究原因發現，E無論如何都在抱怨，抱怨目前的現況和組織的做法，抱怨福利薪資等等。過了一段時間之後，團隊成員有些會受到影響，跟著開始抱怨，有些則會忽視他的抱怨。

案例二：在跨國團隊中，另一個國家的工程師會抱怨無法取得某些系統權限，而本國工程師常抱怨另外一個國家的工程師常想要干涉目前自己工作的範圍。

---

主管處理嚴重的抱怨有幾個方式：

(1) 了解抱怨的事實，根據事實決定行動

如果軟體主管覺得這個抱怨的人其實是為了組織好，而且，大部分的時候抱怨者其實不那麼常抱怨，也不是士氣低落的人，他除了反映工作困難之外，也許也揭露了應該改善的現況。應該進一步了解實情。並且在根據事實來決定行動。

以上面的案例二，雙方雖然都有道理，但主管進一步了解事實後，會發現其實某些系統的權限並沒有分group，這會讓該系統只要有權限的人統統都是最高的管理者權限，所以表面上是合作問題，其實是個技術問題，應該讓系統有不同層級的權限，另一個國家工程師也不是真的想管理這個系統，只是為了工作必須要直接使用，透過另一組人間接使用也很麻煩。而本國工程師也不是真的不想讓其他人使用，只是考慮安全性不應該給很多人管理者權限。

(2) 擁有改變的力量，而不是擁有「叫別人改變」的力量

許多抱怨的工程師常常會忽略「在公司裡面，我是來解決問題，而不是製造問題」

對於主管來說，如果抱怨者其實績效能力都很好，那麼應該化抱怨為力量。舉例來說，當團隊成員抱怨「現在的某系統在部署常出問題，害我需要做額外的工作」。那麼就可以先就事實詢問：「你覺得這對你很重要嗎？這是不是我們應該先解決的問題？」如果是的話，進一步應該跟抱怨者溝通：「既然這樣，你現在在做的是XXX和XXX，這兩件事就先不做，先來把某系統的部署改善，這樣以後你就不用做額外的工作」

讓抱怨者擁有改變的力量 - 就是要調整工作內容和時間。這樣久了，也可以清楚地塑造團隊會往解決問題方向前進，而不會只抱怨問題。

(3) 概念性問題：先記錄並且追蹤

概念性的抱怨是指對公司政策概念的抱怨，例如：為什麼我們公司沒有work-from-home(在家工作)的政策，為什麼上下班要打卡。這類型的抱怨很多時候和「實質工作」沒有很大關係，然而，不處理或者直接用「這個是公司HR政策 我也沒辦法」這種說詞也對大家沒好處。

對於概念性抱怨，應該先行記錄，並且追蹤對團隊成員的影響。舉例來說，對於work-from-home的要求可以先了解團隊成員需要work-from-home的原因：例如需要專心工作，還是需要兼顧家人。如果是需要專心工作，可以提出會在他需要專注的時候。幫忙直接訂一個會議室，或者讓他在距離公司很近的咖啡廳工作，並且記錄一整個月，看看有沒有實質影響。也許，他以後就不想真的work-from-home，也許他會覺得在咖啡廳工作也很好。

重點在於，概念性抱怨其實應該轉為實際可追蹤執行的內容。

主管對於團隊成員的抱怨絕對不能做以下的事情：

(1) 隨意附和，隨意認同抱怨： 表面上這似乎可以拉近團隊與主管的感情，事實上，一起抱怨對大家都沒有任何實質好處。

(2) 忽略重大抱怨：如果這個抱怨是很嚴重的，忽略拖延也沒有好處

(3) 不查證事實根本原因就行動：雖然所有人都知道要查證事實，然而許多事實的根本原因其實不那麼簡單。

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

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

---

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

---

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

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

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

電話面試的技巧：

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

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

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

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

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

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

二：基本的事實查核

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

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

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

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

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

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

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



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

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

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

---

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

---

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

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

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

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

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

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

三：必要的犧牲 

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

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

陷阱

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

如何處理員工離職 (軟體主管的31堂課)

無論如何，主管一定會遇到離職的情況，因此，事先計畫離職處理是軟體主管必定要做的事情。執行上大致上分為三個階段：一：慰留決策，二：離職程序，三：事後檢討。

---

案例：B是一個資深的QA，在開發團隊裡擔任許多重要任務，與此同時還負責管理在印度的測試外包團隊。某日B突然告知，有個新創團隊找他擔任QA主管一職。由於B的職涯規劃是希望朝主管職前進，因此對他而言此機會非常難得，錯過這次也不知道何時能再有這機會，因而提出辭呈，離職時間希望是三週後。

---

一：慰留決策

當接收到離職訊息，第一件事情其實是評估現況。這位成員現今是否適合團隊，並且有很大貢獻？如果是的話，那麼就應該慰留，如果不是，則應該迅速答應並且直接進入離職程序。

請謹記，考慮是否慰留，僅只需要考慮此人適合團隊與否，及是否有很大貢獻。並不是要考慮「他現在手上工作很多」，也不是要考慮「沒人交接很麻煩」，也不是要考慮「現在A專案要是有人走，會對進度造成影響」。倒不是說這些不重要，而是短期因素不能影響長期決策，如果他沒有要走也就罷了，但是一個剛好不那麼適任的人要自己離開，等於是天上掉下來的禮物。

案例中的B明顯是屬於需要慰留的情況。

慰留可以做的事情是：提供主管權限可以提供的任何方案，特別是應該要和B一起討論「如果有什麼事情發生，你就會打消辭意」。討論的本身必須針對「能近期發生的事情」，就事論事才有機會。

慰留不能做的事：不能答應任何自己也做不到的事情。以案例中B的情況，他想要往管理職方向前進是非常好的事情，但公司如果很明顯在未來6個月不可能有此機會，則就不應該答應升遷的可能。慰留也不能當作「拖延離職時間」，任何拖延對大家都不利，因此設定慰留期限是很重要的，頂多2-3工作天已經綽綽有餘。

大部分高績效人才的慰留機會其實相當低。主要原因是高績效的人才通常對事情想得夠清楚才會提離職。

二：離職程序

當提出離職無法慰留後，當下就進入離職程序。主管無論對團隊有多麼強的信心，都應該在建立團隊的時候，先行建立離職程序有備無患。要謹記的是：這裡所謂離職程序，並非HR的離職手續，離職手續僅為文書作業，只要遵循HR的規範即可，但離職程序是要確保對組織的衝擊最小，對現存專案的影響最低，並且讓團隊更能成長。這只能由主管來設計進行。

離職程序最重要先有的事情是最後上班日。雖然說勞基法對最後上班日有規定，但仍然可以和離職的人討論。

以人才為主的軟體公司，其離職程序的管理與執行，絕對不能由「要走的人」執行，而是由「要交接的人」執行。即便我們已經知道要離職的人是個好人，也知道交接的重要性，樂於幫忙任何事情也一樣。主要原因是事情的目的必須要和個人方向一致，即將離職人的方向絕對和現存的人「不一致」。

如果你作為主管還沒設定離職程序，可考慮如下步驟

(1) 確定離職時間 例如3周後
(2) 列出目前工作清單, 列出目前擁有系統權限清單, 列出目前硬體資產清單 電腦等等
(3) 與團隊討論出負責交接的主要負責人，有時候也需要特定工作交接負責人
(4) 設定hands-off day (預計是離職前一週) ：在這天之後，離職人仍然要上班，但只需作為顧問任務，工作都是交接人來進行
(5) 設定交接目標與時間，直接約好交接的教學會議：交接必須是交接工作內容，而非交接技術知識。交接會議必須要專注於現況，而非未來。
(6) 每週至少設定兩次檢查會議，檢查會議只需要10分鐘檢查交接現況。但要注意的是hands-off day之後檢查會議就不應該讓離職人參加
(7) 設定離職人的文件轉移，必要時需要繼續撰寫文件
(8) 倒數第一天：將硬體資產點交
(9) 最後一天：取消系統權限，歡送會
(10) 離職後2周內：事後檢討

三：事後檢討

是否有效的進行事後檢討，是好主管跟普通主管在處理離職的「最大差異」。

高績效人才通常也是重視溝通合作與人際關係的人才，因此不見得會在離職理由上說出實情。然而，探索實情，「正確」調整領導管理方式，以及「正確」調整組織結構會是事後檢討的重點。

(1) 探索實情

統計數字不會騙人，請自己google看看「離職原因統計」，可以看到許多統計數字都指出，離職理由和主管有很大的關係。如果你是主管，對於高績效員工離職，切勿以其他的方式糖塞欺騙自己。要能夠避免這件事情，在探索實情時，必須直接假設「自己就是問題的一部份」：無論你覺得自己有多好。

常見的藉口有：

* 外部拉力：他找到更好的發展機會 我們無法提供
* 有限資源：我們公司資源有限 已經給他很好的薪資福利但他還是不滿
* 內外部歸因：我覺得他自己個性有問題
* 往上推責：最上層主管做事風格讓我難以處理

(2) 調整領導管理方式

檢討大部分的時候結果是都要調整領導管理方式。不見得是大幅度改變，可能只是些微做法調整。但簡要的說，高績效的離職如果不做任何調整就幾乎等同自己騙自己。

關於調整方式有空會再多解釋一點。

(3) 正確調整組織結構

有空再針對這問題解釋多一點。簡要的說，以案例B而言，他想要往主管職前進，並不代表公司應該要產生很多「主管職位」來應變未來眾多人想要擔任主管職的情況，正確調整組織結構並不是直接反映離職人的期待。

系統化思考的秘訣 (軟體主管的31堂課)

系統化思考 Systems Thinking 是解決複雜困難問題的科學方式。而作為主管的工作，時常遇到困難的狀況，如果身為主管的你沒有一個科學性的方式來分析與處理困難狀況，自認可以依賴直覺和經驗，那麼很有可能你依賴的是運氣而已。

---

案例一：有位資深的HR M，憂心忡忡的問說，過去三個月我們的資深工程師招募好像不順利，快要一百人無法通過我們的評估，Hunter看到我們這樣都不太願意再送履歷表來了。我們是不是標準太高？要不要降低標準。

案例二：某主管A被要求和直屬於CEO辦公室的專案經理D合作進行系統整合，然而專案經理D常常會有不合理的要求 ，並常在會議中酸言酸語，讓A在系統整合上花了很多人力時間，但又打不到D的要求，而D又有CEO作為後盾。

---

上述案例都很複雜，牽涉的範圍廣泛。為了解決複雜問題，系統化思考會牽涉到各式各樣圖形工具，例如這個，或者這個。這些圖形工具其實都是為了簡化問題。系統化思考的理論與應用廣泛，但是針對軟體主管的工作特性，有幾個祕訣(捷徑)可以先試看看

(1) 無論如何，先畫張心智圖或者魚骨圖。

心智圖可以拓展思考，魚骨圖可以先探索遺漏因素。更重要的是，圖形可以將你的思考模式放在紙面上，讓你用鳥勘的方向，有機會重新思考問題。並且，這圖型還可以留供未來檢討使用。

(2) 無論如何，先透過5Why找到真正的目的或原因。

以上述案例一，當我們先從一個方向使用5why探究原因，可能如下：

為什麼HR會覺得不順利？是因為招募人數不足。為什麼招募人數不足？是因為hunter不願意積極尋訪多送履歷表。為什麼hunter不積極？是因為我們篩選比較嚴格。為什麼篩選比較嚴格？是因為....

但是，從另一個方向使用5why可能如下：

為什麼HR會覺得不順利？是因為面試的多但都沒錄取。為什麼面試多但都沒錄取？是因為hunter送來的履歷不符合我們徵才的要件。為什麼不符合？是因為hunter不了解我們要什麼樣的人才。為什麼不了解？是因為....

找到事情的真正源頭，或者自己想達成的真正目的會是系統化思考要達成的第一個目標。

(3) 實驗性質的行動！兵聞拙速 未睹巧之久也

任何形式的研究調查，都可以無限期地進行下去，可能永遠都不會有結果。然而作為主管，透過行為有效的將事情推進下去才是重點。

案例二：當展開5why與心智圖，了解CEO的辦公室經理D其壓力來自CEO對他有時間限制時，而D由於無真正的技術能力，導致會將各種事情盡量轉交給主管A，探究其目的在於，萬一整合失敗，不會被歸咎責任。而A的做法就是互相對抗，兵來將擋。這樣的情況，可以持續下去永遠沒有結果。而後改變的做法是，先實驗性透過提供各式各樣教育課程給D的部屬，讓其部屬更了解系統如何運作，並且在各種會議中提及教育訓練一事，讓CEO理解其直屬的團隊的能力不足，因而會讓系統整合的設計本身交由A來進行，自然系統整合的最後結果就會順利達到CEO要求，也讓A與D之間的關係不會永遠惡化。

案例二看似政治問題，但其實透過實驗性質的活動（提供教育訓練）可以讓A快速證實D的團隊能力不足，即便教育順練活動辦得很粗糙簡陋也可以。


提醒一下，無法進行系統化思考的主管，最後更容易透過「恐懼」「運氣」「政治手段」等方式來管理團隊，至於能否達到目的就很難說。

如何讓一對一面談變得有用！ (軟體主管的31堂課)

做為軟體相關工作的主管，固定和自己的團隊夥伴一對一面談，在外商俗稱 one-on-one：是絕對不能省略的事情！如果無法和自己直屬部屬(direct report)每個月至少一小時的懇談，那麼絕對無法有效的激勵與維持團隊。

---

案例：C是在大公司的資深工程師，他常常跟我抱怨他的主管不了解情況。而由於該公司是有規定主管需要跟團隊成員固定one-on-one，所以我自然就問「你不是有跟他固定one-on-one嗎？」，C則回答「是啊，但是那也是聊聊天而已，改覺反應什麼也不會改變」

---

作為主管，要避免上述案例發生，一定要知道如何有效率的進行one-on-one並且讓他變得有用！

如果你的直屬成員超過10人，一對一面談反而更不能忽略或省略。如果你的直屬成員超過15人，那麼你的現行組織必須分層或者分開，除非你的組織是「人力導向」而非「人才導向」否則，超過10人的直接管理已經是極端困難，超過15個人是幾乎不可行。有些主管會驕傲地說，我的直接report-line有35個人，通常這樣的主管已經默默地分出階層，會找尋team leader來取代主管的工作，而大部分的時候team leader才是真正的主管。

一對一面談(one-on-one, 以下簡稱1-on-1)主要的目的有幾個：
1. 了解該成員的士氣情況
2. 了解該成員工作上是否遇到困難
3. 了解是否有需要處理的人際問題
4. 給與成員過去工作表現的精簡摘要：做的很好，或者做得還好，或者做得不好
5. 讓成員給自己回饋


一般來說，1-on-1不應該用來解決「技術問題」，技術問題應該是透明解決，而非兩個人私下解決。除非團隊人數剛好就是兩個人。

1-on-1的推薦作法：

一：固定架構與取得事實優先

當談話有固定架構時，部屬在每一次談話自然就有期待，以及自然地提供所需要的資訊，而這些事實資訊就反映到一對一談話的目的。

所謂固定架構很簡單，就是鎖定2到5個基本問題，這些問題是取得事實，並且應該很快可以回答。舉例來說：

(a) 請問你上次1-on-1到今天為止，有沒有遇到讓你很生氣的事情
(b) 從現在到未來2個月內，你有離職的「打算」嗎
(c) 今天有什麼事情，是你認為我要馬上去做的
(d) 從上次1-on-1到今天為止，你覺得工作開心嗎

這些問題都可以簡要的了解此成員的現況。重點是要用張簡單的紙長期追蹤這些問題。

二：自由討論時間以傾聽為主，下次必定追蹤！

固定問題需要紀錄，自由討論時間更是需要傾聽紀錄和追蹤！

自由討論當然以傾聽為主，在團隊成員還沒徹底講完，只做記錄千萬不要打斷。在結尾時，要說明你記錄了什麼。如果是組織做的事情好壞，公司目前現況，專案進度等等相關的，不用在1-on-1之間有結論，但一定要能夠紀錄，並且承諾會重視他講的所有事情。

重點在此！下一次1-on-1必定要重述他曾經重視的事情。並且，說明這些事情目前的現況，同時也和他討論這些事情對他現在還重要嗎？畢竟很多時候團隊成員只是需要抒發心情，並不真的重視這些，他們可能更重視的是「主管有重視」而已。

三：陷阱！不要做這些事情！

請注意以下陷阱！

1. 千萬不要和團隊成員一起抱怨公司政策，或者一起抱怨某個公司員工或主管
2. 絕對不能承諾無法100%達到的事情
3. 傾聽抱怨是應該的，但導向抱怨成為可執行的行動是最重要的一步
4. 切勿打聽A成員對B成員的個人看法！但可以詢問A成員關於其他員工某個特定時間點做的某件特定事情。
5. 1-on-1必須要有自己的筆記，千萬不要忽略紀錄

加入新創後 如何建立團隊 (軟體主管的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