軟體工程師如何做好專案技術負責人的角色？

在之前文章中，我們談了 軟體工程師如何做好技術設計？。而在這篇文，我們將進一步來談，如果今天你被交派負責一個專案，你要如何擔當好這個技術負責人的角色？

我們會試著展開一個專案從開頭到結尾的各個階段，並討論在各個階段，做為技術負責人的角色，應該要注意什麼。

誰能當技術負責人?

在往下討論如何做好技術負責人的工作之前，想先聊一下「誰能當技術負責人」這點。假如你目前是初階或中階工程師，想往技術負責人的角色發展，推薦可以用以下的點來自我檢視：

• 技術層面：你是否對於模組 (例如前端的元件、後端的服務) 瞭若指掌? 有遇到問題時，你是否比其他人更清楚如何用最佳的方式解決?
• 行為層面：你是否有溝通與協調的能力? 特別是在跨組溝通 (跟上下游團隊溝通)、跨部門溝通 (跟產品、QA 等其他職位的人溝通) 的能力?
• 思維層面：你是否有自己是負責人的主動思維? 當有任何問題時，是否有「由你來扛」的心態?

了解需求：確保解決對的問題

在一個專案的最開始，最重要的是確定好需求是什麼。一個常見的誤區是認為「確定需求是產品經理的工作」。基本上想成為資深工程師，特別是專案的技術領導 (tech lead)，確保有解決對的問題這件事，也是在技術領導職責範疇之中。

先前有機會跟一位 L7 職級的資深前輩聊，他提到不要一看到需求就開始想技術。更關鍵的是先從使用者的角度出發，跟產品端一起把要解決的問題定義好。

事實上，產品經理想不完整，是很常見的狀況。想要把專案帶起來，稱職的技術負責人，不會抱怨產品經理這個沒想到、那個沒想到，而是會主動跳出來，一起把產品端沒想清楚的地方釐清好。唯有在釐清好需求後，才回過頭來思考需要什麼技術解決方案。

一般來說，在大一點的專案，要思考的需求可能不限於自己負責的團隊，會需要進一步去想到上下游的需求、彼此的關聯。不能只想對方要為自己做哪些改動，而是要站在合作方的解度去想如何跟他們對接，這樣會讓後續要推進比較容易一些。

有一個特別重要的點，是在這階段要追著產品端確定的，那就是預期效益。在目前科技業的現實下，開發出的成果有沒有收益，會是特別被看重的。

2023 到 2024 年間，國際上許多優秀的工程師被裁員 (有些甚至在全球開發者社群活躍)，不是因為能力不好，而是可能該組做的成果被公司認為相對效益不高。

很多時候，產品經理可能自己也沒搞清楚，對於預期效益講不出個所以然，這時候身為技術端的負責人，一定要追著產品經理，確保有合理的效益評估，不然後面做的都可能變成白工。

技術分析與比較

在釐清完需求後，接著就可以針對需求來發展解決方案。在發展解決方案時，除了自己想之外，有一些能夠協助想的更完整且透徹的方法，以下四個是推薦實際撰寫技術設計文件前，可以做的事情：

• 找人請教：比起在汪洋大海的資訊中收斂，直接找已經在該領域有一定耕耘的專家會更有效率。假如是在大公司工作，可能其他團隊已經有解決過類似的問題，這時直接約 30 分鐘的 1:1 來請教，會快非常多。在請教時，也可以問該專家有沒有推薦其他的專家，有的話也約來請教。
• 社群中找啟發：除了找人問之外，上網找也是一個方式。舉例來說，假如今天你要負責帶的項目是一個生成式 AI 客服，目前網路、開源社群已經有很多解決方案，這時可以從別人的設計中找到一些啟發。此外，也可以善用自己待的公司的內網，來找相關的技術設計方案 (不過如上面提到，假如有找到相關的團隊有做過相關內容，直接約一個請教的會議會更有效率一點)。
• 尋求回饋：在 軟體工程師如何做好技術設計？ 一文中，我們有談到 Figma 工程團隊的 Engineering Crit 的環節，這個環節的主要做用，是進到正式的技術評審之前，先向相關人士尋求想法與回饋。Figma 團隊會邀請其他團隊的專家，提供對於不同方案的觀點；在有了初步的方案選擇後，團隊又邀請專家給予想法上的輸入。最後基於這些不同團隊與專家的觀點，該團隊才決策出要往下的方向。
• 第一性原理思考：上面提的兩種方式都是參考過往的人的經驗，這能加快速度。然而，別忘了在 高效工程師都要懂第一性原理思考 (First Principles Thinking) 一文中，我們談到跟從過往經驗有其危險性；因此比較好的做法，會是除了參考現有的方案的同時，也試著回到本質思考如何設計這個系統會比較好。

把整體架構、分工、時程定下來

在釐清完需求、探索完不同的技術解決方案後，最終需要確定下來要往哪個方向走，這時做為專案的技術負責人，就需要去確定下整體的架構設計，並且在有了整體架構後，要有各個細部的分工，確保每個部分都有負責人。

一般來說各個公司的習慣可能不同，但普遍比較常看到的，是在有了架構、分工後，由各個子部分的負責人，進一步提出細節的設計，然後再進到子部分的技術評審會議。這階段整體專案的負責人的角色，就會是確保每個子部分沒有偏掉，有照著整體架構來進行設計、不同子部分彼此能順利整合。

雖然在前期確保架構正確很重要，但這階段也不宜拉太長。先前有聽過比較誇張的例子，是某大廠因為技術設計時喬不攏，導致一個專案過了一季還沒有進到實作階段。除非是學術研究機構，不然在一般業界，總是會有來自市場的壓力，當一直卡在這階段，技術領導的能力可能會受到質疑。

特別是不同產品階段，速度與嚴謹度的取捨也會不同。一般在早期階段，以驗證市場為主，先把東西做出來驗證會比較重要，這能避免花一堆時間設計，結果最後發現市場不買單的窘境；反之，如果是已經有大量的使用者，每個改動的影響都很大，這種階段就會更偏向技術設計花多一點時間打磨。

回到細部分工來討論，當各部分的細節設計都完成後，這時務必要把時程定出來。在現實世界中，經常可能遇到要趕上線的狀況。用嚴謹的做事方式，肯定會需要多一點時間，但是從長遠的角度來看，有時候前期求快導致後面要收拾，反而會讓總體成本增加不少。

關於時程預估的掌握，沒有標準答案，專案負責人要有辦法判斷，現在該用什麼樣的節奏。一個大原則是在不犧牲品質的狀況下，確保能盡早完成，讓開發完的成果能盡早轉換成收益。

閱讀更多

如果你對於「如何做好專案技術負責人」這主題感興趣，我們在 E+ 有寫更深入詳細的內容，包含落地執行、監控與追蹤收益、持續迭代專案等具體細節。有興趣的讀者，歡迎加入 E+ 成長計畫。

本文為 E+ 成長計畫的深度內容，截取前三分之一開放免費閱讀。歡迎加入 E+ 成長計畫閱讀完整版本 (點此了解 E+ 的詳細介紹)