管理能力是可學習的硬知識技能 (軟體主管的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)產生的結果:衡量這件事情如何被完成。