產品和程序員梗

① 為防被程序員「砍」，產品經理需要注意這些場景

互聯網行業中，眾人熱衷於討論「程序員砍產品經理」。雖然，「砍」更多是調侃的意思，一種消遣工作的方式；但是，這不是一個飯後笑話，側面反應了產品經理和程序員間的對立關系。很多時候，產品經理和程序員間就像對手，產品研發過程就像打仗，總要爭個你死我亡。「砍」的本質，是程序員表達對產品經理的不滿，也是一種情緒的宣洩。

在產品研發的過程中，產品經理與程序員對立關系，會嚴重影響項目的推進。一旦產品經理和程序員對立關系公開化，很容易導致團隊人心渙散。這種對立關系，經常滋生出一些極端的事情，罵娘、打架已屢見不鮮。

下文就列舉一些程序員想砍產品經理的場景。這些場景都是我過去和很多程序員朋友交流時，他們遇到的對產品不滿的場景。這些場景，都會以產品經理的溝通話語表現出來。通過這些場景，去解析這種對立關系產生的原因。以及，作為對照，產品經理應該如何規避和處理這種對立關系。

這樣說法是程序員們最不喜歡的，最容易惹毛程序員的。這句話，在程序員們看來就是削減工時、加班的代名詞，他們當然不喜歡。而且他們也非常討厭，一個非技術人員為技術人員做技術難度的定論。簡不簡單，都需要技術人員做了技術評估，才能下結論。

這種言語，會讓程序員們覺得產品經理不靠譜。大家通常都是比較排斥借鑒。借鑒你也得有合理明確的理由。以我某程序員朋友的話來說：微信怎麼做的，你就怎麼做，那你不如去微信做產品算了。

每個產品，在表面的UI下，都有其背後的復雜的業務邏輯。如果產品經理只是叫程序員照著某個產品做，很多時候技術們是很難實現的，因為他們也需要弄懂背後的邏輯和流程。當然，這應該是產品經理的工作。

這就是抬杠。產品經理雖然名字裡面有「經理」二字，但並沒有經理的權利，當然不能命令合作的技術們。這句話，言下之意也是拒絕了商量和討論。而程序員也需要參與感和團隊感。

這就是質疑他人能力，是人都不會喜歡。如果產品經理提出的方案，程序員們沒有理解。那就說明產品經理的解釋說明和文檔，做的不夠優秀，不夠簡潔易懂。讓程序員們理解需求，是產品經理的基本工作內容。

在互聯網產品開發中，修改需求和插入新需求都是挺常見的。對於程序員們來說，這是非常不爽的事情。這種操作通常會打斷程序員的思路，思路被打斷是非常痛苦的。當然，這樣也會影響他們的開發效率。更可怕的是，反復的修改需求，會使他們有種勞動成果不被尊重的感受，同時也會對項目的未來抱有懷疑的態度。反復的更改方案，也說明產品經理設計是未經過嚴密的論證，或對細節的把控是不夠。

程序員都比較討厭反復的催促。當項目的節點確定後，技術們會嚴格遵守節點，產品應該信任他們。當然，時間比較緊湊時，反復催促也會加大程序員們的壓力，使他們變得非常煩躁。在這種時候，催促就是添麻煩。

甩鍋會導致團隊分崩離析，人心不齊。不管任何問題，都是團隊的責任，不要將責任指定給某人。特別是在項目復盤時，如果心態不好同事，這是非常難堪的。所以，我們要盡量以原因和結果為導向，而不是責任為導向。

程序員也是也是團隊的一份子，有權利知道知道需求的背景。同時，了解需求背景也利於程序員們更好的開發程序。

產品經理給程序員們畫餅是最不切實際的，只會引起大家的反感。程序員都是喜歡偏實際的東西，虛的東西只會招致白眼。

任何傳遞給程序員的需求，都是需要有計劃和規范的。如果口頭傳達一個需求，很容易導致開發出的功能與需求不匹配。同時，因為缺乏相關的記錄和文檔，可能會造成需求流失。這對於程序員們來說，可能就是延遲、加班、返工、擔責等等風險。這是團隊合作的大忌，也是項目管理不專業的體現。

以上的這些場景，可能出現一次，程序員們都會順著我們的想法做。但是，這會漸漸改變程序員們的心態，最終會使產品經理與程序員間產生隔閡和矛盾。如果出現這些場景，作為產品經理都需要小心的處理好，以免影響項目的正常推進。當然，最好是不要出現這些場景。作為產品經理，我們的最終目標，都是要保證我們的產品，准時、保質、保量的落地。

產品經理在與程序員們合作時，產品經理需要講究合作共贏、互相體諒。在產品經理的相關工作中，最要避免的就是抬杠。抬杠是一切矛盾的根源。很多時候，產品經理要站在程序員的角度考慮問題。比如，對於產品來說可能就是改改需求，但對於程序員，他們更在意的可能是因為改需求而導致的加班。

產品經理在工作中，經常會追求產品上的極致。追求極致本身是好事，但是切忌過分偏執。我們也需要考慮團隊的現狀和資源，在極致和現實間尋找均衡。畢竟，如果沒有喬布斯的團隊，要像喬布斯一樣做產品，只會拖垮團隊。

在產品開發的過程，改需求、改方案等項目異常，都是不可避免的。這是項目管理的第一部分。如何進行項目異常的處理，考驗的是產品經理的溝通能力和項目管理能力。產品經理需要在保持技術們高效工作的情況下，完成項目異常的處理。

當然，在產品經理工作中，矛盾的根源也並不總是產品經理。有時候，也可能是某些程序員的性格或者對該工作的態度導致的。這時候，產品經理要明確，作為團隊的潤滑劑，有責任推動和協調大家的工作。如果，矛盾不可調和，我們需要盡早提出問題、控制風險，避免「勉強」行事。

有時候，程序員在私下評價一起工作的產品經理時，總是會補加一句「我感覺我也能做產品經理」。這句話的背後，是產品經理沒有讓程序員們感受到產品工作的價值。在這種背景下，產品經理是很難獲取程序員們的注重，也會為很多爭論埋下誘因。那如何感受到我們工作的價值那？其實很簡單，就是保持工作信息的透明。將我們針對需求和產品做的相關工作，體現在我們的溝通或者文檔中。

導致程序員想「砍」產品經理，本質是產品經理工作方式的問題，也有情商的問題。在我的產品經理工作經驗中，我總結下了以下四點，我們需要注意和避免的。這四點，都可以和上文的場景相對應，是最容易慢慢改變程序員的心態的。

② 程序員桌子上放菜刀是什麼梗

產品經理:這個需求再改改。程序員拿出一把刀:剛才說啥?產品經理走了。

③ 暴風影音程序更新稱殺程序員祭天是什麼小幽默

暴風影音軟體新版本描述中，出現「殺了一個程序員祭天」這一表述，屬於「產品經理和程序員的一個小幽默」。

今日下午開始，一張截圖在網路刷屏。截圖系暴風影音軟體在蘋果商店的下載頁面，其最新版本更新於8月25日，最新動態一欄中，描述為「修復了閃退的bug，還殺了一個程序員祭天」。

引發關注的產品描述，是「產品經理和程序員的一個小幽默」。一名公關人員稱，暴風影音本次更新，涉及的工作量較大，程序員及產品經理工作要求都比較高。其表示，軟體的更新描述，是「產品經理和用戶溝通的一個窗口，很多APP的說明都很生動有趣」。

估計那程序員已經是前同事了。

④ 論產品經理和程序員的關系

我所理解的產品經理可能是更加高級的東西，可能是在程序員的基礎上去做的，只有從技術轉到產品經理你才能更多的運用你的技術來為你的產品宣傳造勢，如魚得水，而且作為一個產品經理來說你可能考慮的東西會更多，以前只是局限於代碼，而現在更多的是用戶的體驗，你需要的知識和眼界更開闊，綜合能力需要更強，希望能幫到你。

⑤ 產品經理與程序員矛盾的本質是什麼

產品的功能、質量、發布時間和需要投入的資源這四者不能都是封閉條件，否則可能無解。需要投入的資源和發布時間一般是大老闆定的，所以產品經理、開發經理和質量經理只能在「砍功能」、「降低質量要求」和「程序員加班加到死」這三個選擇上相愛相殺了。根源是：高層放衛星玩大躍進，那下面只好群眾斗群眾了。佛曰：與人斗其樂無窮。對於程序員來說，很多時候問題是 PM 不能證明自己存在的價值。PM 要證明自己的價值有幾種可能性：

1、色的產品記錄，自己的名字就是個品牌，程序員知道跟著你做事能成功。

2、假會導致產品方向混亂項目失控，這很容易證明為什麼你需要存在。

3、通過程序員可以理解的方式把道理講明白，讓程序員信服為什麼你管理產品的方法是對的，以及為什麼程序員自身不可能做得跟你一樣好。

可能還有別的方法讓一個 PM 證明自己存在的價值，但如果證明不了的話程序員就會把 PM 看作純粹的 overhead（額外負擔）。PM 對產品團隊帶來的價值和負擔是不可能客觀測量的，別人的主觀評價是什麼就是什麼。如果程序員對 PM 的主觀評價是負擔大於價值，那這個 PM 就沒有存在的意義了。核心原因是——好的產品經理永遠缺貨。當然，優秀的程序員哥哥也缺。既然都缺貨。產品經理是決定公司效率高低的關鍵，產品經理在一個成熟的公司成熟的團隊意味著靈魂和中樞，程序員哥哥不過代表著執行力和能力的邊界（想不明白就瞅瞅喬幫主馬化騰周鴻禕）：1個不知天高地厚的產品經理，2個不經過思考的決策，他的工作量也許只增加了3倍，但他賦予程序員卻是10-1000倍的工作量。

⑥ 產品經理和程序員之間如何避免矛盾

產品汪和程序猿

一、產品經理和程序員最討厭的三句話

產品經理和程序員,就像一對情人，若即若離，有時還會撕逼，和諧的時候一切都好，撕逼的時候兩敗俱傷。

你知道程序員最討厭的三句話是什麼嗎？

1、這個需求很簡單，改一下就好了

2、你先大概弄一個，我看看再說

3、我先下班了，加油啊

我想任何一個程序員聽到這樣的話都會氣炸了，不撕逼才怪，你作為程序員會如何回答這三句話？

1、這個需求很簡單？你行你來啊！

2、大概先弄一個？請問先生（女士），什麼叫大概？

3、你大爺的

你知道產品經理最討厭的三句話是什麼嗎？

1、這個需求做不了

2、這個需求工作量太大了，估計要搞3個月

3、這個變更沒時間做，往後排吧

產品經理在前端，有用戶、有老闆、有銷售，版本發布的壓力很大，聽到這樣的話估計心情也好不了哪去？

1、這個需求做不了？又不是我提的，還不是那個2B用戶提的

2、要做這么長時間？養你們有什麼用，還不如我自己來

3、變更沒時間搞？隨便，等老闆來拍你吧。

二、產品經理和程序員本質上的差異是什麼

奶爸干過程序員，也干過項產品經理，深知這兩類工作的差異，各有各的不易。

總體上來看，做產品更側重於創造和方案能力，不需要精密的邏輯，所以試錯成本相對比較低，大不了改改原型，改改方案，這個成本是可承受的。

程序員的工作是非常精密的邏輯，一個看似很小的變更有可能對代碼產生很大的影響，所以試錯成本非常高，弄不好可能會因為需求的變化導致系統的重構，這時候程序員的挫敗感是可想而知的。

三、產品經理和程序員友好相處的清單

1、產品經理收集需求後，在需求分析階段，需要把一些不合理的需求盡量和用戶溝通去掉，避免不合理需求造成產品發布時間延遲和沒有必要的成本浪費，當然這需要產品經理去說服用戶，不能只做用戶的傳聲筒。

2、需求分析時，產品經理應該根據經驗，敏銳的發現一些在技術層面實現有困難的需求，及時讓研發介入，評估技術可行性，避免後續出現需求定下來，研發說做不了的情況。

當然這需要我們的產品經理對軟體技術架構有一定了解和預判能力，你不能所有的需求都要在需求分析階段讓研發介入，這個成本也是極高的，所以要把握好這個度也是一項能力。

3、原型還是需求溝通的最好方式，這樣是避免產品和研發在需求理解上有差異的最好手段，只靠寫一些文字的需求說明書很難達到好的效果。

但這裡面要注意一點，產品經理繪制出來的原型一般是非高保真原型，是為了更好的溝通需要，所以不能完全按照原型做，需要基於我們自己的前台架構進行定製。

4、需求評審的時候，研發可能會有一些不一樣的意見，他們做了很多年的開發，會有很多好的經驗，好的經驗要虛心接受，不能覺得自己是產品就是老大，就是要按我說的做，這樣很容易造成矛盾，求同存異，目標一致，這個是最好的結果。

5、研發說這個需求做不了的時候，有兩種情況，一個是覺得這個需求實現起來比較麻煩，故意騙你；另外一種情況就是他的知識盲區，他可能確實不知道這個事能做。

產品經理需要有能力和研發進行談判，比如採用類比法（類似的需求在其它項目上咱們就做過），比如去找架構師探討技術可行性。

6、研發有時候評估的工作量會比較大，整個上線計劃拉的比較長，產品經理可以要求研發出詳細的資源配置清單，這樣能清楚的看到一個需求被分解成了多少個研發任務，每個任務的起止時間，由誰負責完成。這樣產品經理大概能看出任務的前後置關系是否合理？工作量是否合理等。

產品經理絕不能說，這么簡單怎麼要搞這么長時間，類似的話一出，絕對會激怒對方，還是要有理有據進行談判。

如果實在無法壓縮工作量，如果增加人力能解決問題的話，可以考慮找領導申請資源。如果還是不行就要砍需求或者改方案了。

7、在版本計劃定好的情況，盡量不加需求，這樣很容易打亂開發的節奏，如果一定要加進來，一定要和研發說清楚，這個是用戶領導或者老闆的強制要求，轉移矛盾。如果可以的話，增加了需求盡量推遲上線計劃。

8、開發過程中如果需求有改動，需要及時更新需求文檔，同時發給我們的研發同學，否則只是靠嘴說一下，很可能研發的同事就不做了，所以一定要落到紙面上。

9、上線的時候要堅持和研發同事一起加班，這樣大家才是一個團隊，贏了一起狂，輸了一起扛。

10、最後一點，就是要多交流，沒有什麼問題是一頓火鍋解決不了的，大家關系好了，很多事情溝通起來自然容易，而且也會更信任對方，這樣就萬事OK了。

⑦ 程序員叫程序猿，產品經理叫產品狗，工程叫攻城獅，那麼設計師和測試叫什麼

設計叫設計獅；測試其實也需要寫代碼的，寫測試腳本，如果做白盒測試的還得會看開發的代碼，也可以叫程序猿。但男性叫程序猿，女生就好一些了，叫程序媛。

⑧ 程序員有什麼好玩的梗

1、一個微軟工程師正走在路上，突然聽到一隻青蛙說：「如果你吻我一下的話，我就會變成漂亮的女人，我們可以結婚，從此幸福地生活在一起。」工程師看著青蛙想了一下，抓起它輕輕地放在自己的上衣口袋裡。青蛙把頭伸出來說：「怎麼，你不準備吻我嗎？」「是的」，工程師說：「我在微軟工作，沒有時間娶妻——不過有一隻會說話的青蛙還是挺酷的。」
2、北京程序員xx遭遇車禍成植物人，醫生說活下來希望只有萬分之一，喚醒更為渺茫。他的Leader和親人沒放棄，他們根據xx視工作如命的作風，每天都在他身邊念：「xx！IE6側邊欄又亂了，線上BUG啊！快起來改！」奇跡發生，xx醒來，第一句話：「我這是好的。」
3、一個年輕的程序員和一個產品經理登上了一列在山裡行駛的火車，他們發現列車上幾乎都坐滿了，只有兩個在一起的空位，這個空位的對面是一個老奶奶和一個年輕漂亮的姑娘。兩個上前坐了下來。程序員和那個姑娘他們比較曖昧地相互看對方。這時，火車進入山洞，車廂里一片漆黑。此時，只聽見一個親嘴的聲音，隨後就聽到一個響亮的巴掌聲。很快火車出了山洞，他們四個人都不說話。那個老奶奶在喃喃道，「這個年輕小伙怎麼這么無禮，不過我很高興我的孫女扇了一個巴掌」。產品經理在想，「沒想到這個程序員居然這么大膽，敢去親那姑娘，只可惜那姑娘打錯了人，居然給打了我。」 漂亮的姑娘想，「他親了我真好，希望我的祖母沒有打疼他」。 程序員坐在那裡露出了笑容，「生活真好啊。這一輩子能有幾次機會可以在親一個美女的同時打產品一巴掌啊！」

⑨ 程序員會被取代么

我個人認為，程序員是無法被替代的，AI應該是可以讓程序員的工作變得簡單，門檻變得越來越低。

但是，要想完全的替代，那是不太現實的。

原因：

程序員在研發這些應用程序，其實都是面向一個實際的業務場景的，這個業務場景可能有非常復雜的流程，可能一個簡單的邏輯背後，是非常復雜的代碼。

而將這些業務邏輯整理成為一個可以應用的方案，是產品的責任，將產品的業務設計、產品設計轉化為代碼並且最終形成一個可交互的應用程序，那就是程序員的工作了。

而看過很多程序員段子的人也應該聽過，產品和程序員之間的矛盾，這都是需要人為的進行調和的地方，如果，現在程序員被機器所替代了，先不說產品的需求丟給機器人，機器人看不看得懂，我們就先假設機器人已經智能到可以閱讀設計文檔了。

如果一個機器人給產品經理說，不好意思，你這個需求無法實現。這個時候，機器也不大可能像人一樣會聯想很多業務邏輯，然後和產品經理溝通，可以就是簡單的給一個答復，然後問你，你要的是不是這個？

⑩ 程序員和產品經理究竟哪條路更好

如果你本身喜歡寫代碼，那麼我覺得程序員的工作挺好的，未必要做產品經理。程序員主要是和機器、代碼打交道，工作難，但是邊界清晰、可控，事情比較聚焦。我並不建議大家都要去做產品經理。
寫代碼是純手工業勞動，大家平時用的各種互聯網產品，都是程序員一行一行代碼寫出來的，還要考慮代碼的邏輯，解決各種Bua等等。如果想做好程序員，就一定要熱愛寫代碼這件事。優秀的程序員，都能夠從自己的工作里獲得樂趣。我認識很多優秀的程序員朋友，我非常尊重他們，而且也特別佩服他們的能力，還有對於工作的熱情。

產品經理要解決的問題的要更綜合、更廣。例如要考慮用戶需求，考慮市場、業務情況，還要考慮和設計、運營、研發之間的配合。

有一些人適合做產品經理，有一些人不適合。我也不太建議大家一窩蜂都去做產品經理。我建議就像做產品一樣，你要大膽假設、小心求證。如果要做產品經理，就多了解這方面的信息，多試試，然後看看自己適不適合。

無論是學生，還是想轉行的人，往往的問題在於糾結太多，想的太多，嘗試太少。如果你想做程序員，那你先寫寫代碼，先做出一些東西，除了看你自己適不適合之外，也能夠成為你找工作時的籌碼。如果你想做產品經理，那麼多試試做做產品，哪怕是虛擬的項目，增加自己的經驗和感知，也能夠成為找工作時的籌碼。

所以，並不存在說產品經理或者程序員到底哪個更好，相比很多行業和職位，產品經理和程序員這
兩個職位都應該是非常好的了。做的事都有意思，工資待遇也都高。
關鍵在於你自己適合哪個，這個問題歸根結底別人沒法回答你，得靠你自己通過了解更多知識來做出判斷。