快速答案： 優秀的工程經理（EM）靠三件事撐起團隊產出：擁抱策略性思維而非被動反應、建立可持續優化的工程產出迴圈、認真對待回顧會議並用 AI 工具把回饋轉成行動。這三者環環相扣——少了任何一個，團隊都會陷入低效與信任流失的惡性循環。
文章同步發表在 我們的部落格
你可能還在寫你人生第一支迴圈，甚至剛搞懂什麼是變數。但如果你正在轉職走向科技業，這篇文章你一定要看完。為什麼？因為你未來的主管——那個決定你要做什麼、什麼時候上線、你的程式碼會不會被砍掉重寫的人——就是工程經理（Engineering Manager，簡稱 EM）。了解他們怎麼思考，你就更懂怎麼在團隊裡生存、發光,甚至有一天，換你來當那個角色。
工程經理的責任很簡單，也很殘酷：把團隊的產出，準時、可靠地交付出去。聽起來像廢話？並不是。多數新手 EM 一上任就搞砸這件事，不是因為技術不夠，而是因為心態走偏了。這篇文章會帶你看懂三個支柱——策略性管理、工程產出迴圈、回顧會議——以及如何用 Claude AI 把最後一塊拼圖做得更好。
先講一個真實案例。
Dan 剛加入 Reddit 的 Infrastructure 團隊，負責一個高能見度、高價值的服務穩定性問題。他做了一件「看起來很對」的事：排了一堆會議，跟所有利害關係人聊需求。
問題出在哪？他把每個人的請求都照單全收。
會議越開越多，Infrastructure 團隊本來就要對接各種部門，Dan 為了讓每個人滿意，單方面承諾了一個根本不可行的路線圖——完全沒考慮技術上做不做得到，也沒問過自己的團隊一句話。
結果呢？團隊焦點被切得四分五裂，工作範疇沒定義清楚，交付日期一延再延。Dan 的主管和利害關係人，開始不信任他能把事情做完。
這就是所謂的反應式狀態——低脈絡、當下反應、見招拆招。這種模式對消防員、急診醫生、客服人員來說是必要的生存技能。但對工程經理來說呢？完全走偏了。
答案是：優先順序打架，打得太兇。
來自團隊內部的壓力包括：
來自團隊外部的壓力也不少：
新手 EM 剛上任，還在適應角色，容易被壓垮。資深 EM 也不能倖免——組織重組、升級事件、OKR 臨時改變，隨時都能把人打回反應式狀態。
反應式狀態會把你推向兩條死路。第一條：你不再策略性地分配精力，開始為了討好某個高層而接下不對齊團隊目標的工作。第二條：壓力會擴散到整個團隊——你自己疲於奔命，團隊因為工時不穩定而累積負面情緒，時程因為半路塞進新工作而崩潰。最後，衝刺目標一個接一個沒達成，交付變得不可靠。
不是最快，也不是最完美。是可靠。
正如專案協作者 Nick Caldwell 所說：「工程經理的角色，就是配置團隊資源，以可預測的節奏和可理解的品質水準達成既定目標。而最優秀的工程經理，能在確保團隊開心且合作良好的前提下做到這一點。」
速度和品質早就被預先設定好了。EM 真正要對齊的，是按時、按規格交付——這樣其他團隊才能靠著你的產出，去完成他們自己的目標。
既然反應式狀態跟這個核心目標互相矛盾，答案已經很清楚：EM 必須策略性思考，而不是被動反應。那些看似衝著你來的優先事項，並不會消失——它們只是要被重新排進你的核心目標之下，而不是輪流插隊。
而要把策略性思考落地，你需要一個系統。這個系統，叫做工程產出迴圈。
工程產出迴圈由五個環節組成：
舉個具體例子：假設 EM 和 PM 決定要在 Chrome 瀏覽器裡支援 Grammarly，第一個衝刺要處理四張 JIRA 卡片。資源分配就是把這四張卡分給兩位曾經做過 Safari 版本的工程師。追蹤就是把卡片從看板的 backlog 拉進「進行中」欄位。簽核交付就是通過 code review 和內部驗收後上線。回顧就是回頭看看有什麼意外、有什麼學到的教訓,並把這些洞察餵回下一輪開發。
聽起來很行政、很無聊,對吧？很多新手 EM 也是這麼想的——這正是問題所在。
把它們當成一條線性流程，你只能靠時間累積換來一點點進步——就像背單字一樣,熟能生巧,僅此而已。
但優秀的 EM 看到的是不一樣的東西：這五個環節互相連動。一個環節變好,其他環節也會跟著變好。
舉例來說：當工程師被邀請參與工作攝入的過程,他們能更早看出哪些任務最適合自己的技能。結果是什麼？資源分配變輕鬆了,工程師的投入度也提高了,因為他們正在做自己擅長的事。投入度一高,交付準時率就跟著上升。
而回顧,往往是這個迴圈裡最容易被低估、卻威力最大的環節。舉個例子：某次回顧中,團隊發現某位工程師總是提早完成任務,結果卡在那裡等兩天才能配合產品發布排程上線。這個發現直接指出兩個可能的改進方向——加大未來任務的範疇,或是調整 Scrum 排程去對齊產品發布週期。
一次回顧,推動了整個迴圈的下一輪運轉。這就是為什麼,回顧不是迴圈裡「可有可無」的最後一步——它是推動整個迴圈往前轉的那個引擎。
先說結論：回顧會議的投資報酬率,比你手上幾乎任何其他活動都高。
但你可能會想,回顧不就是那種「大家隨便講講感想」的例行會議嗎？很多團隊確實是這麼用的——結果就是被跳過、被取消、或草草了事。
問題出在哪？回顧本身有個矛盾：大家嘴上說它有價值,實際上卻把它當成「非必要」、「可有可無」,甚至「重複又無聊」的雞肋。最糟的情況是,回顧沒有明確結論,參與度逐漸下滑,變成另一場讓人疲乏的會議。這也是為什麼 EM 自己常常會找理由取消回顧,像是「時間拿去趕工比較實際」或「這次沒什麼好講的」。
這是個代價高昂的誤解。回顧的價值,遠不只是「蒐集回饋」這麼簡單。
回顧有四層價值：
如果回顧被跳過,這些價值全部一起消失。沒被說出口的回饋不會憑空消失,它會變成怨氣,慢慢侵蝕團隊的凝聚力。就像一座花園——用心澆灌,能收穫滿滿；放任不管,雜草會吃光整塊地。
Heidi Williams(專案協作者)講得很直白:「如果 Scrum 裡的儀式只能留一個,留下回顧,其他都可以砍。」
第一類是產出——這次交付了什麼?問題包括:「這個週期我們有沒有交付承諾的東西?」「規劃和實際交付之間,哪些假設變了?」
第二類是流程——團隊是怎麼運作的?問題包括:「你的工作分配,是否符合你對工程、產品、公司目標的理解?」「交付完成到正式上線之間,有沒有結構性的卡點?」
第三類,也是最常被跳過的一類,是路線圖——接下來要往哪走?問題包括:「根據這次的工作經驗,你會怎麼調整未來的時程估算?」「你最想在接下來的衝刺裡做什麼?」
多數 EM 能做到第一類,不錯的 EM 能做到第二類。但只有真正優秀的 EM,會把第三類也做到——因為工程師手上握有關於未來工作可行性的第一手資訊,而回顧正是他們能安全地把這些洞察直接反饋給 PM 的唯一場合。
蒐集回饋只是第一步。真正困難的,是把回饋變成行動——而這一步,幾乎所有團隊都會搞砸。
Nick Caldwell 分享過一個真實故事:他在 Looker 工作時,直接刪掉了 Jira backlog 裡累積將近五年的改進想法,而且沒有任何人發現。「裡面有好幾萬條,我全刪了。因為那根本就是一份永無止盡的願望清單,幾年前寫下來,從來沒人碰過。」
問題就叫做燙手山芋陷阱:問題被提出來了,卻沒有人真正擁有它。
要避免這個陷阱,每一條回饋都要強制指定三個參數：
下一步行動——「不採取行動」用來篩掉不可行的回饋；「下個週期就改」用來立即處理;「策略型專案」用來標記需要長期投入的結構性問題。
負責人——盡量指派給工程師,提升參與感;策略類回饋交給 PM,讓團隊回饋真正影響產品路線圖;只有純管理性任務才留給 EM 自己。
檢查點——「衝刺規劃」用於立即生效的戰術性改變;「下次回顧」用於需要一個週期驗證的行為調整;「策略檢視」只保留給真正的策略型專案。
這正是 Claude AI 能大幅提升效率的地方。與其讓 EM 一個人在會議後手動整理逐字稿、分類回饋、追蹤進度,你可以把回顧會議的討論內容交給 Claude,讓它:
這不是要取代 EM 的判斷,而是把「整理與追蹤」這種消耗心力卻不需要創意的工作,交給 AI 去做——讓 EM 能把時間留給真正需要人類判斷的部分:誰該負責、優先順序怎麼排。
會議前,提醒團隊先花幾分鐘思考這次週期的產出、流程、路線圖三個面向,別讓回顧變成臨場硬擠想法。
會議中,建議這樣分配時間:
用固定的格式反覆進行,能讓團隊養成「習慣性提出回饋」的能力,而不是每次都要臨場擠靈感。搭配像 Retrium 或 Miro 這樣的協作工具,加上 Claude AI 整理討論紀錄,回顧就能從「大家隨便聊聊」升級成一套真正驅動改進的機制。
還有最後一件事:千萬不要取消回顧。持續性才是參與度和價值的根本。如果某些人固定不出席,私下處理;如果整體參與度下滑,想辦法為這個儀式注入一點新鮮感,而不是直接砍掉。
看到這裡,你應該發現這三個支柱根本不是三件獨立的事。
策略性思維讓你不再被動地滿足每個人的要求,而是把所有壓力重新排進「可靠交付」這個核心目標之下。工程產出迴圈,是把這個策略具體落地成五個可執行、可優化的環節。而回顧會議,則是整個迴圈裡讓改進持續發生的引擎——少了它,迴圈只能靠時間慢慢磨,而不是真正加速轉動。
如果你正走在轉職進科技業的路上,現在不需要馬上把這些原則套用到管理團隊上。但了解「你未來的主管在想什麼、在意什麼」,能讓你更快看懂團隊運作的邏輯——為什麼你的任務被這樣分配,為什麼回顧會議要認真開,為什麼「按時交付」比「做到完美」更被看重。
而如果有一天,你也想從工程師走向管理職,現在就是最好的起點:別等到變成 Dan 才發現,反應式的好意,救不了一個失去焦點的團隊。
工程經理和工程師的角色有什麼不同?
工程師負責技術實作,而工程經理負責配置團隊資源,確保工作以可預測的節奏、可理解的品質水準交付。工程經理是唯一直接對「團隊產出」負責的人。
為什麼回顧會議常常被取消?
因為回顧被誤解為「只是蒐集回饋」的行政流程,一旦某個週期看起來很順利,團隊就容易覺得沒什麼好講,進而選擇跳過。但回顧還有團隊凝聚、賦權工程師表達路線圖意見等更深層的價值,取消回顧等於直接放棄這些好處。
Claude AI 在回顧會議裡具體能做什麼?
Claude AI 可以協助整理討論內容、將回饋自動歸類成產出、流程、路線圖三大類,找出重複出現的模式,並依照「行動、負責人、檢查點」的格式草擬行動項目,減少會議後手動整理的負擔。
新手工程經理最常犯的錯誤是什麼?
最常見的錯誤,是為了討好每一位利害關係人而全盤接受所有請求,卻沒有評估團隊的技術可行性。這會導致團隊焦點分散、時程失控,最終喪失利害關係人與管理層的信任。
工程產出迴圈裡,哪個環節最容易被忽略?
回顧。它常被當成迴圈裡最不重要的最後一步,但事實上它是驅動其他四個環節持續改進的關鍵環節。
iThome鐵人賽
看影片追技術