為什麼在程序員或者其他崗位的人眼裡，PM 是一個很輕鬆的工作？

01-04

技術要轉產品，測試要轉產品，編輯也要轉產品，難道因為門檻低＝工作輕鬆嗎?

題主和我宿友，同時也是一塊做項目，而我正是RD

天天堵在我宿舍門口，給我畫原型圖，讓我給他做程序。

畫完原型圖，他就回去玩遊戲了，或者晚上出去擼串

而我只能默默的寫代碼

多麼的凄慘

每每我還沒下班，題主早就下班，泡著茶，吃著肉

我還在苦逼找BUG

題主真討厭

今夜讓你明白...

門檻低且招人的時候軟性技能識別困難，會導致很多PM都相當水.

專業技能不是人人都可以做，但是軟技能只有高低之分，人人都能做，做得好不好是另外一回事。很多人做不好但仍然擔任PM的位置,僅僅因為他應聘了這個職位並且被錄用了。有專業技能的人，不見得不擁有這些軟技能，職位分工不同而已。

專業工作，內容和檢測標準都很直觀。而PM工作內容定義模糊，很容易划水，靠譜的PM會承擔很多工作，自己會想得很周全。而不靠譜的PM呢：我要有聊天功能，程序狗，給我弄一個吧。神馬？你要具體的需求？難道你沒用過QQ？

本人程序狗，很敬重有能力的PM，因為需要相當高的綜合素質。但是，現實是，很多PM都很水啊！

解決這個矛盾很簡單啊：程序狗高工資低提成，產品狗低工資高提成對產品成敗負責，就不會有轉崗的想法了呀。事實上很多公司已經這麼做了呀。看在錢份上，哪怕心裡覺得產品狗SB，如果工資上有優越感，那就默默的忍了, 和諧共處。

比寫代碼簡單多了╮(╯▽╰)╭

至於說神馬心累……你試過debug一個沒有注釋和文檔的項目么？你試過跟同事交接時亂糟糟的類圖和時序圖看到吐么？

別鬧了，程序猿比你們想像的累多了

---------------------------------------------

不服可以試試，任何一個編程3年有正常人性格的程序員，轉行去做產品，兩個月培訓，能比70%那些幹了三年的的產品經理更加優秀，至少是不遜於人還是沒壓力的。

把產品拉一個出來去坐程序員，倆月培訓，能達到大專畢業生水準么？

PM不需要像程序員那樣持續高強度的加班，而且程序員在事實上承擔著後續的各種責任，包括本屬於PM的那部分（比如設計不合理導致的修改）。理論上來說PM並不是低門檻工作，事實是另外一回事。前面有同學提到軟技能，我就呵呵兩聲。。

因為它們都被產品狗氣啊，這跟我們被公務員氣了之後都想當公務員是一樣的

產品經理的作用對於一個項目至關重要，影響是巨大的。

他可以是部門間溝通的紐帶，可以是整體進度的控制者，甚至可以是整個項目的管理者。

就但從模糊的工作內容定義上就可以發現，其實產品經理是個需要操心很多事的人。

而目前來說，很多程序吐槽的，無非是一點，這個產品經理就每天到處說話，沒什麼技術。

換句話說，沒有讓開發認同的技術表現在眼前。另外除了說話之外，表示感覺很閑。

作為一名二流的測試，三流的開發和不入流的產品經理。

我表示每天用三種不同的身份與人溝通，那種壓力，你們可以自己試試。

而作為產品經理，項目的好壞直接和你的評價掛鉤，那種壓力知道的人自然知道。

因為程序員都相信 "Talk is cheap ,show me the code". 而PM很多時間都在 Talk talk talk.

在老闆眼裡都是給他幹活的狗。偏偏還喜歡互相鄙視。

我也來舉個例子。。

PM苦死冥想，對比很多其他產品，看了很多相關案例。然後跟coder說：我覺得這塊功能還能再做細點強化點。

CODER說：好嘞！

CODER開始工作了，做下需求分析（大部分PM給過來的需求都是不能直接用作開發的需求的，雖然大部分PM覺得自己做的很細緻了）。整理下原先數據的結構並把新功能要調整數據欄位加上去，設計好代碼的結構，把需要實現的每個坑都挖好。

然後，看看這個業務邏輯是否正確，覺得 OK，就開始開發。

每個坑填滿之後，開始測試，並且對於問題的片段進行debug。

差不多1~2天，新功能就做上去了。

PM開始觀察新功能的使用情況，查看用戶的反饋。發現，凡響不是很好，和自己想的不太一樣，但又說不出為什麼。可能沒有達到Apple級別的用戶體驗吧。然後，苦思冥想了一天，跟coder說：「那個xxx功能先去掉把。」

CODER：「。。。。」

很多PM根本就不是PM。

本來，PM應該是串起項目整體流程的職位，可是很多PM以為自己是管理程序猿的職位。

需求的設計，不尊重市場以及不分析現狀，盡喜歡說空話大話，不會抓需求重點。

產品的設計，不理解美術工作，不考慮技術實現的可能性，只懂得吹自己的逼格。

文檔的生成，不能沉入項目之中，只以能出結果當第一要務，甚至會脫離現狀，直接找一個外部跟項目需求完全不搭的別人的作品讓開發者和美術照抄。（這時候完全忘記了自己吹過的逼格了）

項目的安排，不能協調整體工作，以強制他人加班當作自己的協調能力。而往往別人加班的時候，他自己並不參與工作的協調，早早下班了事。

這樣的PM，難道不是一個很輕鬆的工作？

一方面，各個工種都想轉PM，是因為在太多人眼裡，很多「隱性技能」根本就不是技能。

比如說「溝通技巧」，比如說「規劃組織」，比如說「向上溝通要資源」，比如說「保持團隊士氣」，比如說更玄乎的「產品感覺」。

這些技能無法產生任何可以用肉眼見到的成果，但程序員創造的可是一行行實打實的代碼啊！

試著換位思考一下，你是一個程序員，你每天的工作是碼代碼、碼代碼、加班碼代碼，

然後你看到那個指揮你碼代碼的人神龍見首不見尾，就是見到的時候，很多的時候也是在跟人說話、跟人說話、加班跟人說話……

你心裡會平衡么？

更重要的，一個產品的誕生，程序員寫了代碼那是Hardcore，UI、交互做的東西更是肉眼可見隨時被噴，你PM做的東西呢？

另一方面，我揣測是程序員或其它專業技術人員的一個發展恐慌。

私下裡太多程序員問過我這個問題了，「30歲之後怎麼辦？繼續寫代碼么？50歲之後怎麼辦？繼續寫代碼么？」

作為一個知識幾乎三天一小變五天一大變的技術行業，這種對未來的恐慌是可以理解的。

那你的發展方向呢？環顧周圍，程序員轉UI？難，專業槽太深，且UI還在那兒自己恐慌著呢。

PM？恩，不錯，肉眼看上去工作很簡單，且再不濟也是個「經理」啊！叫出去也比較有面子。

So，也許也真不是他們覺得pm很輕鬆，只是他們想要為自己的未來打算。

話又說回來，就是程序員真的當pm，也說不準真的可以當好；同理，UI、交互也可以成為好的產品經理，有機會，應該讓他們多嘗試，產品做成功了，那固然好，哪怕做失敗了，至少也可以讓他們了解pm的工作。

唯一的問題，大家都來當產品經理，誰來給我寫代碼啊！後天deadline！趕緊把手上的bug改完！這個產品做好了，下次讓你嘗試做一個小產品哈，乖~~

—————————————7月10日————————————————————

回應 @張小苗

1、要承認不同崗位間對互相工作的理解是有偏差的，所以對於自己不熟悉的工作的片面理解是客觀存在的，哪怕表面上你看不出來，不跟你說，工作一團和諧。

2、真正深入對方的內心了解對方的想法，怨念可以有，吐槽可以有，但是大家共同有著一個更高的目標，就是做一個好的產品。以此為目標，建立在互相理解基礎上的偶爾痛快的吐槽，誰都不會把它當回事兒，玩笑而已，何必認真。

3、無論你是從開發轉過來，還是從UI、交互轉過來，還是直接做PM，我認為PM應該給自己在團隊中的定位只有一個，就是「那個啥都不會啥都要諮詢大家但是能讓大家做事兒挺有勁且能真正做出東西的二貨」。

4、很高興我被認作是一個程序員，說明我和程序員朝夕相處交心暢談的時間都沒有浪費。

5、我是一枚PM。

—————————————7月11日————————————————————

關於 @趙明登和 @張大牙的回復，我繼續補充。

其實，本不想回復你們的評論的，因為你們實在是怨念太深，我就算回復也很難改變什麼。

但，如果真的放著不管，我怕這個問題又成了PM和coder們互噴的地方了。

我不想看到這個，所以還是補充兩句吧。

這裡，我想先說幾點跟這個主題無關的東西：

1、真誠的溝通，最終要的前提是傾聽別人的想法。

請大家評論前，先確定自己真的看完了我的回答，因為你們的一些指正讓我很迷惑。我反覆看我的回答，根本就沒發現我有提過你們說的一些觀點。

2、不帶偏見看問題，很難，但還是希望大家能試著做一下。

比如說，當腦子裡裝著對PM的刻板印象時，只要出現PM這個Title，馬上一個「油嘴滑舌、頤指氣使」啥啥的形象已經瞬間被腦補起來了，於是已然豎起了渾身的刺，根本不會在意這個人在講什麼。

3、同樣的問題，你可以從積極的方向理解，也可以從消極的方向理解。恩，我覺得前者更好些，不是么？

PM這個崗位的工作，在不同的組織里，差別是非常大的。我不否認確實有不合格的PM的存在，大家也都受過委屈，感受過種種不公平……但，如果你把這個當成你生活的常態，那麼它有可能真的成了你生活的常態。

請積極的對待這些問題，嘗試著去溝通，表達自己的訴求；如果雙方真的都是真誠的態度，那麼應該不會有什麼問題是解決不了的；如果再三嘗試還是不行，那麼你可以換個環境。如果你發現無論在哪兒你都是被欺負受壓迫的，這種情況下，還是反省一下自己吧，我覺得問題更多的可能出現在自己身上。

好了，雞湯喝完，來來來，我們先來找找共鳴。

若干年前，我也寫過代碼，跟弟兄們徹夜改bug，在滿是紅燒牛肉麵味道的房間里對著屏幕光著膀子大罵那個隔三差五改需求的客戶。

可能我做的事情還更多一點。如果真的需要，我也可以做交互、做UI，平面設計也能搞個七七八八，逼急了也能切個圖寫個頁面應付客戶抗兩下。

後來沒在coding或UI之類的專業技術方面發展，是因為我發現在這些方面，我做的都不是最好的。而我的優勢，可能是將這些亮閃閃的技術、設計與現實中已有的傳統模式結合起來，讓這些東西產生更大的商業價值。

於是我就就這樣做了，也不知道那一天，就發現自己成了傳說中的PM了。

但，請相信我，糊弄著做，哪個崗位都可以簡單；但真要認真了，沒有什麼工作是簡單的。

還在上大學的時候，當別人問起我以後想做什麼時，我曾說過，只要不是財務、行政和HR，其餘工作我都能做好。

不做財務，是因為我看著數就頭疼；不做行政和HR，是因為我主觀的認為這兩個工作「太沒技術含量」。

隨著閱歷的增長，我終於知道我大學時候的想法有多麼的天真可笑。

現在我所在的行業，恰恰與我當時「不屑於」做的HR高度相關，在與這個行業的大牛們學習交流的過程中，我深深的為我自己之前的想法愧疚。

要把我手上的產品做好，我要學的東西已經夠我去讀一個在職碩士了，哪怕就是如此，我們與世界最先進的技術相比，差距還是很大。

隔行如隔山，真的是如此。

扯遠了，回來。

好的PM，從來不會把自己title裡面那個M當回事兒。

大家共同的目標是做一個好的產品，儘管工作過程中，種種衝突摩擦在所難免，但有了這個大目標，Who care？鬥鬥嘴緩解一下壓力，吐吐槽清爽一下神經，然後該幹啥幹啥。

至於什麼「升職」、「向上爬」？費那心思幹啥，產品做好了有了足夠的收益老闆自然會給你回報，不給回報你們就把老闆炒了唄。至於title這東西的價值，不過是印名片兒上唬人的東西。你告訴我你想印啥？「XX公司大中華區技術開發總監」怎麼樣？好，我讓行政幫你去印，回去儘管和你發小炫耀去，別去客戶那兒瞎顯擺給我搞烏龍就行。

好的PM，也絕對不會不尊重coder或者designer。

我在原文裡面已經提到，PM應該給自己在團隊中的定位只有一個，就是「那個啥都不會啥都要諮詢大家但是能讓大家做事兒挺有勁且能真正做出東西的二貨」。

就算你是coder出身，在PM這個位置上，你也得把自己coder方面的知識格式化一下，尊重真正專家的意見。至於什麼「他們懂技術，沒法糊弄……」

這個問題根源不在於PM，而在於招聘沒做好。這種「躲在專業槽後麵糊弄別人」的人，且不說就不應該將其納入團隊，就算之前看走眼不小心讓其漏網了，只要在工作中出現這樣的問題，就應該從團隊中將其清除掉，否則貽害無窮。

至於「多少PM一年內轉型成精通2到3們語言領域的coder……」

其實啊，世界無難事，只怕有心人。這話你信么？

我認識學建築材料出身，第一份工作在某航空公司做部門經理，然後辭職去德國留學，從編程幾乎0基礎學起，最終能夠完成獨立的火箭燃料控制系統編程的人。

我看過高中畢業，然後在飯館打工，自己第一台筆記本都是買的二手，買不起書天天到書店抄筆記，成功應聘某萬人嚮往的互聯網企業的人。

我同事也給我講過他的一個朋友，外科大夫，成功轉職做Maya的故事……

總之，千言萬語一句話，別把別人的工作想得太簡單，也別把自己的工作想得太難。工作生活中總有太多因素你不可控制，但至少你可以選擇自己的態度。

因為抄襲本來就沒什麼技術含量，有實力的產品另說。

pm心累

我小的時候體力不好也不懂足球，所以認為守門員是一個很輕鬆的工作。

這屆世界盃上，表現神勇的哥斯大黎加門將納瓦斯，平時使用高速飛來的網球練習撲救。

汝果欲學詩，工夫在詩外。

技術等要轉也是轉管理，產品做事情也是老大說的算，誰會去轉產品。並且，程序員轉產品得天獨厚，本身就懂技術再加上能扯兩邊都討好。

我們先定義PM是產品經理，以免歧義。

PM的特點不是軟技能，以及對於樓主的提問「為什麼大家都像轉PM」。要能清楚的回答這個問題，分3個段落：

PM的工作行性質是怎麼樣的，大多數工作都是溝通協調中用軟技能來體現的嗎？

一個常規的PM，他的常規工作一般包含如下

商業信息調查與分析。需要統計學基礎，需要對行業整體信息掌握比較全面，並且能預測趨勢。

產品規劃和設計。規劃產品線或者產品，搭建產品框架（不同於技術上的架構設計），

分解產品包，並且具體產品的特性進行分類，
配合工程師開發，對產品問題進行解釋，對完成產品或模塊組織驗收
協調資源以配合進度
上通下報

這些工作多少可以定義為軟技能要求呢？軟技能是很難量化的東西，而且通常你以為的軟技能，低下需要非常大量的硬技能。

為什麼工程師覺的PM的工作輕鬆?或者將為什麼普通認為PM相對於工程師輕鬆？

PM的工作強度其實很大，要做好一個PM非常困難，我說的是做好，而不是做出名。那為什麼會有PM輕鬆這種說法呢？

「門檻低」。其實PM的門檻不低，在產品同質化、快速更新的壓力下，互聯網公司會快速大量的推出新產品或新版本，需要大量干體力活的人員來程序化「設計」產品。而在「製造」這些設計的設計師也往往會被命名為產品經理，在若干年前，他們的崗位名稱可能是美工、UI設計師、產品助理…
如解磊說的，崗位理解偏差。 PM也不會向大家彙報自己每天的日常工作。而處於後端工作的大多數人並未接觸過產品管理的前端工作。
作為一個PM，需要在白天留足別人的可打斷時間，比如早上和不同的人開會，下午做一些細碎的事情方便別人諮詢，晚上才整理相關數據整理，回顧工作，找出風險點並通報給相關人員。

為什麼工程師想轉PM？

理由太多，列舉如下：

覺的產品經理輕鬆、工程師加班加點；
覺的產品經理收入高、工程師收入太死板；
覺的產品經理可以管別人，工程師是被人管；
覺的產品經理容易積累人脈，工程師只能和機器PK；
覺的產品經理的發展是越走越寬，工程師沒有可發展空間；

當然，以上理由都可以去分析解釋。不過這樣的理由應該可以解釋原問題了。

周一才知道現在程序員考試中最高級別考試有PM專業了。

PM非常重要，不僅僅對項目，而且對每一個最低層的碼農的日常工作而言。

覺得PM沒什麼作用的人，都該好好地把PM相關的教材過一遍再說這種大話。

簡單點的項目，好的PM可以縮短產品研發周期，複雜的項目，PM直接決定產品成敗。

一個人只有在不喜歡自己工作的時候，才會想著轉干別的。

程序員選擇離開某團隊或某公司，很大程度上都和PM有關。SB的PM輕輕鬆鬆地把功勞都攬自己身上，把錯誤都歸咎於程序員；NB的PM則是想方設法為自己和程序員兩者都謀取利益，會想著顧全大局。

當下的情況是，數量上看，NB的PM &<&< SB的PM。

作為一名既不是程序猿也不是PM的"外行"，我發表點我的看法。

先問一下，程序猿工作幸苦么？辛苦！肯定辛苦！我大學期間專攻php，經常遇到各種程序問題，很多時候，我知道那樣做不好，但是我解決不了。也有很多問題，在我奮戰了1天1夜後終於豁然開朗！介於此段經歷，走出大學後我沒想過做一名專業的程序猿。（太苦逼了）

那PM或者說一個合格的PM 工作輕鬆么？我覺得不輕鬆！PM需要想當多的對行業，對用戶，對產品的理解。這些不是靠你看看文章就能學來的，是需要積累的。不同層次的PM 看到的東西是不一樣的。

一個剛入門的PM 需要對產品，用戶等做非常多的工作才能有一點能力去決定產品怎麼做。這不是做程序，行就是行，不行就是不行。PM這裡沒有可量化的標準。一切可以說是以結果為導向的。想要入行PM 簡單，想要做好PM的工作，很難。這和做營銷一個道理。

當然，如果你有任何一方面的基礎例如：美工，程序，心理學，營銷等等那你轉行做PM是有一定優勢的。但是這不代表你就能在PM這塊做的很好。