經理人之道：技術領袖航向成長與改變的參考指南
當我讀到這本書時有一種相見恨晚的感覺，不愧是眾多大師推薦的一本關於面向專案管理(Project Management) 的好書，對於一個軟體人來說這本書可以說是必讀的。從剛入門的軟體工程師新手給予很好的建議，再來是資深工程師、技術領導，到後來轉職為管理者的全方位教學。這樣的道路也可以說是常見的職涯規劃，當然，想要繼續鑽研、醉心於技術的人，仍然也能獲益良多。
軟體工程師
作為剛入門的職稱，會發現以前在學校學到的技術等級完全不敷使用在產品、服務上，需要不斷精進其中的技巧。剛進入職場，總有著資深的前輩、架構師罩著，除了跟隨他們的腳步走，漸漸得也要學習看待問題的思維，進而提升自己在專業上的能力。另外一點更重要的是找尋自我，了解自己想要的，維護自身的權益，如果沒有頭緒，本書前面章節提醒、舉例了很多相當重要的部分，讓讀者能夠得到相當大的助益。資深軟體工程師 & 技術領導
就我的職涯經驗中，每間公司對於 Tech lead 的定義不太一樣，有的像是純技術負責人，有的則像是專案負責人，需要負責到專案的設計、開發、交付時程與品質等，這部分職責會與專案經理相重疊，如何共同合作是一門很大的學問而其中的細節與各間公司組織架構有非常大的關係，無法完全套用特定規則。無論如何，Lead 這個字眼終究與管理、溝通有著極大的關係，勢必是需要學習開發程式以外的技能，這點非常吃重個人特質。有些人始終不想碰上管理，畢竟面對人與面對電腦差異慎大，有「人」的部分就是隨時在變化，需要隨時準備好改變與突發狀況，相較於純開發上，就顯得複雜非常多。
專案經理
專案管理其實是名詞上的誤解，該關注的絕對是「你的成員」，而非僅有專案或項目上的進度，能夠完成專案的是人，而非進度表上的數據。
從第四章開始進入本書的管理重點，內容繁多，讀第一遍時感到極其硬核，做了一些筆記後再度閱讀，發現這些細節與重點並不複雜，關鍵在於「養成習慣」，平常生活中多了解、觀察成員，定期給予正面讚賞與建議，千萬不要給予「驚喜」，這可是管理者的首要大忌！！
人家常說選擇好的老闆跟到底就對了，好的管理者除了足夠關心成員、培養他們的職涯也照顧到心理層面。
你是好的管理者嗎？或者你有跟到對的老闆嗎？
認真說來這邊的心得僅有包含大部分內容，書中後半段描述的是管理多個團隊、高階經理人，礙於本人還沒到那個層級，雖然閱讀完但仍有部分內容無法完全內化，就不在這裡獻醜了。
章節筆記
CH1 管理入門課
這個章節比較像是給新鮮人的建議。
與主管的交流 或 1 ON 1
- 建立你和主管之間的連結，透過這個會議能夠讓他更了解你
- 聊聊最近有什麼狀況，可以適度發出你的需求
- 控制會議的走向並非完全主管責任，你可以規劃想討論的內容，但不要是進度報告！
- 直屬主管是頭號盟友，給予你建議、培訓、職涯成長或是升職
- 主管希望的是你能夠帶來「解決方案」而非「提出問題」
- 永遠在尋找能夠學習成長的環境
- 尋找優秀的主管與導師
- 建立同儕人脈
- 強大的技術力需要經驗與時間的累積，無法一蹴可幾
- 花時間思考你要什麼(這是一個幾歲都需要不斷問自己的問題)
- 對自己負責：主動尋求反饋，虛心接受建議
CH2 指導
每個人都會經歷過被指導與指導的階段。
Intern
- 嘗試著將專案切割細項，並與實習生逐一確認過，整個過程包含聆聽與溝通，是成為管理者的必備技能之一。
- 確實仔細聆聽，包含觀察肢體動作與面部表情
- 明確溝通：引導他該怎麼做，如果無法，則明確告訴他該怎麼做
- 定期校準：頻繁的確認進度、反饋給實習生是很重要的
Rookie
- 指導新人是一個全新眼光觀看這個部門/公司的機會，畢竟你已經上手太久，很多事情早已視為理所當然。
- 高效團隊準備好：入職文件、環境設置文件、系統部署流程
- 上述文件需持續更新，若有錯誤或過時，可以邀請新人加入編輯，讓他有所貢獻也必須要分享。
Mentor
- 導師關係的目的：幫助團隊新人進入狀況
- 確實認真的指導，而非半吊子，半吊子比不做更讓人氣餒
- 作為導師勢必會伴隨生產力下降
- 保持好奇與開放心態，不要將團隊規則視為理所當然以及故步自封
- 傾聽與使用他們語言，嘗試著理解他們的想法，而非直接灌輸既定或正確做法，引導比指導更重要
- 建立人脈：職涯很長，圈子很小
CH3 技術負責人(Tech Lead)
什麼是 Tech Lead ?
- 必須扮演技術專案領袖的角色，廣泛應用專業知識，對內使團隊變得更好; 對外與其他合作夥伴互動發揮協調作用。
- 學習如何成為優秀的技術專案管理者，透過有效分派工作而不逢事必管。
- 關注整個團隊生產力，提升團隊成果的影響力。
- 學習有效與產品、分析或其他業務團隊合作。
工程師的職涯必經之路？
- 軟體工程師晉升到資深工程師後，可以自行選擇避免管理技能的-獨立貢獻者或是具備管理技能的 Tech lead
成為優秀的 Tech lead
- 勇於遠離程式碼
- 停止依賴舊有既能，開始學習新能力(無論是技術或管理)
- 比起獨立貢獻者，Tech lead 往往被要求更多的職責，像是設計架構、關注每個細節與保持交付
- 需全然了解專案需求、妥善規劃工作並保持團隊產出效率
- 花時間好好與經理職務(主管)解釋設計，嘗試讓非技術職的人能理解專案，有必要時仍然要解釋技術與選定的理由
- 透徹了解架構：認識系統、設計細節、資料流
- 注重團隊精神：無聊的事以及有趣(挑戰)的事，都需要與團隊共同分享並執行
- 溝通能力：代表團隊參與會議進行需求溝通，並將會議結果分享給團隊。訓練書寫、閱讀以及溝通能力，撰寫文件並與團隊分享，並取得他們的反饋。
- 練習重述一次對方說的話，確保與他們表達的是一致的。聆聽他人想法，並用自己的方式重複解釋一次。
管理專案
- 分解工作：將大專案拆解成小的工作項目，並著重在工作優先序、何時能開始項目、由誰執行個別任務。工作可以是你熟悉的試算表(像是 Microsoft Project)、甘特圖 或是 WBS 之類的工具。
- 推敲細節與未知要素：推敲每個項目可能會遇到的問題、如何解決以及需要什麼樣的協助。
- 運行專案，調整計畫：透過上面的規劃你能了解到團隊進度為何，當進度不如預期時，也讓每個人都理解狀況。
- 管理需求變更：專案勢必帶來需求變更與未知突發狀況，透過了解變化帶來的風險與成本，即時評估專案的交期，或是在交期之前優先進行必要項目、簡化或捨棄次要項目來取得平衡。
- 專案末期：重新檢視專案的每個細節，哪個部分需要足夠的測試、驗證，上線前的演練報告(Premortem)與預先演練，同樣，遇到問題時，能夠移除「更好」的項目，優先執行「必要」的項目。
個人經驗評估
- 公司對於 Tech lead 是否有職務說明？要求是什麼？
- 如果你像成為 Tech lead，你是否願意多花時間在程式碼以外的事情上？你對於系統架構是否有足夠的理解？
- 你有沒有和主管討論過對於 Tech lead 的工作期許？
- 你有沒有和出色的 Tech lead 共事的經驗？他們做了什麼事蹟讓你感受到優秀？
- 反之，讓人沮喪的 Tech lead 呢？
CH4 管理個別成員
為團隊新人建立 30-60-90 日計畫
建立 30-60-90 日計畫能夠幫助新人有目標的熟悉公司、部門的節奏，其中內容包含程式碼、修復、部署流程，使得他們能夠跟上團隊的腳步。另一個好處是能夠幫助你評估這位新進員工是否適合公司。
關於 30-60-90日計畫 可參考這篇文章
鼓勵參與更新 New Hire 文件
對新進員工來說，鼓勵參與編修這份文件能夠使他們感到有貢獻感。通常會閱讀此文件的都是新人，也只有他們會按照這份文件來執行每個項目，對於過時、執行上遇到問題他們會第一手面對，透過他們克服問題後來修繕文件再適合不過。
管理者的日常
溝通你的行事風格
互相了解彼此會使得工作更順暢。這部分需要明確告訴他們你希望得到的工作細節，包含如何回報交付、回報頻率等。
一對一會議
1 | 規律的一對一會議就像定期更換機油; 假如懶惰於執行這個步驟，到時候被困在路上的就是你 |
- 定期的一對一會議：建議剛開始一週進行一次，選定適當的時間，盡量避免在忙碌的週一或週五執行
- 在這週內，你和他的交流頻率多嗎？假設多的話，不一定需要這個會議
- 這個人需要多大程度的輔助？
- 這個人和你分享了多少資訊？
- 你和這個人關係有多友好？有時候不要把時間都花在有問題的員工上，明星員工也需要關注
- 團隊或公司近況是否穩？
- 回饋:
- 「沒有回饋」遠糟糕於「任何回饋」
- 好的反饋應公開、立即表揚
- 差的反饋應該於私底下提出，讓對方能及時修正
了解你的員工
每一位員工的特質與個性皆不相同，處理一對一會議的方式也不同，有以下幾種做法，可以是綜合也能是單獨類型：
- 待辦事項型：專注在需要執行的項目上即可，高效率且不浪費時間、拖泥帶水。
- 打聲招呼型：員工具有很多想法，可以讓他們來主導整場會議，讓他們發揮關於團隊與個人的意見。這個部分容易流於職場上的抱怨，需要盡量專注在個人與團隊工作的項目上，而非情緒抒發。
- 建議回饋型：這個部分特別適合在新進或新手員工，在每次會議上提出建議與改善目標，下一次則提出來檢討，不斷聚焦在需要強化的項目上。讚賞也是，請不要吝嗇讚美做得好的部分。
- 進度回報型：當一位員工除了回報進度之外真的沒什麼好聊的時候，就能夠嘗試適度減少一對一會議的頻率，但要記得他的狀況是沒問題為前提。這種形態比較有可能的情況是讓其他資深工程師或經理向你回報你無暇應對的專案。
避免微觀管理(Micromanagement)
- 當員工擁有自主性，能夠適度決定自己要做什麼時，才能夠有效的激勵員工
- 缺乏信任和不肯放權是微觀管理(Micromanagement)的主要問題。
- 當你被微觀管理時，代表你不被信任能夠完成任務
- 當才華洋溢的工程師成為主管時，微觀管理的情況屢見不鮮！
- 不要要求遇到困難(或每一位)員工每天進行彙報，短期也許可以，但長期對你的工作是一個負擔，對員工來說也有更大壓力，進而產生逃避以及隱瞞問題的狀況。
委派工作
- 花點時間觀察團隊，當團隊沒有任何可以分享的東西，這是一個警訊，代表你可能需要調整團隊方向
- 不要透過員工獲得一些唾手可得的資訊。可以自行查看版控、工單系統或是監控系統
- 通常，你只需要知道哪些事情進行得順利，哪些項目比預期多的時間以及是否需要協助救好
- 團隊需要的是一個信任他們的上司，不要拿你寶貴的時間去管枝微末節的小事
持續回饋
持續回饋是一種定期分享正面回饋和修正建議的實踐。強烈建議發生問題當下就能提出來，而不是需要等到久久一次的績效評估才反應。以下為實踐的方式：
- 了解你的成員：了解成員是第一成功要素，花點時間好好坐下來與他們聊聊近況，有什麼想法與需要協助的部份
- 觀察你的成員：優秀的經理知道如何找人才，但也不要總是專注在「需要改進」的項目上，這樣持續回饋變演變成持續批評
- 定期讚美：設定一個目標，定期讚賞團隊的某個人。這樣做的好處是迫使你仔細觀察團隊的每個成員，從正面回饋開始，強調成員在某件事上做得好，更能提升他們的榮譽感。
績效評估
- 360度績效評估是一個更為精準且優秀的評估方式。
- 績效評估應當是一個漫長的過程，需要透過他人來協助評估成員
- 人往往會透過成見來審視他人，千萬別高估自己
- 該回顧的是整年，而非最近幾個月。人們往往只記得這幾個月發生的事，儘可能提醒彼此值得關注的事項
- 將重心放在成就與長處，不要糾結於需要改善的項目，這不是績效考核主要目的
- 避免驚喜。如果成員在某些方面表現不佳，那績效考核上不應該是他第一次聽到需要改進的內容
- 如果沒有特別想提出改善的項目，那很可能代表這個人準備好要被升職了
- 如果一個人持續表現不佳，也有可能是放錯位置，給予不同類型任務也許他能做得如魚得水
- 潛力，必須與「行動」和產生的「價值」緊密聯繫，其他都是多餘的幻想
培養職涯發展
- 作為主管者首要任務，了解公司遊戲規則、升職流程
- 管理者必須要做的工作之一就是「幫助員工升職」，因此替該位員工準備升職的理由是應盡的責任
- 找出適合的「升職專案」，將這些關鍵專案交給潛在適合升職的成員
個人經驗評估
- 你有沒有定期和成員開一對一會議？
- 上次你們討論職涯發展是什麼時候？
- 最近給予正面回饋是什麼時候？
- 上一次給予改善建議是什麼時候？你給予多少時間再度檢驗？結果如何？
- 你有沒有經歷過不公平或沒有意義的績效評估？那怎麼做才能改善？
- 你知道公司的升職流程是什麼嗎？
CH5 管理團隊
管理團隊
- 維持技術敏銳：想贏得工程師團隊的尊重，必須讓他們信任膩在技術上有所建樹
- 將主要目標分散為數個小目標，保持定期實現，會讓團隊更熱衷於工作
- 解決工具與流程上的問題。放任軟體流程問題會使得生產力低落與員工受挫，與其這樣不如花點時間，大家認真將流程問題改善，促進自動化、減少人力參與、減少重複性工作，對於團隊影響將立竿見影
- 當工作團隊遇到交期將至，與團隊共患難是非常關鍵的，最後他們只會記得管理者是否撒手不管，還是願意與他們共度難關
- 趕赴交期，不應該是頻繁發生，無非就是應該減少需求或替團隊爭取時間
- 跨團隊協作遇上問題，務必表現出願意解決的態度，定期與對方團隊主管接觸，也向自己的成員尋求回饋，針對改善進行有意義的對話。
- 公開場合，保持積極正向態度，支持團隊成員的努力，成為他們的後盾
- 讓團隊保持專注。經理的工作是幫助團隊保持專注，阻擋外來的事物讓他們分心，像是職場的勾心鬥角、政治角力。
- 適度讓團隊承受壓力
- 確保團隊成員了解事情的脈絡。這邊說的不是芝麻蒜皮的小事，像是公司的政策調整、專案目標改變、產品方向調整等，需要讓所有成員了解這些是，這會使成員感到尊重、重視，有助於凝聚團隊向心力。他們不是工具，而是人。
- 專案管理者在規劃目標時，應該以團隊大方向為主，在幾個月、幾週的工作量進行評估。幫助團隊粗估工作量，有助於每個衝刺的敏捷開發方法規劃內容。
- 一個季度預估
10週的工作量。一年52週，一季13週，扣除休假、生病以及其他狀況，用10週作為生產力評估是比較合理的。 - 預留
20%時間進行維護現有系統，無論是重構、加測試或是調整 Legacy 部分，也可以當作是工作項目上的緩衝。 X2法則，在軟體領域估計工時的方法，當需要立刻給出預測時間時，把預估的時間乘以2再回報，是一個蠻常見的做法。
激發正向循環
- 培養以資料驅動的團隊文化。凡事以資料做為提案或決策的依據，例如生產力(交付或程式碼相關)、品質指標(程式碼品質或QA開單狀況)，都是觀察團隊產出狀況的好指標。
- 舉行回顧會議。衝刺期間發生的事情與決策(無論好、壞或一般)拿出來討論，確保團隊決策方式是否滿意，是否有得到充足的需求幫助，系統品質等，定期回顧系統和專案成果是非常重要的，一昧的向前衝刺只會讓團隊感到疲憊，且不健康。
- 經理的職責是讓團隊聚焦在目標上，阻擋外來、不必要或無法做的事情。這其中必備的手段是了解重要性與優先順序，並可以向團隊成員徵詢意見、回饋。
- 建立「團隊安全感」，讓成員勇於承擔風險、不怕犯錯，是建立團隊的良好基石
管理衝突
- 不要完全依賴共識或投票。因為只要是人，就容易偏心、選擇所好或是帶有利害立場去投票
- 建立明確流程，減少人為干涉、干擾，造成不確定性
- 正視潛在問題。例如成員在工作上出了問題，應該立即提醒，而非等到一對一在進行處理。
- 解決真正的問題。問題是否有持續發生？只有你一個人認為有問題？還是大家都因此糾結？經理的任務是找出問題的原因，解決團隊氣氛不佳或效率低落的狀況
- 不要為了袒護自己團隊，拿其他團隊出氣，這是工作，沒有伸張正義這種事
- 經理的目的不是當好人，真正應該做的是為人著想。在任何問題即將發生或者惡化前，提早發現並提醒
- 勇於面對衝突，謹慎思考解決方案
- 當團隊內存在「有能力的混蛋」，他的行為會造成團隊不良影響，必須在當下發聲，表明明確立場。
- 隱瞞資訊的人。通常這種屬於害怕的表現，可能是工作沒有達成期望目標、擔心受到苛責。應該明確告訴他狀況，說清楚才能真正解決問題。
個人經驗評估
- 身為專案經理，你的職責是什麼？你應該停止什麼樣的工作，或者將什麼工作轉交給團隊？
- 你對團隊的日常工作有多了解？像是開發、部署與維運？
- 當某位成員為團隊帶來大量負面情緒時，你打算如何處理？
- 你和團隊成員相處融洽嗎？上次一起坐下來喝咖啡、吃午飯是什麼時候？
- 團隊如何做出決策？你有分配決策責任的流程嗎？然而哪些應該由你來做決策？、
- 你上次縮小專案交付範圍是什麼時候？你如何決定哪些功能應該捨棄？