會議室的白板上，畫滿了你完全看不懂的系統架構圖，上面佈滿了像是「Microservices」、「K8s」、「RabbitMQ」之類的神秘符文。團隊裡最資深的兩位工程師，正為了要採用即時運算還是批次處理兩種不同的技術方案，展開了一場激烈的神仙打架。

• 工程師A：「用批次處理，系統的 Latency 會太高，使用者體驗會很差！」
• 工程師B：「但用即時運算，系統的複雜度和維護成本會暴增，Scalability 會是個問題！」

你看著他們在白板上飛快地寫下更多你看不懂的程式碼和縮寫，感覺自己像個誤闖霍格華茲的麻瓜心中充滿了敬畏，但更多的是一種深不見底的恐慌。

就在此時，兩位工程師同時轉頭看向你，問道：「PM，這兩種方案各有優劣，妳覺得我們應該選哪個？」

時間彷彿凝固了，你感覺所有人的目光都聚焦在你身上，期待你給出一個專業、明智的裁決。你的大腦一片空白，手心開始冒汗。你很想問「Latency 是什麼？」，但又怕這個問題一出口，就會暴露自己的無知，失去團隊對你的信任。

最終，你只能擠出一個尷尬又不失禮貌的微笑，說出了那句最無力的話：「嗯…我相信兩位的專業判斷，你們討論出一個最好的方案就好。」

你看著他們眼中閃過一絲失望，隨即轉頭繼續用你聽不懂的術語爭論。那一刻，你感覺自己就像個坐在王位上卻赤身裸體的冒牌國王。

症狀診斷

如果你也常常在技術會議中，感到自己像個局外人，那麼你可能正深受「冒牌者症候群」所苦。

這個病症的根源，在於我們錯誤地將 PM 的價值，定義為團隊中懂得最多的人。

對於沒有技術背景的 PM 來說，這種焦慮感會被無限放大。

我們害怕自己的無知被揭穿，害怕因為聽不懂而失去對專案的掌控力，害怕無法贏得工程師的尊敬。於是，我們很容易選擇了最糟糕的應對方式：假裝自己都懂。

但其實一個 PM 的核心價值，從來就不是去跟工程師比誰懂的技術多（術業有專攻呀！）。你的價值，在於你能否做到工程師做不到、或沒有時間做的事：

• 定義「為何而戰」：清晰地闡述產品的商業目標與使用者價值。
• 掃除前進障礙：搞定跨部門的溝通、爭取必要的資源。
• 管理潛在風險：從時程、預算、使用者體驗等多個維度，評估技術決策帶來的影響。

面對這種技術辯論，最直覺的反應是試圖用自己有限的知識參與其中，希望證明自己的價值。然而，一條更需要勇氣、也更能展現價值的道路，是坦然地承認自己的知識邊界，然後用強而有力的提問，來引導團隊做出最明智的決策。

你的工作重點不是成為一個技術專家，而是要成為一個善於提問的價值守門員。

處方籤

第一劑：重新定義、搞清楚你的價值定位

在我們學習如何「對外」提問之前，你必須先學會如何「對內」叩問自己。請先放下對技術的焦慮，誠實地回答以下幾個問題，這將幫助你重新錨定自己的核心價值：

• 問題一：拋開技術細節，這個專案「最不能失敗」的一點是什麼？ 是準時上線搶佔市場？是提供絕對穩定的使用者體驗？還是要達成老闆最在意的那個商業指標？
• 問題二：在所有利害關係人中，誰的「失望」會是致命的？ 是終端使用者？是付錢的客戶？還是你的大老闆？他們的期望分別是什麼？
• 問題三：放眼整個團隊，只有我能扮演的、不可取代的角色是什麼？ 是那個最懂使用者的人？是那個最會跨部門溝通的橋樑？還是那個最擅長管理風險的守門員？

當你對這三個問題有了清晰的答案，你就找到了你的「價值主場」。你的自信，將不再建立於你懂不懂技術，而是建立在你對商業目標、使用者價值、以及所有利害關係人期望的深刻理解上。

第二劑：學習問出好問題

一個好的問題，勝過一百個自作聰明的答案。你需要學會用「外行人的視角」，來提出那些工程師可能忽略的、直指核心的問題。

• 你可以問的「傻問題」：
  • 關於風險：「這個方案聽起來很棒，那它最壞的情況是什麼？如果發生了，我們的備案是什麼？」
  • 關於成本：「導入這個新技術，除了開發時間，我們還需要付出哪些隱性的成本？例如學習成本、維護成本？」
  • 關於使用者：「如果我們選擇了效能比較差的方案B，對使用者來說，最直接的影響是什麼？是頁面載入慢 2 秒，還是 0.2 秒？」
  • 關於取捨：「聽起來方案A體驗好但風險高，方案B穩定但沒亮點。如果我們的第一要務是『準時上線』，哪個方案更能幫助我們達成這個目標？」

第三劑：持續建立你的專業護城河

光是聽懂還不夠，你需要建立起團隊對你「專業」的信任。我們在【病症22】中，已經準備一些基礎的技術翻譯，還有如何讓自己持續認識新名詞的方法，而這只是幫助建立溝通基礎的敲門磚，真正的信任，不是來自於你懂多少術語，而是來自於你在你的專業領域做到無可挑剔。

1. 成為無可挑剔的「規格制定者」：你的需求文件 (PRD)，應該要成為工程師最可靠的聖經。邏輯清晰、邊界條件考慮周全、使用者流程圖一目了然。當工程師相信你的規格永遠比客戶的口頭禪可靠時，你就贏得了第一層信任。
2. 成為資訊的「中央樞紐」與「過濾器」：你主動承擔起所有跨部門的溝通，將來自四面八方的模糊需求與壓力，轉化為清晰、可執行的任務。你為工程師擋下了所有不必要的會議與干擾，讓他們能專注在開發上。你不是傳聲筒，你是保護團隊的防彈背心。
3. 成為專案的首席風控大師：你主動去追蹤那些工程師可能不會注意的非技術風險：市場趨勢的變化、競爭對手的動態、法務條款的更新、行銷活動的排程。你讓團隊感覺到，你在看的，是整片天空，而不只是眼前的程式碼。

當你將這些做到極致時，你就建立起了一道名為「 PM 專業」的護城河。團隊會因為你的存在而感到安心，他們尊敬的不是你超級懂技術，而是你能夠為整個專案帶來的確定性與方向感。

臨床實戰

好，讓我們回到開頭那個讓你無地自容的會議室。

當兩位工程師將問題拋給你時，如果你服用了這份處方，你可以怎麼做呢？

1. 坦然承認，重新定位：
   這時你可以微笑地說：「謝謝兩位的詳細說明。坦白說，關於底層技術的細節，我當然不如兩位專業的。但身為這個專案的 PM，我的職責是確保我們的技術決策符合老闆的期待。」
2. 啟動「強力提問術」：
   你接著問：「我想請教一下，如果我們選擇了方案A（即時運算），我們可能需要付出多少額外的開發和測試時間？這個時間成本，是否會影響到我們原訂的上線日期？」
   「另外，如果我們選擇了方案B（批次處理），對使用者來說，最直接的體感差異是什麼？是推薦結果會延遲一分鐘出現，還是一小時？」
3. 引導決策，拉回共同目標：
   在得到答案後，你做出總結：「好的，我理解了。看起來，方案A能提供極致的用戶體驗，但有延期的風險；方案B能確保我們準時上線，但體驗上會有些許延遲。考量到我們這次專案最重要的目標，是『盡快上線，驗證市場反應』，我會建議我們先採用方案B，確保時程。但同時，我們將『升級為即時運算』，作為我們下一階段的優化目標。兩位覺得這個方向如何？」

你可以透過一連串聚焦於「成本」、「風險」和「使用者體驗」的問題，成功地引導團隊，做出了一個最符合當下商業目標的決策。

B計畫：當團隊質疑你的專業時

好，我們來面對那個最傷人的狀況。

當你問出你的「傻問題」時，團隊裡可能有那麼一個人用輕蔑的語氣說：「唉，這個是技術常識啦，你怎麼連這個都不懂？」

此刻，你的內心可能會淌血（還有想鞭數十之類的），但你的表情必須堅定。

這時我們不要惱羞成怒，或畏畏縮縮地道歉，而是可以再次跟他重申你的價值定位。

當下你可以說：「謝謝你的提醒，我的確不懂。也正因為我不懂，所以我才需要請教各位專家，這個技術決策會對我們的『使用者』和『時程』帶來什麼影響。我的工作，就是確保我們的技術，永遠走在能為公司創造最大價值的軌道上。」

最後的醫囑

坦白來說，我覺得擔任 PM 這個角色，是一個極度需要展現自信的角色，而這份自信並不來自於你無所不知，而是來自於你謙虛地接受自己知識的局限，並善用這份坦然來進行最精準、最有力的提問。

工程師負責「如何把事情做對 Do the thing right 」，而你負責定義「什麼是『對』的事情 Do the right thing 」。這兩種專業沒有高低之分，只有分工不同。

非技術背景的 PM，贏得工程師尊敬的唯一方法，就是在你的專業領域做到無可挑剔。當你寫的需求文件邏輯清晰、當你搞定的跨部門溝通順暢無比、當你為團隊擋下了所有不合理的需求時，沒有人會故意去挑三揀四質疑你懂不懂 API。

所以下次當你又在技術會議中感到焦慮時，請深呼吸，然後驕傲地在心中告訴自己：「我有我的專業，也有我的價值，而我的價值，是在於引導團隊用正確的工具達成最重要的目標。」

工程師間的技術辯論

我：剛剛說的 “累疼係” 是蝦米？？？？