快速解答： 工程管理不是「升職加薪」那麼簡單的一件事。優秀的工程主管(EM)要同時做好四件事——管理產出、管理利害關係人、管理團隊、管理自己——才能穩定交付有價值的軟體。就算你現在只是一個人用 Claude AI 打造產品,這四個角色你也早就在扮演了,只是還沒有人告訴你,這其實就是工程管理。

文章同步發表在 我們的部落格

你有沒有想過,為什麼公司不讓最強的工程師直接指揮所有人?

答案很反直覺:寫程式寫得好,跟帶好一個團隊,是兩種完全不同的能力。 前者靠的是技術直覺,後者靠的是系統思考。而多數公司,偏偏習慣把最會寫程式的人,直接推上管理職。

我們的專案協作者 Heidi Williams(現任 Grammarly B2B 與平台工程主管)講過一句話,點出了問題的核心:「大家常常有一種印象,覺得公司應該由產品主導,工程只是負責執行。但說到底,真正決定『功能怎麼蓋出來』的人,是工程師。」

工程團隊,是把想法變成產品的「執行者」。但誰來確保這群執行者,把力氣花在對的地方、用對的節奏交付?這正是工程管理存在的理由。這篇文章,會帶你走過工程管理的基本功——不管你未來要帶一整個團隊,還是像現在這樣,一個人搭配 Claude AI 生態系打造軟體產品,這套邏輯都用得上。

工程主管到底在做什麼?為什麼技術強不等於帶得好?

先講結論:工程主管的核心任務,不是寫程式,是交付「可預期、有影響力」的產出。

我們的另一位協作者 Nick Caldwell(Twitter Core Tech 總經理)是這麼定義的:「工程主管的角色,是組建一支團隊,以可預測的節奏、可理解的品質水準,交付既定目標——也就是產品與服務。」

聽起來抽象?換個角度想。公司裡有三層人:高階主管負責定方向,個人貢獻者(IC)負責寫程式,而工程主管卡在中間——確保 IC 的產出,真的能對齊高階主管的方向,並且準時交付。少了這一層,公司要嘛方向亂飄,要嘛技術團隊變成一群各做各的散兵。

你可能會想:那工程主管是不是就是「傳話的人」?

不是。Two Sigma 董事總經理、Rent the Runway 前技術長 Camille Fournier 講得很直白:「矽谷不少新創,對『管理』和『層級』有很負面的反應,覺得那很官僚、浪費時間……但好的管理,其實是讓工程團隊真正發揮效能、讓公司真正運轉起來的關鍵一環。」

從工程師轉任管理,最卡的一關是什麼?

多數工程主管,是從表現優異的工程師一路升上來的。問題來了——一旦走上管理路線,他們就不再親手寫程式,而是負責打造「寫程式的團隊」。

Pilot 創辦人暨技術長 Jessica McKellar 形容過這個轉折點:「從工程師轉成主管,會有一個轉捩點,那種感覺很不舒服——好像你整天都在開會,什麼實質的東西都沒完成。」

這種不適感,不是你的問題。是角色本身變了。

Claude AI 能在文件與知識管理上幫上什麼忙?

工程主管的另一個隱形負擔,是團隊知識的保存與傳遞——技術決策紀錄、新人上手文件、跨團隊溝通紀要,樣樣都要有人整理。

這正是 Claude AI 能派上用場的地方。你可以把會議逐字稿、技術討論串丟給 Claude,請它幫你草擬決策紀錄、整理成新人看得懂的入職文件。這能省下大量手動彙整的時間——但要不要採納某個技術方向、怎麼跟團隊解釋這個決定背後的取捨,終究得靠你自己判斷。

怎麼打造並帶領一支真正高績效的團隊?

一個好用的框架很簡單:招募對的人、養成學習的文化、建立心理安全感、定義清楚的目標。 少一個,團隊都跑不遠。

• 招募與新人融入:找到技術能力與團隊文化都合適的人,再用結構化的方式幫他們快速上手。
• 持續學習的文化:鼓勵團隊嘗試新技術、新做法,而不是每天只解決眼前的火。
• 心理安全感:讓工程師敢說「我不知道」、敢在會議上提出反對意見,而不是悶著頭猜主管想要什麼答案。
• 清楚的目標:每個人都該知道,自己手上的工作,怎麼連結到公司的整體方向。

你可能會想:這些不是老生常談嗎?

沒錯,道理很簡單。難的是持續做到。多數團隊的問題,不是不知道這些原則,是每天被緊急任務追著跑,根本沒空落實。

為什麼功能上線不是終點,而是溝通的起點?

功能上線那一刻,工作才剛開始。

新手最常犯的錯,是把上線當成慶功的時間點,然後轉頭去忙下一個功能。但上線後的數據、用戶反饋,才是真正檢驗這個功能值不值得做的證據。

有效的上線後溝通,需要做到三件事:

• 把上線結果,轉化成能推動下一步行動的具體洞察——不是只丟一張數據截圖
• 主動跟產品、工程、領導層對齊——不同角色關心的數字不一樣,講法也該不一樣
• 管理好各方的期待——上線初期數據不好看,不代表功能失敗,可能只是還沒觸及對的用戶

怎麼主持一場真正有用的專案復盤?

先問自己一個問題:你的上一場復盤會議,真的改變了什麼嗎?

如果答案是「沒有」,問題通常出在準備不夠。一場有價值的復盤,不是走流程,是逼團隊誠實面對哪裡做對了、哪裡做錯了。

準備階段,你該做的事包括:

• 提前彙整這次專案的關鍵數據與時間軸,別讓與會者臨場才第一次看到
• 準備幾個開放式問題,引導大家說出真正的想法,而不是官腔式的「都很順利」
• 營造一個安全的討論空間,讓團隊敢講出不好聽的真話

這裡,Claude AI 能幫你分擔不少資料整理的工作——把散落的績效報告、團隊回饋丟給它,請它幫你彙整重點、標出矛盾之處,甚至草擬復盤會議的討論大綱。這能把你原本要花上大半天整理的工作,壓縮到一小時內完成。

但真正把復盤結論,轉化成具體、可執行的改進行動——這一步,沒有人能替你做。誠實面對團隊的優缺點,然後拍板下一步該怎麼調整,永遠是你的責任。

怎麼用數據,決定下一步該優化、重做,還是放手?

上線後的數據,不會自己告訴你答案。你得問對問題。

分析數據時,先看兩件事:上線指標(用戶有沒有用、用得順不順)和用戶反饋(他們喜歡什麼、卡在哪裡)。把這兩者放在一起看,你才能判斷,這個功能是值得繼續投資優化,還是該考慮重新設計,甚至乾脆下架。

決定路線圖優先順序時,把復盤學到的教訓真正放進考量——別讓上一輪的錯誤,在下一輪原封不動地重演。

Claude AI 在這一步,最擅長幫你從大量數據裡抓出模式——例如哪個用戶群的留存率特別低、哪個功能區塊的操作路徑特別容易卡關。把這些模式攤在你面前之後,決定「這代表什麼」「該怎麼回應」——這個判斷,還是得靠你。

管理,是一套系統,不是一份待辦清單

走到這裡,你應該已經看出一件事:工程管理的成功,不是靠單一技巧,是靠領導力、技術判斷力,加上不斷迭代的習慣,三者疊加出來的結果。

上線後的復盤,才是真正學習發生的地方——不是上線那一刻的掌聲。而真正厲害的工程主管,懂得把每一次的數據和反饋,轉化成整個組織都能沿用的知識,而不是只留在自己腦子裡。

就算你現在還沒有帶團隊,只是一個人搭配 Claude AI 生態系打造自己的第一個軟體產品——這套邏輯依然成立。你同時扮演著工程主管、產品經理、工程師三個角色。搞懂每個角色該做什麼判斷,你就已經走在對的路上了。

下次你的功能上線之後,別急著往下一個任務衝。先問問自己:我真的聽懂用戶在說什麼了嗎?我把這次學到的教訓,寫下來了嗎?

常見問題

完全沒有管理經驗,能直接當工程主管嗎?
可以,但需要心理準備。多數工程主管都是從資深工程師直接升任,一開始都會經歷「不再親手寫程式」的不適應期。重點是理解,管理的產出,是團隊的成果,不是你個人的程式碼。

一個人用 Claude AI 打造產品,也需要學工程管理嗎?
需要。就算只有你一個人,你依然同時扮演工程主管、產品經理、工程師三個角色。搞懂工程管理的邏輯,能幫你避免漏掉關鍵的判斷步驟,也能讓你更清楚,哪些工作適合自己動手,哪些該交給 Claude Code 這類工具輔助完成。

Claude AI 能取代工程主管的判斷嗎?
不能。Claude AI 能幫你整理文件、彙整數據、草擬會議大綱,大幅節省資料處理的時間。但真正決定「這個功能值不值得做」「這個團隊問題該怎麼解」,終究需要你對脈絡的理解與判斷。

上線後多久,應該進行專案復盤?
業界常見做法,是在功能上線後的一到兩週內進行,讓數據有足夠時間累積,同時避免拖太久導致細節被遺忘。太早做,數據不夠;太晚做,團隊記憶已經模糊。

怎麼判斷一個功能該優化,還是該直接放棄?
同時看上線指標和用戶反饋。如果核心用戶群有使用,但操作路徑卡關明顯,通常值得優化;如果用戶完全不買單,即使功能技術上做得再完美,也該考慮重新設計方向,甚至放手。