前言#

從管理一兩個人到管理一整個團隊，看似只是一小步，但管理一個團隊遠不止於管理個別成員。事實上，在這個層級之後的每一步，你都可能面對全然不同的要求與挑戰。職涯晉升中最難準備的事情，就是你將要做的事情會完全改變。儘管你可能認為管理是資深工程師技能的自然延伸，但它實際上是一整套全新的技能與挑戰。

以下是作者用於「管理一個團隊」這個角色的職位描述，她稱之為 Engineering Lead：

Engineering Lead 職位描述：

• 花較少時間寫程式，但仍參與小型技術交付（bug fixes、小功能），且不能阻礙或拖慢團隊進度
• 負責識別流程中的瓶頸與團隊成功的障礙，並加以排除
• 識別最具價值的專案，並讓團隊聚焦於這些專案
• 與 Product Lead 緊密合作，管理專案範圍並確保技術交付物按時完成
• 識別團隊的人力需求，規劃招募以填補缺口
• 是一位獨立的管理者，能管理與自己技能組合不同的團隊成員
• 清楚傳達期望，並頻繁地給予和徵求回饋（不僅限於績效考核期間）
• 擔任產品群組技術路線圖的領導者，清楚溝通時程、範圍與風險
• 識別策略性技術債，進行成本效益分析，並向管理團隊建議優先順序與時程

本章的主題是超越人員管理的工作。因為新任管理者容易過度專注於人事相關任務，作者希望將注意力拉回到管理團隊中更具技術性、策略性與領導力的面向。

保持技術能力#

這本書是為工程管理者寫的，而工程管理是一門技術學科，不僅僅是一套人際技能。隨著職涯發展，即使你不再寫程式，你的工作仍然需要引導技術決策。即使有架構師設計系統或其他資深技術人員負責細節，身為團隊管理者，你必須讓這些人為他們的決策負責，確保這些決策通過技術直覺的檢驗，並在團隊與商業的整體脈絡中取得平衡。多年累積的技術直覺對引導這個過程極為重要。

如果你真心希望贏得工程團隊的尊重，他們必須認為你在技術上是可信的。沒有 technical credibility，你將面臨一場硬仗。不要低估你的技術能力在成為成功的工程管理者過程中的價值。

為什麼要繼續寫程式#

• 親身感受痛點：你需要留在程式碼中，才能看到瓶頸和流程問題在哪裡。如果建置太慢、部署太耗時、on-call 是場噩夢，當你自己動手處理瑣碎的程式任務時，你會切身感受到這些問題。想像一下你的團隊成員有多沮喪！親身經歷過，才更容易識別技術債並優先處理它。
• 評估可行性：身為單一團隊的管理者，你會被要求幫忙判斷系統中什麼可以做、什麼不可以做。當產品經理提出瘋狂的想法時，如果你對系統有信心，就更容易評估該功能的實作難度（但要小心過度自信！）。優秀的工程管理者能識別出系統中實現新功能的最短路徑。
• 避免過早技術過時：在這個層級，如果你不留在程式碼中，你可能會在職涯中過早地讓自己在技術上過時。你可能走的是管理職涯路徑，但這不代表你應該完全放棄技術職責。

重點： 作者在 Engineering Lead 的職位描述中明確期望這個層級的管理者能實作小功能和修復 bug。

如果公司不提供「有一點時間寫程式的管理者」角色#

有些公司將管理和技術分軌分得太乾淨，管理者一開始就直接帶大型團隊，管理工作變成純粹的行政與人員管理。如果你的公司是這樣，作者的建議是：在你真正掌握了想學的程式撰寫和系統設計之前，先留在技術崗位上，然後再決定是否要轉入管理。停止寫程式後很難彌補失去的時間，如果太早停下，你可能永遠無法獲得足夠的技術素養來超越中階管理的角色。

不用擔心——在後面的章節中，作者會詳細討論在什麼時間點不再需要留在程式碼中。但在目前這個階段，試著至少保持一點參與。

診斷團隊失能：基礎篇#

有時你會發現自己管理的團隊是失能的——他們不斷錯過交付目標、成員不快樂、人員持續離職、產品經理感到沮喪、團隊對產品經理也感到沮喪。或者他們只是對工作缺乏活力，對當前的專案缺乏熱情。你能感覺到某些地方出了問題，但不確定到底是什麼。以下是幾種常見的團隊失能模式。

無法交付（Not Shipping）#

你可能不認為這是失能。也許你的團隊正在深入研究一個新問題。然而，即使是做研究的團隊，通常也有目標和交付物，即使只是初步發現。人類在設定小目標並定期達成時，通常會感覺良好。

身為團隊管理者，你可能擔心推得太緊，所以在他們錯過截止日期時不太計較。關鍵在於學習如何在推動團隊與適當退讓之間取得平衡。如果你仍在為團隊寫程式，這可能是捲起袖子幫助團隊達成交付物的好時機，或者深入研究正在落後的部分，與負責的工程師合作以了解狀況。

有時團隊無法交付，是因為他們使用的工具和流程讓工作難以快速完成。一個常見的例子是團隊只嘗試每週或更少頻率地釋出變更到生產環境。不頻繁的發佈可能隱藏了許多痛點：糟糕的發佈工具、高度手動的測試、功能太大、或開發者不知道如何拆解工作。

技巧： 發佈可以是資源爭奪的焦點。當人們在爭搶稀缺資源時，團隊成員之間的衝突和不滿幾乎是不可避免的。讓「交付程式碼」這個資源不再稀缺，可以立即改善團隊士氣。作者的經驗是，將每週一次的痛苦發佈改為每日發佈，對團隊產生了即時的正面影響。

人際問題（People Drama）#

有時我們會太久不放手那個「才華洋溢的混蛋」（brilliant jerk）——那個你認為不可替代的人，因為他產出驚人且聰明絕頂，但他不是團隊的好隊友，讓周圍所有人都不開心。較輕微的版本是那種愛製造戲劇性事件的人，沉溺於負面經歷，花太多時間在八卦和搞「我們 vs. 他們」的遊戲上。

你必須勇敢地在人際問題萌芽時迅速處理。可以向你的主管求助，特別是如果這是你第一次處理，但要意識到你的主管可能比你更難處理這個問題——她看不到對團隊動態的直接影響，她只看到一個能完成工作的人。

• 對於負面的人：明確告訴他行為必須改變，帶著具體的例子，在事情發生後迅速給予糾正性回饋。有時負面的人只是不開心，最好的做法是幫助他在友好的條件下離開團隊。其他時候，這個人並不知道自己對團隊的影響，一次快速的談話就足以遏制事件。
• 注意能量吸血鬼（energy vampires）：不要讓公開發表負面言論的人在你的團隊中保持那種心態太久。這類有毒的戲劇性事件即使是最好的管理者也難以對抗。最好的防禦就是積極出擊，快速行動至關重要。

過度工作導致的不滿#

這個問題通常比較容易解決，因為其根源通常是你可以處理的問題。

• 如果過度工作源於生產系統的不穩定：身為管理者，你的工作是放慢產品路線圖的步調，花一段時間專注於穩定性。建立明確的警報、停機時間和事故指標，並努力減少它們。建議在每次規劃會議中將 20% 的時間用於系統永續性工作（“sustainability” 而非常見的 “technical debt”）。
• 如果過度工作源於緊迫的時間限制發佈：第一，扮演啦啦隊長的角色。用各種方式支持團隊，特別是親自幫忙做工作。訂晚餐。告訴他們你感謝他們的辛勤工作。明確告知衝刺結束後會有明確的休息時間。有時候衝刺期可以成為團隊的凝聚體驗，但他們會記住在壓力期間，管理者是和他們一起還是在別處做自己的事。第二，盡一切可能從這次衝刺期中學習，避免下次再發生。如果可以就砍功能，如果日期真的不切實際就推回去。衝刺期會發生，但沒有理由讓它頻繁發生。

協作問題#

你的團隊與產品團隊、設計團隊或另一個技術團隊合作不順利，缺乏協作拖累了所有人。這裡沒有快速修復的方法，但展現改善協作的意願會有很大的幫助。

• 確保你與適當的同級定期接觸，共同解決問題
• 從團隊收集可操作的回饋，並就可能的改善進行有建設性的對話
• 不要在團隊面前貶低你的同級——即使你對他們感到沮喪，也要在公開場合保持正面和支持

如果你的團隊內部不能好好合作，可以創造一些不全是工作的共處機會：帶全團去吃午餐、週五下午提早下班一起參加有趣的活動、在聊天室鼓勵一些適度的幽默、問問人們的生活近況。即使大多數內向的人也希望與團隊有一種歸屬感。在沒有前述人際問題的前提下，在這方面的小小努力可以大幅溫暖團隊氛圍。

扮演保護傘的角色（The Shield）#

許多管理建議告訴新管理者，他們的工作之一是成為保護傘（shield，或不太客氣地說是 “bullshit umbrella”）——幫助團隊專注於需要完成的工作，不被公司中更廣泛的戲劇性事件、政治和變動所分心。

作者對此觀點有複雜的看法：

保護傘的價值#

不必要地暴露在與團隊無關的有毒戲劇中的團隊，確實容易分心和感到壓力。如果你管理的是工程團隊，他們不需要關心客服部門的人際衝突。幫助團隊理解他們可以且應該專注於能影響和改變的事情，忽略他們無法改變的事情，這很有價值。職場中的戲劇性事件通常只不過是滿足自我的消耗。

保護傘的限制#

然而，期望你能或應該為團隊遮擋一切是不切實際的。有時候讓一些壓力透過來傳給團隊是適當的。目標不是讓他們壓力山大，而是幫助他們了解正在處理的背景脈絡。

• 人類需要脈絡：極端的保護者認為他們可以透過給出清楚的目標來最好地聚焦和激勵團隊。但人類通常需要一些脈絡來了解為什麼這些目標被設定，以及他們正在解決什麼問題。如果十一月某個系統不上線就會有營運問題，你的團隊值得了解這個後果。適當的脈絡能幫助團隊做出好的決策，關於如何以及在哪裡集中精力。身為管理者，不是你一個人做所有決定。
• 不要否認外部事件的存在：如果公司其他部門發生裁員，而團隊從別人那裡知道而不是從你這裡，你非但沒有保護團隊免受戲劇性事件影響，反而製造了一個讓他們覺得有壞事發生但沒人願意承認的情境。如果你用直接、低情緒的方式溝通這類事件的資訊，你可以減少八卦並迅速中和對團隊的影響。

注意： 你可能是保護傘，但你不是父母。有時在結合保護傘和導師角色時，我們會和團隊形成類似親子的關係，把他們當作需要保護、養育和適時責備的脆弱孩子。你的團隊由成年人組成，需要被以適當的尊重對待。這種尊重對你的心智健康和他們的都很重要。當你把他們視為自己的延伸時，太容易把他們的錯誤當作個人問題，或者太情緒化地投入，把每個他們與你的分歧都當作是針對個人。

如何推動好的決策#

身為工程管理者，你在團隊決策過程中的角色是什麼？你可能有一位產品經理負責產品路線圖，有一位 Tech Lead 深入技術同時也在思考專案管理。那麼你，工程管理者，在哪裡？

你的責任比你預期的更大。雖然產品經理負責產品路線圖，Tech Lead 負責技術細節，但你通常要為團隊在這些元素上的進展負責。領導的本質是，雖然你可能只有引導決策而非獨裁的權力，但你仍會被根據這些決策的結果來評判。

建立數據驅動的團隊文化#

當你有產品或業務負責人時，她應該習慣使用關於業務、客戶、當前行為或市場潛力的數據來證明她的決定。開始在組合中加入其他數據，例如：

• 團隊生產力數據：完成功能所需的時間
• 品質指標：處理故障所花的時間、QA 或發佈後發現的 bug 數量

這些效率和技術數據點可以用於評估產品功能和技術變更的決策。

鍛鍊你的產品思維#

強大的領導力關心培養成功，並擁有一個交付成功專案的團隊。這意味著磨練你對客戶重要事項的理解。無論你是為外部客戶寫程式、為其他工程師開發工具，還是經營一個支援團隊，你都有某個群體依賴你的工作產出。把他們當作你的客戶。 花時間培養客戶同理心很重要，因為你需要給工程師們工作的脈絡。培養客戶同理心也能幫助你找出哪些技術領域對客戶有最大的直接影響，這個理解將引導你在哪裡投入工程精力。

展望未來#

你需要從產品和技術的角度提前想兩步。了解產品路線圖的走向有助於你引導技術路線圖。許多技術專案是基於它們能更容易地啟用新功能而獲得支持的——例如重寫結帳系統以插入 Apple Pay 等支付方式，或遷移到支援透過 WebSocket 串流資料變更的新 JavaScript 框架，以建立更互動的體驗。開始向產品團隊詢問未來可能的樣子，並花一些時間關注可能改變你軟體開發或運維方式的技術發展。

回顧決策和專案的結果#

討論你用來推動專案的假設是否真的成立了。重寫那個系統後團隊是否真的更快了？新增新功能後客戶行為是否如產品團隊預測的那樣改變了？你從 A/B 測試中學到了什麼？專案完成後很容易忘記回顧假設，但如果你把這變成你和團隊的習慣，你將始終從決策中學習。

進行日常流程的回顧#

敏捷流程通常在每兩週的開發衝刺結束時有一個 retrospective 會議，討論衝刺期間發生的事情，並挑選幾個事件——好的、壞的或中性的——進行詳細討論。無論你使用什麼方法論，定期的流程回顧對於偵測模式和強迫面對決策結果都有很大價值。團隊對需求的取得方式感覺如何？他們對程式碼品質感覺如何？這個過程幫助你了解你隨時間做出的決策如何影響團隊日常的運作方式。這種方法比收集團隊健康數據更主觀，但它可能比許多客觀指標更有價值，因為它來自團隊自身正在注意到並為之掙扎或慶祝的事情。

好管理者 vs. 壞管理者：衝突逃避者 vs. 衝突馴服者#

Jason 的故事（衝突逃避者）：

Jason 的團隊過度工作。所有人都知道 Charles 應該在做大型系統重寫，但他已經在自己的寵物專案上待了好幾個月。在聽到 Charles 沒有幫忙做新系統的抱怨後，Jason 召集團隊投票決定應該放棄哪些專案來減輕工作量。毫不意外，他們投票放棄了 Charles 的寵物專案——除了 Charles 本人毫不意外，因為 Jason 從未告訴過他，而他一直以為自己在做正確的事。

Jason 的團隊感到壓力很大，部分原因是 Jason 似乎不會為他們向其他團隊挺身而出。他討厭拒絕新專案，但也不要求增加人手來管理工作量。結果，團隊過度工作、難以排定前進的優先順序，成員之間積攢了好幾個怨恨。

Lydia 的故事（衝突馴服者）：

Lydia 的團隊也感到壓力，她也有自己的 Charles 需要處理。她曾承諾 Charles 會有時間做那個專案，但很明顯優先順序已經改變，所以他的工作也需要跟著改變。在與 Charles 的 1-1 中，Lydia 解釋了當前的工作量，並告訴 Charles 團隊需要他幫忙做系統重寫。Charles 不高興，Lydia 也不喜歡這個對話，但她知道身為團隊管理者，她有責任確保團隊聚焦在最重要的專案上。

Lydia 知道這個專案對團隊很重要，所以在爭取更多人手的同時，她確保團隊了解她為什麼決定承接這個大專案。她和團隊一起排定工作優先順序，並透過建立呈現選項和徵求回饋的結構來引導他們解決技術選擇的分歧。Lydia 的團隊形容她嚴格但公正，雖然分歧會發生，但團隊善於度過挑戰並且協作良好。

分析#

雖然 Jason 的民主風格看起來應該產生一個有權力感的團隊，但他無法說不或為任何決策承擔責任意味著沒人感到安全。在 Jason 的團隊裡很難知道接下來會發生什麼，因為他不是在引導團隊，而是讓團隊自己引導自己。

團隊成員不斷爭吵和意見不合確實很痛苦且可能非常失能。但存在一種叫做虛假和諧（artificial harmony）的東西，而衝突逃避型的管理者傾向於偏好和諧而非功能性的工作關係。為分歧創造一個安全的環境讓它自行解決，遠比假裝所有分歧都不存在要好得多。

管理衝突的 Dos and Don’ts#

Don’t：不要完全依賴共識或投票

共識看起來有道德權威性，但這假設所有參與投票的人都是公正的、對各種結果有平等的利害關係、且對背景脈絡有同等的了解。這些條件在每個人有不同專業水平和不同角色的團隊中很少被滿足。就像團隊投票否決了 Charles 的工作一樣，共識可能是殘忍的。不要讓人們為你知道會失敗的投票做準備，而不是自己承擔傳達壞消息的責任。

Do：建立清楚的流程讓決策去個人化

當你想要允許群體決策時，群體需要有一套清楚的標準來評估決策。從對目標、風險和需要在做決定前回答的問題的共同理解開始。當你將決策的所有權分配給團隊中的某人時，明確說明哪些團隊成員應該被諮詢回饋，以及誰需要被告知決策或計畫。

Don’t：不要對醞釀中的問題視而不見

衝突逃避的另一個表現是無法在問題持續太久之前加以處理。身為管理者，如果你在績效考核中給予負面回饋，這不應該讓你的員工大吃一驚。如果有人的工作存在重大問題，那個人應該在你注意到的時候就知道。如果你自己沒有注意到這些問題，而是在考核過程中透過多位同事的回饋才得知，這不是好兆頭——這可能表示你沒有在關注，也沒有在 1-1 中留出空間讓團隊討論他們與同事之間的問題。

Do：在不引發戲劇性事件的情況下處理問題

處理衝突和培養失能之間有區別。你要讓人們有空間表達挫折感，但要注意區分發洩和真正的人際問題。運用你的判斷力來決定什麼該處理、什麼該放下。要問的關鍵問題是：這是持續性的問題嗎？這是你個人注意到的嗎？這是團隊中很多人都在掙扎的事情嗎？是否存在權力動態或潛在的偏見在起作用？目標是識別導致團隊協作效率下降的問題並加以解決，而不是成為團隊的心理治療師。

Don’t：不要把氣出在其他團隊上

諷刺的是，衝突逃避型的管理者在面對其他團隊時往往會尋求衝突。他們強烈認同自己的團隊，會對他們認為來自外部的威脅做出積極反應。當出事時，管理者變成霸凌者，要求為他的團隊伸張正義，或把問題怪罪到其他團隊頭上。有時候，這種行為是管理者對自己團隊壓抑情感的一個出口。正如一位朋友所說：「我沒有告訴我的人他們需要改進的那 10%，因為我害怕他們會忽略做得好的那 90% 的訊息，所以我把對責任的渴望發洩在其他團隊身上。」

Do：記得保持善良（kind）

想被人喜歡是自然且完全人性的。我們許多人相信被喜歡的方式是被認為是 nice（客氣的）。但你身為管理者的目標不應該是 nice，而應該是 kind（善良的）。Nice 是禮貌社交的語言；Kind 則是更深層關係的語言。

• 告訴一個還沒準備好升遷的人她還沒準備好，並用她需要做的工作來支持這個說法——這是 kind
• 引導那個人說「也許你可以升遷」，然後看著她失敗——這是 unkind
• 告訴某人他在會議中的行為正在干擾團隊——這很尷尬、不舒服，但這是你作為管理者工作的一部分

Don’t：不要害怕

衝突逃避往往源於恐懼——害怕承擔決策的責任、害怕顯得太苛刻、害怕人們會在收到不舒服的回饋後離職、害怕不被喜歡、害怕冒險失敗。一些恐懼是自然的，對衝突結果的敏感是一個明智的習慣。

Do：保持好奇心

思考自己的行為是對抗衝突恐懼的最好方法。問問自己：

• 我是因為團隊真的是最適合做決定的人，才把決策推給他們的嗎？還是我只是害怕如果我做了一個不受歡迎但必要的決定，人們會對我生氣？
• 我是因為這位同事真的很難合作，才避免和她討論這個問題的嗎？還是我只是希望問題會自行解決，因為我不想討論並可能犯錯？
• 我是因為他真的只是那天狀態不好才是一次性事件，才不給員工回饋嗎？還是我是因為害怕他不喜歡我這個管理者才不說？

對自己的行為保持思考，就不太可能去尋求不必要的衝突。

挑戰性情境：團隊凝聚力的破壞者#

建立功能性團隊的關鍵要素之一，是建立一個合作愉快的團隊。有一個測試快樂工程團隊的方式：「如果你晚上幫他們買披薩，他們會留下來一起社交，還是會盡快衝出門？」

當然，這個測試有其缺陷——有固定下班時間義務的員工不一定比願意留下聊天的人更缺乏投入感。但更大的論點仍然成立：大多數凝聚力好的團隊都有一種同袍情誼，讓他們一起開玩笑、喝咖啡、共進午餐，彼此之間感覺友好。

真正的目標是心理安全感（psychological safety）——一個團隊成員願意在彼此面前冒險和犯錯的團隊。這是一個成功團隊的基石。凝聚團隊的工作始於創造帶來心理安全感的友好氛圍。你可以透過花時間把人當作人來認識、詢問他們工作以外的生活和興趣來鼓勵這一點。這不僅僅是空洞的寒暄——它培養歸屬感（relatedness），讓人們被視為個體而不只是匿名的齒輪。

這就是為什麼破壞團隊凝聚力的人如此棘手。他們幾乎總是以一種讓團隊其他人覺得不安全的方式行事。我們稱這些員工為「有毒的」（toxic），因為他們傾向於讓接觸到他們的每個人都變得更低效。快速處理他們是良好管理的重要部分。

才華洋溢的混蛋（The Brilliant Jerk）#

才華洋溢的混蛋產出個人超高成果，但自我驅動到在幾乎所有人周圍製造恐懼和反感。這種人的挑戰在於她很可能長期因為她的才華而被獎勵，她像救命稻草一樣緊抓著它。承認世界上有超越純粹智力或生產力的價值，會挑戰她在世界中的位置，這對她來說往往是個可怕的命題。所以她用智力來霸凌，以刺耳的方式壓制異議的聲音，無視她認為不如自己的人，公開流露她對任何她認為愚蠢的事物的挫折感。

重點： 避免才華洋溢的混蛋症候群的最好方法就是根本不要雇用他們。一旦被雇用，擺脫才華洋溢的混蛋需要一種不常見的管理信心。

處理才華洋溢的混蛋的關鍵策略：

• 簡單且公開地拒絕容忍不當行為。這可能是少數幾個「公開表揚，私下批評」原則需要被打破的情況。當一個人的不當行為對團隊有明顯的影響，且你不希望你的文化模仿這種方式時，你需要在當下說些什麼來明確標準。例如：「請不要用那種方式對人說話，這是不尊重人的。」
• 你需要嚴格控制自己的反應，因為在公開場合傳達這種回饋是走鋼索。如果你顯得情緒化，可能會削弱你的權威。保持中立但切中要點。
• 這種方法只應用於你認為對整個團隊有害的行為。如果你只是覺得這個人在私下削弱你個人，那就私下討論。你的首要目標是保護整個團隊，第二是保護團隊中的每個個人，最後的優先順序才是保護你自己。
• 預期她會全力反擊所有回饋。如果她不認為自己的行為是問題，她就不會改變。世界上所有的證據都無法改變一個不想改變的人。

不溝通者（The Noncommunicator）#

另一個非常常見的問題團隊成員是不溝通者——那個對你、隊友和產品經理隱藏資訊的人。他偏好秘密工作，在一切完美之前才揭曉一個神奇的專案。他不想經過 code review，也不在大型專案上要求設計審查。他不與隊友討論，而是直接 revert 他們的 commit 或拿走他們的 ticket 自己做。

身為管理者，你必須盡快遏制這種資訊隱藏的習慣。如有必要，明確告訴他，他沒有達到工作期望。這通常是恐懼的徵兆——這個人害怕被發現不足，或害怕被要求做他不感興趣的工作。有時候這是一個覺得自己應該有更多責任、不尊重管理者的人的徵兆。

如果可能，處理隱藏行為的根本原因：

• 如果隱藏者害怕被批評，你的團隊是否有需要被處理的嚴苛文化？
• 你的團隊整體是否具備心理安全感？
• 團隊其他成員是否把這個人當作局外人對待，也許是因為他有不同的背景或技能組合？
• 如果團隊在排斥這個個人，你需要決定是嘗試糾正團隊還是將個人轉到另一個團隊

缺乏尊重的員工#

第三種有毒的個體是簡單地不尊重你身為管理者，或不尊重她的隊友的人。處理這個人會很困難，你可能需要管理者的幫助。簡單來說，如果你的團隊成員不尊重你或她的同事，她為什麼還在這裡工作？

問她是否想繼續在你的團隊工作。如果她說想，清楚且冷靜地列出你的期望。如果她說不想，開始轉調到另一個團隊或幫助她離開公司的流程。

注意： 你不能讓一個不尊重你或不尊重團隊的人為你工作。這會侵蝕團隊其餘成員的凝聚力，因為他們會開始懷疑那個人不尊重你是否是正確的。越早撕下 OK 繃越好。

進階專案管理#

身為工程管理者，你將幫助設定團隊的時程。當更大的組織試圖弄清楚季度或年度的計畫時，你將估計你的團隊是否能做某些專案、這些專案需要多少工作量、以及你是否有合適的人來完成工作。組織期望你能做到即興估算和更具體的專案規劃。

第三章高層次地概述了專案管理，但現在作者想深入一些進階工作。身為團隊管理者，雖然你可能將部分專案規劃推給 Tech Lead，但你很可能需要自己做一些。你可能需要決定承接哪些專案、何時推回去拒絕專案，以及你可能被要求對工作完成時間給出粗略估計。

你需要對團隊的節奏和步調有很強的感覺，才能成功管理他們的工作量。

專案管理經驗法則#

這些都不能替代敏捷專案管理

作者不是建議你進入 waterfall 模式，從一開始就詳細規劃每個專案。然而，大多數團隊既有高層次的長期目標，也有短期的目標來幫助實現這些目標。對於實際規劃較小的部分，團隊協作分工和粗略估計的敏捷流程在日常組織中非常有效。身為管理者，你不是要打亂或擁有那部分執行過程。然而，你要為更大的圖景負責——以月而非週來衡量的成就——這就是你需要開始進行更高層次規劃的地方。

每位工程師每季度有 10 週的有效工程時間

一年有 52 週，每季度約 13 週。然而，現實中你的團隊會失去很多時間。假期、會議、考核季、生產事故、新員工入職——所有這些都會佔用專注時間。不要期望每位團隊成員每季度能在主要專案上投入超過 10 週的專注工作。Q1（冬季假期剛過）通常是最有生產力的，Q4（包含冬季和年終假期的季度）通常是最沒有生產力的。

全面預留 20% 的時間用於一般性維護工程工作

所謂「一般性維護工程工作」包括：測試、除錯、清理遺留程式碼、遷移語言或平台版本，以及其他必須進行的工作。如果你養成這個習慣，你可以用它來每季度處理一些中型的遺留程式碼並獲得不錯的改善。持續清理系統可以保持系統的易用性，讓團隊在新功能上持續前進。最壞的情況下，你可以用這個緩衝來平滑功能開發中意外的延遲。但如果你把時程表 100% 填滿功能開發，預期功能開發會因為過度排程而迅速放慢。

當截止日期臨近時，說不是你的工作

你幾乎肯定會有偶爾的截止日期，無論是你自己設定的目標日期還是從上面下來的。達成這些目標的唯一方法是在專案尾聲砍範圍。這意味著你，身為工程團隊負責人，將與你的 Tech Lead 和產品負責人/業務代表合作，弄清楚哪些「必須有」其實並非真正的必須有。你將需要向雙方說不：

• 有時工程團隊會說他們不可能在沒有做某些其他技術工作的情況下實現某個功能——你需要判斷何時推動一個 hack 實作，何時堅持正確的實作
• 有些產品功能需要顯著的工程複雜度來實現——你需要與產品團隊合作，弄清真正的必須有項目，同時解釋達到他們願景的成本

使用加倍法則做快速估計，但為較長的任務爭取規劃時間

軟體估算中流行的加倍法則是：「當被要求估計時，把你的猜測乘以二。」這個法則適合用於即興的猜測。然而，當你談論的是你認為會超過幾週的專案時，加倍估計但要明確表示你需要一些規劃時間才能確定時程。有時較長的任務會花費遠超過你估計的兩倍，花一些時間更仔細地規劃再讓團隊承諾一個大型的未知專案是值得的。

對帶給團隊估計的事項要有選擇性

強調你在估算和規劃過程中的角色，部分原因是一個不斷要求隨機專案估計的管理者對工程師來說是令人分心和有壓力的。身為管理者，你有責任處理不確定性，並限制你讓團隊接觸到多少不確定性。不要成為工程師和公司其他部分之間的傳聲筒，來回轉達訊息並分散正在忙於你已經承諾的重要任務的人。但你也不是黑洞。試著建立一個團隊層級的流程來討論新功能和客戶投訴，並限制在此流程之外發生的估算。

自我評估#

• 你成為團隊管理者後有哪些新職責？你停止做了或交接了哪些任務來為這些新職責騰出時間？
• 你對團隊日常撰寫、部署和支援程式碼的挑戰了解多少？
• 你的團隊多頻繁地將工作標記為已完成？
• 你上次寫一個功能、除錯一個問題、或與團隊成員配對處理他們遇到困難的程式碼是什麼時候？
• 團隊中是否有一兩個人造成了大部分的負面影響？你有什麼計畫來解決這個問題？
• 你的團隊成員之間是否有互動？他們在會議中會笑嗎？在聊天中開玩笑嗎？一起喝咖啡或吃午餐嗎？你們上次不談工作地坐在一起是什麼時候？
• 你的團隊如何做決策？你是否有分配決策責任的流程？哪些決策你認為自己有責任做？
• 你上次回顧一個已完成的專案看看它是否達到了目標是什麼時候？
• 你的團隊對於他們為什麼在做目前的專案理解得多好？
• 你上次砍專案範圍是什麼時候？你用什麼來決定砍哪些部分？