前陣子批踢踢科技業版上有一篇文章：「PM到底要做啥」，引起了一些討論（和工程師的酸酸與抱怨XD），其實內容蠻常看到的，都是工程師(後面簡稱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從他的角度，提出其他可行的解法。甚至一個團隊合作了一段時間，有了默契，並累積了一些對客戶的認知，有時RD會記得之前聽過的客戶需求，有機會就在程式裡加入一些優化（那時做為PM會超驚喜！），或是會主動與PM討論解法，這些都能讓整個團隊更進步，也更團結。
反過來講也有些PM會覺得，RD為什麼總是一個口令一個動作，很多顯而易見的設計，沒有講就不做，遇到也不會主動問PM，或是任何事情都要文件定義得清清楚楚才要開工，按表操課。其實，肯按表操課還是好的，慘的是文件最後寫得落落長，但根本沒人看。
其實我認為PM也可以思考，是不是雙方的溝通與合作模式，讓PM少了「為什麼要這麼做」的溝通，習慣讓RD「做就對了」，一旦習慣了這種「接單生產」的合作模式，怎麼能期待對方有對產品的熱情與ownership，主動「多做一步」呢？或是RD吃過虧，「有私下答應過」的功能沒做到，被PM拿出來highlight變羅生門，久而久之就會要求什麼都先更新文件以自保。
其實我覺得這種「公事公辦」，都是雙方合作缺乏互信以及默契的結果，帶來的結果其實是一種資源的浪費，這當然雙方都有責任，要公事公辦也不是不行，但這樣的結果PM一般會比較痛XD，所以雖然初期的溝通與互信的建立很花時間，但我認為PM最重要的「做事」，應該就是在溝通中搞定多方，而這也跟PM的專業能力有關－－如何挖掘真正的「Why」，並傳遞價值、激發熱情，是要有深刻洞察才做得到的。
抱怨2：需求一直改一直改，schedule卻沒變
其實我認為這個問題背後的問題，是資訊不透明，PM沒真正搞懂需求是什麼，心中也沒有商業價值判斷，就很容易變成傳聲筒，擋不住客人或老闆的要求，不過反過來我也必須說，奢望需求一旦確定下來都不會改的人，跟要求程式寫好測過就要沒bug，是一樣的天真呀~~
即使「改需求」難以避免，但PM還是有些能控制的方向，減少「人禍」造成的需求變更。
從基本功開始，PM至少要明白客戶或用戶這麼做的「目的」是什麼，因為一般而言，客戶開案的大目標不會有太大的改變，但是對「怎麼實現」會有很多意見，如果雙方可以在目的，也就是「Why」方面先建立共識，其實在後續的「How」如何實現，會更容易聚焦，而且這也會扣回第一點－－你如何讓你的團隊真正了解需求，一起做出客戶需要的產品？
接著，做到盡量以可視化的方式溝通，例如提供相關範例，確保是不是客戶要的，或是畫出使用流程、大致的介面與行為，讓客戶更清楚做出來是什麼樣子。不然很容易變成「客戶心中的xxx」、「PM心中的xxx」和「RD心中的xxx」完全不一樣的結果（不過誤解還是不可避免，這只是盡量減少「人禍」的可能性）。
當然，PM也要想辦法讓客戶「畫押」，並讓對方知道修改可能需要負擔額外成本，或是增加工時，讓對方理解他們的修改，也是要付出對應的代價的，讓對方的利益和己方一致，往「盡量一開始就釐清需求，不要太多修改」前進。
更厲害的PM會「嗅得出來」哪些地方可能有風險，例如聽到客戶需求講得不太清楚，或是數據不太合理、動機不太合理，或者他是也是轉自第三方（or老闆）的消息或說法，就會有很大的機會，後續有新的資訊跳出來而變動，根據PM嗅出來的「異味」，他會在問題還沒發生時就盡量避免（發現我腦中迸出異味這個詞是因為旁邊我兒子．．．|||），例如，可以想辦法約到對方老闆，直接溝通需求，不要透過傳聲筒，或者是在討論初期，針對需求提出多種可能實現的proposal，用結果去逼近對方的真正需求。
抱怨3：PM都不懂技術
PM其實會覺得不太公平，技術以及程式怎麼寫，一定是RD最會呀！不過我發現即使是懂技術的PM，還是會被RD嘴不懂XD，所以我最後已經放寬心了，只要不是寫code的人，會需要RD解釋邏輯的，大概都會被嘴吧！(RD不要戰我><)
不過我覺得PM還是有些基本的觀念與認知需要弄懂，不需要會寫程式，但是重點是關於產品設計的know-how、哪邊可能有問題、導致問題的原因是什麼、釐清問題的步驟、不同模組之間的合作或介接關係是什麼……等觀念。
這可以協助PM和RD溝通、釐清問題，也可以讓你初步聽到需求時，能很快知道風險與難度在哪裡，快速與客戶做進一步溝通，因為面對客戶時，PM要戴上的就是「開發團隊代表」的帽子了，客戶對於可行性、風險、工期的初步判斷與期待，一般都是先對PM溝通，此時PM若心中有一個大的藍圖，就能很快釐清需求、建立期待。
拿到實體世界來講，假設你要蓋一間房子，PM可能不必有土木師傅或是建築工程師的功力，也不用親自設計出建築設計圖或水電配置圖，但他要有個敏銳度，這邊的施工是不是已經偏離設計圖了，是不是少了防火梯（疑？），可能會造成什麼風險？為什麼會這樣？如果硬著頭皮不做會怎麼樣？延宕要花多少錢？要怎麼跟業主溝通？
這樣的PM算「懂技術」嗎？其實我覺得比較像是「專案或產品的know-how」，PM也應該要有認知，對於每一個專案細節，PM一定無法比實際執行的人懂，但是對「全局」的綜觀與掌握，以及A事件若發生，有多大的可能觸發B，PM要怎麼執行C，讓事件的影響變成D，然後要如何、跟那些人溝通……等處理流程。
PM的力量
總而言之，我認為PM是資訊的匯總角色，很像任意門，每天一睜開眼睛就是要對接老闆、業務、行銷、開發，甚至是客戶、用戶等等角色，心中有個藍圖，頭上戴著不同的帽子，滿足不同的期待，做著所謂「見人說人話，見鬼說鬼話」的人生（要精確判斷對方是人是鬼也是沒這麼簡單！），PM需要找到自己的定位，發揮自己的價值，做起事來才會事半功倍。
不過說起來容易，做起來卻不簡單，實際上具體上遇到不同的情況要怎麼做呢？我準備五月底在Hahow開課，談「產品經理職場學」，希望能藉由這們課，介紹如何成為產品經理，有什麼系統化的方法可以快速上手。
在正式開課之前，也會用音頻或寫文的方式，針對Hahow問卷提到的一些問題先做回答，以下是Hahow製作的問卷連結：http://sc.piee.pw/HWP6G
嚴禁抄襲，未經授權不得轉載。歡迎各媒體交換文章。
關注工作、管理、商務情報
親愛的讀者，歡迎加入「SmartM人才培訓網」Facebook粉絲團，每天更多豐富的工作、管理、商務報導等你關注與分享。
加入Line帳號，關注最新的工作、管理、商務情報，學習不間斷，精采文章不漏接。
粉絲團