• 我們是
  • 引 領航理念
  • 合作伙伴
  • 引 領航話你知
  • 創業營商心得
  • 創業資訊
  • PM 只會出張嘴、改需求?從 RD 的抱怨,談產品經理該做的事04-06-2019

    前陣子批踢踢科技業版上有一篇文章:「PM到底要做啥」,引起了一些討論,其實內容蠻常看到的,都是工程師(後面簡稱RD)常常會嘴PM的幾個點。

    雖然我覺得這些批評常地圖炮,文中被砲轟的其實是「做不好的PM」,而不是「PM這個角色」本身,當然更不代表PM這個角色沒有價值,不過有這樣的評價,PM當然自己也可以思考,是不是沒有找到自己的角色定位,沒有做自己該做的事情,或是在溝通上沒有控制多方的需求以及期待,才會導致雙方錯誤的認知。

    以下整理前三名RD最喜歡抱怨PM的點,想要來釐清一下迷思,還有討論PM應該如何思考與自我定位:

    抱怨1:出一張嘴不做事
    我覺得要看「出一張嘴」是不是真的讓事情推進,或是解決了問題,如果有,其實「出一張嘴」也是一種做事,而且偏偏是許多RD很不喜歡做(或是很難做得好)的事。

    許多人可能因為「本來就會說話」、「從小就會和其他人交流聊天」,而忽略「溝通能力」的價值,不認為這是一種專業,但是PM要做的事情,是「在不同時間點,戴上不同帽子,扮演不同角色,和不同的人溝通」,其實和RD的溝通,只佔PM日常溝通的一部分而已,而且越高階的PM,這部份佔越少,因為PM往往還要跟供應商、業務、行銷、老闆、代工廠、客戶、用戶等很多角色溝通,而且厲害PM和菜鳥PM能做到的結果差很多。

    以和RD溝通為例,很多RD會抱怨「PM只會跟RD壓schedule,然後出一張嘴要你做」,很多PM其實會覺得很莫名,PM問RD工時是一種尊重吧?不然要自己漫天亂估嗎?

    差別可能在於PM的心態,以及溝通的方法。PM在面對RD時,應該戴上「客戶代表」的帽子,而非「老闆的帽子」。

    這種思維的好處,除了讓RD感受到「參與感」,甚至是「英雄感」,而非「社畜感」,讓他們認知到自己的專業能力,才是實現這個願景的重要工具,也可以讓RD從他的角度,提出其他可行的解法。甚至一個團隊合作了一段時間,有了默契,並累積了一些對客戶的認知,有時RD會記得之前聽過的客戶需求,有機會就在程式裡加入一些優化,或是會主動與PM討論解法,這些都能讓整個團隊更進步,也更團結。

    反過來講也有些PM會覺得,RD為什麼總是一個口令一個動作,很多顯而易見的設計,沒有講就不做,遇到也不會主動問PM,或是任何事情都要文件定義得清清楚楚才要開工,按表操課。其實,肯按表操課還是好的,慘的是文件最後寫得落落長,但根本沒人看。

    其實我認為PM也可以思考,是不是雙方的溝通與合作模式,讓PM少了「為什麼要這麼做」的溝通,習慣讓RD「做就對了」,一旦習慣了這種「接單生產」的合作模式,怎麼能期待對方有對產品的熱情與ownership,主動「多做一步」呢?或是RD吃過虧,「有私下答應過」的功能沒做到,被PM拿出來highlight變羅生門,久而久之就會要求什麼都先更新文件以自保。

    其實我覺得這種「公事公辦」,都是雙方合作缺乏互信以及默契的結果,帶來的結果其實是一種資源的浪費,這當然雙方都有責任,要公事公辦也不是不行,但這樣的結果PM一般會比較痛,所以雖然初期的溝通與互信的建立很花時間,但我認為PM最重要的「做事」,應該就是在溝通中搞定多方,而這也跟PM的專業能力有關:如何挖掘真正的「Why」,並傳遞價值、激發熱情,是要有深刻洞察才做得到的。

    抱怨2:需求一直改一直改,schedule卻沒變
    其實我認為這個問題背後的問題,是資訊不透明,PM沒真正搞懂需求是什麼,心中也沒有商業價值判斷,就很容易變成傳聲筒,擋不住客人或老闆的要求,不過反過來我也必須說,奢望需求一旦確定下來都不會改的人,跟要求程式寫好測過就要沒bug,是一樣的天真呀。

    即使「改需求」難以避免,但PM還是有些能控制的方向,減少「人禍」造成的需求變更。

    從基本功開始,PM至少要明白客戶或用戶這麼做的「目的」是什麼,因為一般而言,客戶開案的大目標不會有太大的改變,但是對「怎麼實現」會有很多意見,如果雙方可以在目的,也就是「Why」方面先建立共識,其實在後續的「How」如何實現,會更容易聚焦,而且這也會扣回第一點:你如何讓你的團隊真正了解需求,一起做出客戶需要的產品?

    接著,做到盡量以可視化的方式溝通,例如提供相關範例,確保是不是客戶要的,或是畫出使用流程、大致的介面與行為,讓客戶更清楚做出來是什麼樣子。不然很容易變成「客戶心中的xxx」、「PM心中的xxx」和「RD心中的xxx」完全不一樣的結果(不過誤解還是不可避免,這只是盡量減少「人禍」的可能性)。

    當然,PM也要想辦法讓客戶「畫押」,並讓對方知道修改可能需要負擔額外成本,或是增加工時,讓對方理解他們的修改,也是要付出對應的代價的,讓對方的利益和己方一致,往「盡量一開始就釐清需求,不要太多修改」前進。

    更厲害的PM會「嗅得出來」哪些地方可能有風險,例如聽到客戶需求講得不太清楚,或是數據不太合理、動機不太合理,或者他是也是轉自第三方(或老闆)的消息或說法,就會有很大的機會,後續有新的資訊跳出來而變動,根據PM嗅出來的「異味」,他會在問題還沒發生時就盡量避免,例如,可以想辦法約到對方老闆,直接溝通需求,不要透過傳聲筒,或者是在討論初期,針對需求提出多種可能實現的proposal,用結果去逼近對方的真正需求。

    抱怨3:PM都不懂技術
    PM其實會覺得不太公平,技術以及程式怎麼寫,一定是RD最會呀!不過我發現即使是懂技術的PM,還是會被RD嘴不懂,所以我最後已經放寬心了,只要不是寫code的人,會需要RD解釋邏輯的,大概都會被嘴吧!

    不過我覺得PM還是有些基本的觀念與認知需要弄懂,不需要會寫程式,但是重點是關於產品設計的know-how、哪邊可能有問題、導致問題的原因是什麼、釐清問題的步驟、不同模組之間的合作或介接關係是什麼等觀念。

    這可以協助PM和RD溝通、釐清問題,也可以讓你初步聽到需求時,能很快知道風險與難度在哪裡,快速與客戶做進一步溝通,因為面對客戶時,PM要戴上的就是「開發團隊代表」的帽子了,客戶對於可行性、風險、工期的初步判斷與期待,一般都是先對PM溝通,此時PM若心中有一個大的藍圖,就能很快釐清需求、建立期待。

    拿到實體世界來講,假設你要蓋一間房子,PM可能不必有土木師傅或是建築工程師的功力,也不用親自設計出建築設計圖或水電配置圖,但他要有個敏銳度,這邊的施工是不是已經偏離設計圖了,是不是少了防火梯,可能會造成什麼風險?為什麼會這樣?如果硬著頭皮不做會怎麼樣?延宕要花多少錢?要怎麼跟業主溝通?

    這樣的PM算「懂技術」嗎?其實我覺得比較像是「專案或產品的know-how」,PM也應該要有認知,對於每一個專案細節,PM一定無法比實際執行的人懂,但是對「全局」的綜觀與掌握,以及A事件若發生,有多大的可能觸發B,PM要怎麼執行C,讓事件的影響變成D,然後要如何、跟那些人溝通等處理流程。

    PM的力量
    總而言之,我認為PM是資訊的匯總角色,很像任意門,每天一睜開眼睛就是要對接老闆、業務、行銷、開發,甚至是客戶、用戶等等角色,心中有個藍圖,頭上戴著不同的帽子,滿足不同的期待,做著所謂「見人說人話,見鬼說鬼話」的人生,PM需要找到自己的定位,發揮自己的價值,做起事來才會事半功倍。

    本文由Evonne Tsai授權轉載自其Medium。