回批踢踢Tech版 ,PM到底要做啥?

2019.06.03 by
Evonne Tsai
Evonne Tsai 查看更多文章

財金人,科技人,行銷人,現為電商商業轉型部副理;10年產品行銷與管理經驗,大小公司通吃,軟硬產品兼施。

著作:打造360度行銷產品力:產品經理帶你直搗商業競爭核心

課程:http://bit.ly/2XojAZh

shutterstock
溝通是PM必備的能力,也是時常被忽略的一項技能。一位優秀的PM能在溝通交流的過程中,激發團隊開發熱情,同時將問題防範於未然。

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

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

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

抱怨1:出一張嘴不做事

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

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

扮演不同角色與人溝通,是一位PM的必備技能。
Gorodenkoff via shutterstock

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

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

做為「客戶代表」,重要的目標是讓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」如何實現,會更容易聚焦,而且這也會扣回第一點:你如何讓你的團隊真正了解需求,一起做出客戶需要的產品?

優秀的PM要能讓團隊理解需求,開發出客戶真正需要的產品。
sindlera via shutterstock

接著,做到盡量以可視化的方式溝通,例如提供相關範例,確保是不是客戶要的,或是畫出使用流程、大致的介面與行為,讓客戶更清楚做出來是什麼樣子。不然很容易變成「客戶心中的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

《數位時代》長期徵稿,針對時事科技議題,需要您的獨特觀點,歡迎各類專業人士來稿一起交流。投稿請寄edit@bnext.com.tw,文長至少800字,請附上個人100字內簡介,文章若採用將經編輯潤飾,如需改標會與您討論。

(觀點文章呈現多元意見,不代表《數位時代》的立場。)

每日精選科技圈重要消息