進度條

WordPress 架站實體工作坊即將開始

【實體課程】12/06 (日) 09:00 「台北場」WordPress 整天工作坊即將開始,目前持續售票中,不要錯過喔!購票與詳情請看「KKTIX 購票頁面」或「進度條文章」。

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

客戶說沒有這個功能就不能出版,可以麻煩你今天加一下嗎!?

作者: Vincent Ke 更新日期:

「那個,客戶的抱怨又來了,可以麻煩你幫忙修一下嗎!?」

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

 

 

can-chat-chatting-362.jpg

 

 

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

 

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

 

 

asking-beautiful-brainstorming-601170.jpg

 

 

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

 

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

 

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

 

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

 

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

 

 

adult-blur-depth-of-field-1181717.jpg

 

 

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

 

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

 

 

advice-advise-advisor-7097.jpg

 

 

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

 

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

 

 

adult-bar-brainstorming-1015568.jpg

 

 

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

 

 

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

 

 

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

 

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

 

 

business-discussion-indoors-2173508.jpg

 

 

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

 

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

 

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

 

 

advice-advise-advisor-7075.jpg

 

 

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

 

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


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

Medium vincent

Vincent Ke

喜歡把混亂的事情變的簡單 用嘴巴做事其實很可以 但要結合靈活的腦袋思考 就一起來拆解吧