專案反思與重塑：TPM、SA、PM角色定位的挑戰與解決方案

Feb 25, 2025

專案如同一面鏡子，映照出組織的每一個短板。最近公司剛完成一個專案，過程中幾乎遭遇了軟體開發中可能碰到的所有問題

引言

專案管理是一場技術與人性的博弈。無論是技術斷層、文化限制，還是客戶需求的脫節，成功的專案總在混亂中尋找秩序。許多團隊在角色定位不清與溝通失誤中掙扎，卻鮮少找到突破之道。本文從一場真實專案出發，剖析TPM、PM與SA的困境，揭示Demo失敗的真相，並提供實用解法，助您將挑戰化為競爭力。

反思第一步：如何從混亂專案中找到改進線索

專案如同一面鏡子，映照出組織的每一個短板。最近公司剛完成一個專案，過程中幾乎遭遇了軟體開發中可能碰到的所有問題：客戶訪談不清、時程延宕、人員調動、PM淪為傳聲筒等。更別提本案融合生成式AI、影像辨識與即時影像串流，技術複雜度大幅提升。我將這次專案視為團隊在最糟糕狀態下會面對的挑戰，認為正視問題是解決的第一步。透過歸納這些議題，希望能降低團隊未來犯錯的機率。因此，我先列出本案中的幾大問題，並按重要性逐一檢視。

在這場挑戰重重的專案中，問題層出不窮。接下來，讓我們從組織結構的變革開始，逐一剖析這些痛點。

組織結構變革下的TPM困境

本案首先遇到的問題是組織結構變革，首次導入PM與TPM架構。PM是台灣科技業熟悉的專案經理，而TPM（技術專案經理，Technical Project Manager）則負責與客戶進行技術討論與報告。從命名可見，TPM被期望具備足夠的技術知識，能在客戶與團隊間轉換語境，並監督專案技術環節的設計與開發進度。然而現實卻不盡人意：這次擔任TPM的人員在軟體開發上缺乏深度，無法有效監督進度或引導設計方向。更因初次擔任此職，常需仰賴工程師主動提供解決方案，無法發揮主導作用。例如，工程師常需先想好解決方案再要求TPM確認，這與經驗相悖 — — 理想上，TPM應主動確認問題後，與團隊討論可行方案，而非反過來。但這屬個人成長議題，暫不展開。

可以注意到 TPM 當中，是包含 Project & Manage，工頭已經對手上建材沒概念，自然沒法掌握進度，這是危險的。倒不如退一步思考 TPM 當初導入的用意，一開始是要讓 PM 出去的時候擔心技術沒底而設立的，所以可以不用進度管理，反而只是名技術諮詢(Technical Consultant)就可以，負責翻譯以及回答專案當中的技術相關問題，我想定位上會比較容易。再退一步來說，組織中有這種 luxury 可以聘一名人員執行嗎？這個我在組建團隊時會認真思考這必要性。就目前來說重新定義 TPM 為技術諮詢，專注於技術翻譯而非進度管理。如此一來可以省去培訓這名角色的時間，直接從團隊中抓取出來即可，也省去一層決策結構。

TPM的困境反映了技術與管理間的斷層，而這只是問題的冰山一角。另一關鍵角色 — — 系統架構師（SA）的缺失，同樣讓專案陷入混亂。

系統架構師（SA）的缺失與混亂

從工程師角度看，本案首要議題是系統架構師（System Architect，SA）的缺失。專案初期運作模式是：AI團隊負責產出辨識結果，後端管理資料庫與對接，前端處理畫面佈局與資料串接。各部分看似獨立，但名詞定義與資料流動卻邊開發邊設計，團隊間很少坐下來討論使用情境或梳理流程。這就像一群工人拿著各自的工具與材料，聽到業主要蓋牆後就各自開工，只能靠默契與經驗『猜測』牆的規格。換言之，缺少一位整合資料串接、評估設計難度的角色。

一定得有SA才能整合嗎？答案顯而易見：不盡然。但這正是許多組織常見的問題 — — 各自為政。哈佛商業評論研究指出，專案執行中90%的時間花在溝通上，協作失敗的主因有67%來自『孤島效應』[1]。這凸顯溝通的重要性，而打破困境是每個領導者都會面對的課題。現實解法上，可引入SA，或培訓資深工程師兼任整合角色，後者或許更實際。

SA的缺席讓技術整合舉步維艱，而這也讓專案經理（PM）的角色定位更加撲朔迷離。接下來，我們探討PM在本案中的掙扎。

PM角色的窄化與文化影響

PM角色的重新定義與挑戰

除了SA需重新定義外，另一關鍵角色 — — 專案經理（PM）同樣值得團隊深思，其職責是否被充分想像與描述？隨著組織成長與專案數量增加，外聘PM協助消化工作量看似直覺合理。然而隨著時間推移，我發現這些PM與過往經驗大相逕庭。這種差異連Steve Jobs都曾提及並分享看法[3]。PM角色的模糊性促使我重新思考：PM究竟該負責什麼？又應具備哪些能力？讓我們透過具體情境來梳理。

理想PM的技能與角色分工

想像一個尋常的專案場景：某個陽光明媚的早晨，內部會議室擠滿了焦慮的氣氛。專案經理召集全體成員討論即將上線的新系統，會議一開始，專案經理述說著報告，近幾日收到大量客戶反映系統操作繁瑣、界面不夠直觀；同時，老闆透露市場上競爭對手動作迅速，迫使公司必須加快產品迭代。系統架構師提出優化現有系統架構的方案，指出部分模組需重新開發；然而，工程團隊反映現有代碼難以兼容改動，技術難題重重。介面設計師則堅持，必須從用戶角度重新設計交互流程，以改善用戶體驗。某個人果斷調度資源，迅速組成解方，要求各方在短期內梳理問題根源，並提出可行的試運行方案。這是軟體開發的日常縮影，但早期公司往往一人身兼多職。角色依技能而定，以下是從這情境提煉的七個關鍵角色：

客服：主要負責面對客戶情緒、接收並記錄客戶對系統的各種不滿，並把這些信息傳遞給內部團隊，從而成為改善產品的重要來源。
業務：在市場前線推廣產品，回答潛在客戶對產品功能、上線時間、價格等方面的疑問，並努力將客戶拉入產品生態中。
架構師：根據需求設計整體系統架構，是技術方案與系統穩定性的核心保證。
使用者分析人員：將客戶需求轉化為具體的使用情境，這是產品與用戶之間橋樑的關鍵角色。
介面設計師：根據使用情境設計產品介面，確保用戶在使用過程中的體驗直觀且流暢。
工程師：根據系統架構和設計要求實現功能，並撰寫必要的文件來確保知識的傳承與落實。
專案經理：負責專案進度、資源配置和風險管理，確保各角色高效協同、按期交付。

這些是我反覆在各類案子中歸納出來所需要的角色，也是最核心的組成，但更多時候公司早期只有老闆＋設計師＋工程師，一人包含了客服、業務、架構、使用者分析、專案經理，這也替早期團隊奠定了基礎，出去談的 PM 至少擁有這五種角色身上的技能才行。我想這也可以間接說明為什麼在組織內對於外聘 PM 想像完完全全不同。但這還不足以回答我心中的另一個疑問，為什麼台灣對於 PM 的想像縮限只剩下專案進度管理、推動團隊協作而已？

這些理想角色看似清晰，但現實中PM為何淪為『傳聲筒』？這背後的文化因素值得深究。

文化結構對PM的限制

台灣的專案經理（PM）常給人『怪怪的』感覺，似乎被局限於進度監督，而非真正領導專案。國際標準（如PMI的PMP框架）定義PM為領導團隊、在預算與時限內完成專案的關鍵角色，需具備規劃、執行與問題解決能力。但在台灣，PM常淪為『進度監督者』，與此有明顯落差。

這與文化結構密切相關。台灣深受儒家思想影響，強調階級秩序與和諧，PM因而習慣聽從上級指示，而非主動挑戰現狀。例如，專案瓶頸時，PM往往選擇上報而非自行決策，角色更像監督者而非領導者。此外，台灣多採用功能型組織架構，部門壁壘分明，資源由各單位主管掌控，PM缺乏直接調度權，只能仰賴跨部門協調，職責遂簡化為追蹤與報告。企業認知也加劇此現象，將專案管理視為『工具應用』，導入Scrum或Slack後便認為管理到位，PM因而被定型為行政角色，而非具全局視野的領導者。

然而，這種窄化也有其價值。在資源有限、強調穩定的環境中，台灣PM能在混亂中維持秩序[5]。Steve Jobs曾示範解法：直接從內部提拔具技術背景者擔任PM[3]。但這引出新問題：工程師如何轉型為PM？畢竟PM需融合人際管理、專業技術、文書與領導能力。在艱苦環境中，這些或許是必備技能。

PM的窄化不僅影響內部協作，更在對外Demo中暴露弱點。接下來，讓我們看看Demo環節的失誤。

Demo展示與客戶需求的脫節

本案最後一大問題是：因PM僅專注進度監督，執行期間只重視功能完成度，Demo時遂逐條展示功能，而非解決客戶需求。這是前述問題的連鎖結果。Demo本質是與客戶對話，若僅介紹功能與用途，客戶或許只會禮貌回應『謝謝』，然後不了了之。搞砸Demo並不難[6]。

為此，可採用『You-They-You』框架自我檢視[7]：先展示產品功能，再連結客戶需求，最後達成目標。例如：『今天Demo中，我將展示…，因為您提到…是您關心的重點。』成功的Demo取決於客戶是否感受到價值。但這離不開深入理解客戶需求。可搭配『Present-Future-Preference』框架挖掘需求：『當前流程是否有拖延因素？使用產品後，您希望達成什麼目標？您如何評估解決方案的成功？』這是我與不同背景人士聊天時常延伸的技巧。

總結與展望

本案暴露了角色定位、溝通與文化的多重挑戰。未來，團隊可重新定義TPM為技術顧問、提升PM的多面向能力、引入SA或培訓整合角色，並改進Demo以聚焦客戶需求。這些改變需時間投入，但將增強組織的長期競爭力。

參考資料：