程序員和產品經理打架圖

① 下面這張圖 誰是程序員 誰是產品經理

你好。
請問你的圖呢？
我在網站上看到的，一般是產品經理帶動著程序員，牽動著程序員在走，所以產品經理都是會走在前端，且會大步往前走的。

② 一張圖 將程序員 產品經理 設計師眼中各是什麼樣的

當然不一樣啦，要不就只設置一個崗位了，二者的著眼點完全是不一樣，產品設計師的職業發展方向就是產品經理，產品設計師只是一個過渡而已。

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

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

④ 產品經理如何避免被程序員毆打

首先，從做人方面 產品經理還是要以身作則，雖然從職能上就已經決定了程序員和產品經理肯定是有一定矛盾在，不管是誰都是能夠相互體諒的。在我做程序員之前，我做過一段時間監理，對於剛剛畢業的畢業生來說，施工隊肯定是看不起我這樣的小孩的。所以在指出問題 或者 想要檢查的要求時，或多或少，他們都會有點反感。這個時候除去交流的技巧外，還要注意要盡可能參與其中，比如你要檢查樓頂的設備是否安裝完善，但22層的大樓，電梯也沒有，這個時候，你就應該和他們一起一樓一樓的爬，只有你參與進來，也付出汗水，其他人才不會說什麼。也不敢說什麼。產品經理也是如此，對於軟體產品的開發，不僅僅只是發號司令，我覺得更應該參與的整個環節中去；
另外，就我本身程序員的身份，我覺得程序員最苦惱的問題，無疑就是需求不明確或者不合理。這個時候產品經理不僅僅要服務好需求方，也應該為後續可能出現的情況做評估，減少需求改動並合理的拒絕一些不能接受的需求。

⑤ 什麼仇什麼怨，程序員設計師與產品經理的愛恨糾

哈哈哈，程序員和產品經理可以說是死對頭啦。
1、頻繁改需求
如果項目經理想要整死程序員，頻繁改需求是最快的辦法。特別是做了一半硬是改掉需求，scrum里的表現就是sprint內的非受迫需求變更，太狠了，技術同學表示不能忍。
2、拿老闆和運營做擋箭牌
不說清需求價值，當技術童鞋問「為什麼要做」的時候，支支吾吾，或者說「老闆要的、運營要的」。最絕的就是說，這個功能老闆說必須要做，那個功能老闆說明天就得上……
3、扮用戶
程序員會產品經理溝通的時候，比較經常就是聽到，「關鍵字是用戶不會這么覺得，如果我是用戶。」
這種產品經理通常關注點會有問題，比如更多的時候討論的是這個按鈕是這么顏色，應該放在哪裡，文案應該怎麼寫等，如果把這些問題當做核心，那難免會讓人啼笑皆非。

4、口頭禪——不就是xxx
有些產品經理口頭禪：不就是xxx，這也引來一些程序員的反感。
比如「這個問題不就是在資料庫里加個欄位就可以解決了嗎?你要是沒時間，我給你寫個SQL 語句，你執行一下吧。」結果程序員一臉懵逼。
其實，如果是在你的非專業領域里，最好少用這種「不就是XXX」這樣的句型為妙。
5、不懂裝懂
特別是對技術一竅不通的產品經理，會不停讓程序員加班趕工。
「開發大哥，我代碼寫的不多，你可別騙我，這么簡單的需求，明明一下午可以搞定，你跟我說一個星期?」
此時，想必程序員口袋裡50米大刀已經飢渴難耐......這種產品經理叫程序員哭笑不得。
希望可以幫到你，謝謝！

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

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

⑦ 產品經理和程序員,如何避免矛盾

產品實現是你的目的，為了這個目的不必太講究。

做了一陣子之後我有了自己對於與程序員相處的方法論，對這句話並不苟同，我還是傾向於把事做好的同時也能把話說好，雖然我現在也能深刻的領會到當時leader的核心意思是產品本身是第一位的。

接下來我就闡述下自己的一些心得：

• 產品經理與程序員最大的矛盾在於——改需求。這牽涉兩個問題，一個是如何盡量地做足前期工作，盡量把需求細化，需求做的足夠扎實就會大大減少改需求的次數，這是產品本職工作，不屬於溝通問題；另一個問題就涉及如何溝通了，就是需求無論如何確實要改。這個時候有一點很重要就是努力與程序員（或者開發經理）達成共識，比如「我們的目的是要做最好的xxAPP」、「這個功能對於我們的目的來說是必不可少的」等，然後再來談詳細的需求點，程序員也就會逐步認可改需求這件事情。（還有一點很重要的就是，如果無論如何也達不成一致，也有必要反思這個需求是否真的有改的必要？）

• 用數據和客戶來幫你增加底氣。在談論某項功能實現的時候，產品經理經常會碰見程序員消極被動不願意做，或者質疑這么做有沒有道理的時候，採取需求依據的數據和真實的客戶需求是能有效推進的好辦法。比如「80%的同類產品都有這個功能」、「每周都能收到幾個客戶對某某問題的反饋」，一般來說程序員是能夠接受這種說服的。

• 試著多用詢問的語氣。讓程序員感到他是專業的，他是能夠解決這個問題的，要依仗他才能做的更好。這會無形中賦予他一種責任感（因為你把問題拋給了他，他就隱形中負有解決這個問題的責任），在傳達出意願的同時也避免了話語的生硬，讓程序員感受到對其職業技能的尊重。

• 注重日常交往。日常生活中交個朋友，比如一起打球、打游戲，聊聊電影和漫畫，實在是沒有共同語言就經常沖他賣個萌、攪個基、撒個嬌、講個笑話。這樣，大家都是朋友了，不看工作職責的那一半看交情的那一半，溝通起來也會順暢很多。

總結：有很多時候產品的產生不完全是靠嚴格的流程和規章制度誕生的，也需要很多溝通的潤滑。能夠開開心心地把產品做出來最好，但是最終我們還是不能離開產品實現這個 標的物。

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

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

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

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

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

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

⑨ 為什麼程序員分分鍾想砍死產品經理

產品經理是不懂技術的，所以需求方面也不知道工作量有多大，自然在工作中問題會很多，而且產品經理常改需求，這是讓程序員不能忍受的。但也沒有什麼辦法，有時候這個需求也是來自老闆的。