TLDR
在這篇文章中我想說明與 PM 進行良好溝通是重要的。接著藉著我的經驗，我提供一些方法在我的經驗中幫助我與 PM 進行溝通。這些方法包含：
多問需求背後的脈絡
控制溝通的細節
在開發中盡可能的與 PM 討論各種 trade-off
溝通的時候可以注意的細節
to whom?
我寫這篇文章的時候想像的讀者是
工作上需要頻繁與非工程師角色溝通的工程師
工作上需要頻繁與工作的 PM
覺得工程師不該跟 PM 對立而想要改變這個想法的人
disclaimer
我遇過的PM大多都是非常優秀的人，他們在產品方向、優先級排序和利益相關者管理方面的能力給我留下了深刻的印象。偶爾，他們做出一些讓我無法理解的決策，但這很可能是因為我當時並不了解的背景資訊，或是他們承擔了一些不合理的責任要求，譬如 PM 同時要負責多個專案，或甚至我也看過 PM 同時還要負責業務。因此，如果你的情況不同，那麼這篇文章所講的內容可能並不適合你。
為什麼與 PM 溝通是重要的
對我來說，與PM溝通的重要性有以下幾點：
資源支援：PM通常擁有許多資源，能夠協助你完成工作目標，例如釋出新功能或解決問題。透過與PM有效的溝通，你可以獲得所需的支援，提高工作效率和成果。
職涯發展：在職涯發展方面，PM在進行績效評估時提供從他們角度的正向回饋是非常有價值的。他們能夠觀察和評估你的工作表現，並提供有益的建議和指導，以改善你的技能和職業發展。
學習機會：PM擁有廣泛的知識和經驗，與不同部門和利益相關者合作。透過與PM的交流，你可以從他們身上學到許多有價值的知識和技能，了解整個項目的規劃、執行和交付過程，提升自己的專業能力。
建立信任關係：與PM建立良好的信任關係對於你的工作和職業發展非常重要。當你和PM之間有信任基礎時，他們會更傾向於向你優先提供問題和機會，並與你合作解決挑戰和達成目標。
總結而言，與PM進行有效的溝通對於你的工作成果、職涯發展和個人成長都非常重要。透過建立互信的關係，你可以獲得更多支援、學習機會和職業發展的推動，同時也為未來的合作打下良好的基礎。
具體可行的方法
如果你也同意與 PM 之間良好的溝通是重要的，那以下是我對於如何與 PM 進行良好溝通的一些心得跟覺得可能有用的方法。
總是問問需求背後的原因
在《你問對問題了嗎？：重組問題框架、精準決策的創新解決工具？》這本書的最一開始有一個故事是這樣的：
有一棟大樓的居民經常抱怨電梯運行速度太慢。假設你是負責維修的人，你會選擇如何處理？你可能會選擇著手加快電梯運行速度，以滿足居民的需求。然而，這次負責維修的人具備探究問題的能力，於是他審慎觀察後發現真正的問題不是「電梯運行速度太慢」，而是「乘客在電梯中感到無聊」。因此，他決定在電梯內增加了鏡子。從那時起，居民們對電梯的運行速度感到滿意了。
我認為一個好的工程師**除了被動的接收 PM 提出的需求以外，更應該多問問對方提出需求背後的原因，或是需求究竟想解決什麼問題。**而我也發現在日常的工作中，我們偶爾會遇到聽起來不合理的需求，這時候很自然地我們會問更多需求背後的原因。在面對一些聽合理的需求的時候，我們可能就會比較自然地接受他，而不會立即想要為什麼。
然而，無論要求的合理性如何，探究需求背後的原因都應該是一樣重要的。因為即使是合理的需求，也可能不是 PM 心中想解決的問題的最好的解決辦法。對於 PM 而言工程師可能更像是一個工具，而 PM 的工作無非就是協調各種工具的順利運作，以達成某個目的。但這個工具具體上到底能做到什麼事情卻是工具自己，也就是工程師自己本人最清楚。
控制溝通的細節
當我們進行溝通時，控制細節是非常重要的。而我覺得 Top-Down 的方式講述一件事情對細節的控制非常有幫助。葉就是傳達信息時，我們應該先提供整體的概念，接著提到主要的幾個重點，然後再根據需要逐漸深入細節。
此外在與 PM 進行溝通的過程中，我們需要密切關注對方的反應。這樣做可以讓我們更好地了解對方的理解程度和知識背景。如果對方顯示出對某些細節的不瞭解，我們可以適時提供相應的背景知識，使用具體的例子來解釋，或者如果情況需要的話，也可以嘗試將細節抽象起來，僅從概念上進行敘述。
最後，如果我們覺得對方可能需要更多的細節才能理解我們的內容，我們可以直接問對方對先備知識的了解程度。通過這種方式，我們可以確定對方對於相關主題的瞭解程度，從而決定是否需要提供更多的細節。
Involve your users in the trade-off
這個論點實際上來自 《The Programmatic Programmer》這本書。在軟體開發的過程中我們往往會需要做出許多不同的決定，而在這個過程中，我覺得不斷的跟 PM 確認各種抉擇的 Trade-off 也是非常重要的。
首先，程式品質和開發時間之間的關係是一個不單調的斜直線。從最初的 0% ~ 60% 的完成度可能需要一週的時間，從 60% ~ 90% 可能需要另外兩週，而最後從 90% ~ 100% 則可能需要四周。在與 PM 的溝通中，我們應該明確表達這種關係，以便 PM 能夠理解在時間和品質之間做出權衡的重要性。讓 PM 可以根據更多的 context 知道這個專案需要多細緻的完成度，這樣可以確保在項目進行中能夠達到合適的平衡點。
這個考量也是來自於其實多數時候我們並不需要將軟體開發做到完美，而只要做到足夠好即可。
Great software today is often preferable to perfect software tomorrow.
此外，如果可能的話，在與PM的溝通中，可以列出多個選項並分析每個選項的優點和缺點。這樣可以提供更全面的信息，讓PM能夠基於這些信息做出明智的決策。同時，列出多個選項可以幫助激發創新思維和找到更好的解決方案。最後是我也發現將多個方案明確的列出來也能幫助雙方在溝通的時候掌握明確的資訊。
舉個例子來說，假設我收到一個需求是「排序一個商品推薦的列表」，這時候我會試著從最簡單的方案開始，列出至少兩三個選項，並且與 PM 討論。這邊可以列出來的選項包含：
直接用商品的購買數量排序。這個方案不具備個人化，可能使用者體驗也比較不好，但這個方案的好處也顯而易見。這裡的排序可以在各個階段很容易得被快取
而這個方案中也會有更多的選項可以提供，像是以下這兩個方案的差別可能在於日後要繼續開發的時候，後者會更有彈性（但事實上我們也很有可能短時間不會再回來開發這個專案）：
排序的邏輯可以直接在 SQL 中實現
排序的邏輯可以在後端中實現
根據過往的使用者資料，利用資料分析的方法找出跟轉化率最相關的數據，並利用這些數據進行排序
使用 Machine Learning 的技巧建構一個推薦系統
這裡又會出現一些選項，譬如我們可以使用 managed service 的推薦系統（e.g. GCP Vertex AI, Miso.ai 或是 Appier 都有對應的服務）
或是我們也可以自己建構推薦系統。好處是日後可以自定義的細節更多，但時間跟金錢成本可能會是所有選項裡面最多的。
溝通中要注意的細節
同樣在《The Programmatic Programmer》中也有提到，在溝通的時候我們應該注意以下細節：
首先，我們應該計劃好想要表達的內容。寫下大綱，然後問自己：「這能清楚傳達我想要表達的內容嗎？」這樣有助於組織思緒，確保溝通流暢且明確。其次，我們需要了解我們的聽眾。不同的人有不同的需求和興趣。在溝通之前，要了解對方的背景和專業知識水平，以適應他們的需求。最後是選擇適當的時機進行溝通，你不會想在星期五下班前傳出一大串需要好好思考才能回覆的訊息。
要根據情境和對方的狀態選擇合適的時間和地點。確保對方有足夠的注意力和專注力來聽你的信息。
另外初中也有提到可以使用 WISDOM 原則來引導溝通。WISDOM代表：
你希望他們學到什麼？（What do you want them to learn?）
他們對你要傳達的內容的哪部分有興趣？（What is their interest in what you've got to say?）
他們的專業知識有多高？（How sophisticated are they?）
他們需要多少細節？（How much detail do they want?）
是誰需要知道這些資訊？（Whom do you want to own the information?）
如何讓他們對你即將說的話有興趣？（How can you motivate them to listen to you?）
作為溝通的一部分，我們也有 50% 的時間需要成為一個好的傾聽者。最簡單的原則就是：如果你不聽對方的，他們也不會聽你說話。我們應該聽取對方的請求，聆聽問題。這樣可以建立良好的溝通氛圍，增加彼此的信任、理解和合作。
But More Importantly
總歸來說還是同理心
寫到最後，其實我覺得在跟 PM 溝通的時候同理心還是關鍵。有同理心的人可能自然而然就能在每次的討論中學習如何與 PM 好好溝通事情。
沒有人想成為瘋子
這是我在《致富心態》中學到的最重要課程之一。無論是在投資還是與他人合作時，我們往往容易陷入非此即彼的思維陷阱中，將與我們意見不同的人視為錯誤。然而，大部分情況下，這只是因為彼此的背景知識、優先級排序或目標尚未對齊而已。據我的經驗，如果我們能清楚地表達自己的需求和期望，對方（PM）往往會試著站在我們的角度上，尋求更接近雙贏的解決方案。
但我想特別指出的是
身為工程師的我們應該避免使用情緒作為溝通的手段。
在我個人的經驗中，軟體工程師可能在公司中擁有一些特權。這種特權往往導致他們可以使用情緒來迫使其他合作夥伴配合他們的要求。然而這種行為並不正確。我們應該避免以情緒作為工具，而是努力理解自己真正需要什麼，以及如何以合理和明確的方式表達出來。
結論
我覺得有效的與 PM 進行溝通對於工程師的工作成果、職涯發展和個人成長都是重要的。我也認為我的職涯目前為止也因為跟 PM 之間保持良好的關係而獲益良多。然而，我必須承認，有時候溝通也會出現失誤，儘管我努力維持資訊透明度，但仍可能發生資訊不流通的情況。即使我努力將要傳達的事情以書面形式確認多次，仍有可能遺漏部分內容。不過，我相信我在與專案經理溝通的能力上持續進步，這種進步將有助於我成為一位更優秀的軟體工程師。
Acknowledgment
Cover Photo by Lala Azizli on Unsplash
Photo by Morgan Housel on Unsplash