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

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

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

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

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

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

可以參考這篇

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

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

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

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

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

當然是越低越好

(5) 臨時加班次數

當然也是越低越好‘

如何指派工作 (軟體主管的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開頭，中間，結尾都講一次。

極端簡單解決問題的技術：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堂課)

系統化思考 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堂課)

當你有機會加入一個新創公司，並負責建立某個軟體開發團隊，無論是哪種類型的團隊：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說要不要早點有人進來)