「不只是PM」- 拒當傳聲筒！身為進階 PM 的二三事

「那個，客戶的抱怨又來了，可以麻煩你幫忙修一下嗎！？」

「客戶說沒有這個功能就不能出版，可以麻煩你今天加一下嗎！？」

 

 

 

 

在系統開發的日常之中，這幾句話想必是相當熟悉。每當需求傳遞的過程之中，如果 PM 無法準確地傳達訊息，最後就是在出版的過程裡，才驚覺做出來的功能，與客戶實際的需求，存在著可大可小的差異。小則延宕，大則加班，但這樣的落差，往往都是把團隊和客戶，帶往對立面的窘境。

 

但問題出在哪裡？真的是客戶沒有精準的傳遞訊息嗎？還是其實身為 PM 的你，從來沒有確實的了解，客戶傳遞的需求中，到底是在哪個環節中，發生了問題？如果客戶的想象過於天方夜譚，身為團隊一份子的你，又該如何克服技術與非技術之間，溝通的難關呢？

 

 

 

 

當然，PM 的工作，從來就不是以一個傳聲總機的角度，把需求發包給 RD 同學們，而是應該設身處地的，站在客戶與 RD 同學之間，成為那座溝通的橋樑，在把客戶的需求傳遞的同時，也應該要做到保護團隊的義務，來了解每一個需求實踐的可行性。

 

但難道一定要 RD 出生，才有辦法參透技術的奧妙與可行性評估嗎？其實懂不懂技術，並非是一個 PM 最重要的核心技能，當然具備一定程度的熟悉是絕對要的，但如何彌平團隊與需求之間溝通的落差，才正是一個專業的 PM，應該要在意的事情

 

因此，小編依照自己工作的經驗，分享幾個小撇步，來作為 PM 精進溝通技巧的進階能力

 

「第一，聆聽，勝過自帶立場的千言萬語」

 

從需求訪談開始，先拋開所有對系統的既定想像與成見，先從專心聆聽需求開始，從溝通的過程之中，了解客戶對於需求的理解，因為也許客戶的業務繁忙，對於需求，也只能盡到傳遞的義務，而對需求的背景與本質，客戶本身也不是確切的了解。

 

 

 

 

這時候正是「溝通」的重要性，身為 PM 一定要有打破沙鍋問到底的勇氣，哪怕是問題再小再繁瑣，也必須要切實得考究，讓客戶可以把你的問題與團隊的陳諾，忠實的傳遞回去，來確保我們的想像與客戶的想像之間，沒有存在差異。

 

舉例來說，客戶可能會需要再物流系統，有著快速儲存配送地址的功能，在一聽到這個需求的同時，並非快速提供解決方案，而是應該要了解現有系統本身，是不是帶給客戶什麼樣的困擾或是客訴，這時候反覆提問，來收斂問題的範圍，畢竟客戶的希望很單純，就是期待你可以解決他們的痛點，而並非交付一個多餘且雞肋的功能

 

 

 

 

「第二，對內對外反覆確認，把不確定的變動，化為收斂的可能」

 

一但問題的核心被收斂之後，PM 可以試著在會議上持續的確認施作範圍和項目，來確保客戶的想像和你的想像之間，沒有存在落差。如果無法條列溝通，也許現場繪圖討論也是一個可行的方式，但這一定也會考驗到 PM 對於自家系統的熟悉程度，但別懷疑，這就是 PM 必須具備的功課之一。

 

 

 

 

承上例，客戶最原始的需求是減少反覆輸入配送地址，以期望增加結帳效率，這時專業的 PM 就應該要釐清自己家系統，會在哪些 Page 需要輸入配送地址這樣的作業，並把問題收斂到最小範圍，例如哪一個 Page 實作儲存常用配送位置，或是在哪一個欄位自動帶入上次配送地址等等，並讓客戶確認，這樣的實作是否可以解決到客戶目前遇到的困境與痛點。

 

 

「第三，正視自己的無知，把問題帶回內部討論」

 

 

別把每一個問題想得太簡單，只要有些許不確定的因素，都應該把問題帶回到團隊內部討論，避免自己承諾到無法實作的項目。這中間勢必會遇到技術端上的討論，在 RD 同學解釋給你的當下，PM 也應該試著重複著確認，了解自己對需求的認知與實作技術的落差，以求兩端的溝通降到最小的差異

 

舉例，客戶遇到一個 App Crash 的問題，RD 會試著用技術的角度來討論這個問題發生的確切原因，而身為 PM 的你，應該試著在 RD 解釋後，依照自己的角度，重新詮釋一次問題給 RD，來確保你的認知是否和 RD 同學達到共識，這樣你才會了解如何解決問題，以及該問題修復上的難度在哪？如果是 Corner case，是否可以定為較低的優先序等等。畢竟團隊的資源有限，我們應該要投注較大的開發能量在優先序高的項目上，也只有確實瞭解問題，你才有辦法訂出團隊與客戶間，都可以接受的處理順序。

 

 

 

 

「第四，也是最重要的，要讀懂空氣」

 

一但掌握到上述三點之後，不論是在客戶端的討論，還是 RD 內部的溝通，最重要的就是氣氛的掌握，一但你嗅到了「客戶或是 RD 沈默，或是露出不解的神情」，一定要適時地打破僵局，問出是不是有哪裡不妥的狀況或是沒有考慮到的問題，一來是確保會議可以往自己期待的目標前進，二來也是確定那些客戶不說的，不會成為他們心裡的疙瘩

 

舉例來說，客戶回報的 App Crash，在你詳細的解釋修復難度與實作的優先順序後，可能當下一片沈默，這時候你一定要反覆詢問客戶，是不是其實有更高層的長官關注這個問題，又或著是這個問題會影響到客戶內部 KPI 的標的，如果是，那就要反覆的跟客戶告知，先修這個 Bug，可能會遇到預期產出功能延宕的可能性，來確保你的思維與客戶的立場，是不是在同一條船上。

 

 

 

 

最後，也是最重要的，一個合格的 PM，除了確保溝通順暢之外，更要建立客戶與團隊間的信賴，這不僅考驗你對系統的了解，也是考驗著帶領團隊前進的士氣，而也只有做足功課，才能取得客戶的信賴，把信賴回饋成士氣，才能確保產出的品質無慮。

 

讓客戶信任你，也同時要讓團隊知道，你不只是一個傳聲筒而已，自己對系統的了解，以及溝通的順暢，這才是彌平技術與業務之間，最重要的事情。我們可以不懂技術，但對溝通差異的彌平，一定要視為己責，才能確保交付和期待之間，沒有落差。

最後，如果你喜歡我們的文章，別忘了到我們的FB粉絲團按讚喔!!