程序員產品經理打架真相

❶ 干貨！程序員需要掌握的幾種圖

隨著互聯網寒冬的的到來，程序員就業環境越來越嚴峻，這就要求我們必須要不斷提高自己，來應對高壓的工作環境。下面介紹的這幾種圖是我在工作中經常使用的，所謂的圖，都是為了輔助思考的，輔助開發的，比文字描述的更清晰，更有邏輯。
前些年，網上有一個口號喊得很響： 「人人都是產品經理」 。這就要求我們需要學習認圖、畫圖的技巧，能從需求文檔里快速的抽象出我們想要的東西。最近，網上曝出的程序員和產品經理之間的矛盾，大都是需求不清晰產生的，作為程序員的我們如果掌握的產品經理所必須的技能，那我們以後就可以吊打產品經理了，哈哈哈哈。。。

流程圖 是對過程、演算法、流程的一種圖像表示，在技術設計、交流及商業簡報等領域有廣泛的應用。

計算機語言只是一種工具。光學習語言的規則還不夠，最重要的是學會針對各種類型的問題，擬定出有效的解決方法和步驟即演算法。有了正確而有效的演算法，可以利用任何一種計算機高級語言編寫程序，使計算機進行工作。因此，設計演算法是程序設計的核心。

對同一個問題，可以有不同的解題方法和步驟。

例如，求1+2+3+…+100，可以先進行1+2，再加3，再加4，一直加到100，也可採取100+(1+99)+(2+98)+…+(49+51)+50＝100+50+49×100＝5050。

還可以有其它的方法。當然，方法有優劣之分。有的方法只需進行很少的步驟，而有些方法則需要較多的步驟。一般說，希望採用方法簡單，運算步驟少的方法。因此，為了有效地進行解題，不僅需要保證演算法正確，還要考慮演算法的質量，選擇合適的演算法。

一個計算問題的解決過程通常包含下面幾步:

傳統流程圖

用圖表示的演算法就是流程圖。流程圖是用一些圖框來表示各種類型的操作，在框內寫出各個步驟，然後用帶箭頭的線把它們連接起來，以表示執行的先後順序。用圖形表示演算法，直觀形象，易於理解。

美國國家標准化協會ANSI曾規定了一些常用的流程圖符號，為世界各國程序工作者普遍採用。最常用的流程圖符號見圖。

流程圖不僅可以指導編寫程序，而且可以在調試程序中用來檢查程序的正確性。如果框圖是正確的而結果不對，則按照框圖逐步檢查程序是很容易發現其錯誤的。流程圖還能作為程序說明書的一部分提供給別人，以便幫助別人理解你編寫程序的思路和結構。

PS：牆裂推薦大家使用ProcessOn，畫流程圖的神器！！！

心智圖 （Mind Map），又稱 腦圖 、 心智地圖 、 腦力激盪圖 、 思維導圖 、 靈感觸發圖 、 概念地圖 、 樹狀圖 、 樹枝圖 或 思維地圖 ，是一種圖像式思維的工具以及一種利用圖像式思考輔助工具來表達思維的工具。

心智圖是由英國的托尼·博贊（托尼·布詹）於1970年代提出的一種輔助思考工具。心智圖通過在平面上的一個主題出發畫出相關聯的對象，像一個心臟及其周邊的血管圖，故稱為「心智圖」。由於這種表現方式比單純的文本更加接近人思考時的空間性想像，所以越來越為大家用於創造性思維過程中。

ps:我一般都是用的網路腦圖，在線的比較方便

拓撲學（TOPOLOGY）是一種研究與大小、距離無關的幾何圖形特性的方法。 網路拓撲是由網路節點設備和通信介質構成的網路結構圖。

拓撲學是數學中一個重要的、基礎的分支。起初它是幾何學的一支，研究幾何圖形在連續變形下保持不變的性質(所謂連續變形，形象地說就是允許伸縮和扭曲等變形，但不許割斷和粘合) 拓撲圖用於計算機網路示意，也就是不考慮計算機實際的位置，只表示網路中每台計算機以及網路設備之間的相互關系。

節點，節點就是網路單元。網路單元是網路系統中的各種數據處理設備、數據通信控制設備和數據終端設備。

鏈路，鏈路是兩個節點間的連線。鏈路分「物理鏈路」和「邏輯鏈路」兩種，前者是指實際存在的通信連線，後者是指在邏輯上起作用的網路通路。鏈路容量是指每個鏈路在單位時間內可接納的最大信息量。

通路，通路是從發出信息的節點到接收信息的節點之間的一串節點和鏈路。

星型結構的優點是結構簡單、建網容易、控制相對簡單。其缺點是屬集中控制，主節點負載過重，可靠性低，通信線路利用率低。

匯流排結構的優點是信道利用率較高，結構簡單，價格相對便宜。缺點是同一時刻只能有兩個網路節點相互通信，網路延伸距離有限，網路容納節點數有限。在匯流排上只要有一個點出現連接問題，會影響整個網路的正常運行。目前在區域網中多採用此種結構。

環型結構的優點是一次通信信息在網中傳輸的最大傳輸延遲是固定的；每個網上節點只與其他兩個節點有物理鏈路直接互連，因此，傳輸控制機制較為簡單，實時性強。缺點是一個節點出現故障可能會終止全網運行，因此可靠性較差。

樹型結構實際上是星型結構的一種變形，它將原來用單獨鏈路直接連接的節點通過多級處理主機進行分級連接。

這種結構與星型結構相比降低了通信線路的成本，但增加了網路復雜性。網路中除最低層節點及其連線外，任一節點或連線的故障均影響其所在支路網路的正常工作。

UML是一種開放的方法，用於說明、可視化、構建和編寫一個正在開發的、面向對象的、軟體密集系統的製品的開放方法。UML展現了一系列最佳工程實踐，這些最佳實踐在對大規模，復雜系統進行建模方面，特別是在軟體架構層次已經被驗證有效。

功能模型， 從用戶的角度展示系統的功能，包括用例圖。

對象模型， 採用對象，屬性，操作，關聯等概念展示系統的結構和基礎，包括類別圖。

動態模型， 展現系統的內部行為。包括序列圖，活動圖，狀態圖。

實體關系圖，簡記E-R圖是指以實體、關系、屬性三個基本概念概括數據的基本結構，從而描述靜態數據結構的概念模式。

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

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

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

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

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

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

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

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

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

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

❺ 有多少人程序員真的接觸到高並發，用戶量大的系統

一場程序員與產品經理的血案，讓我們重新反思，產品經理與設計師，開發工程師到底應該如何配合如何有效的合作，從而達到共贏的狀態?珍愛生命，來讀讀@JingDesign 的這篇文章。 血案!程序員殺害產品經理? 2014年註定是一個不太平的年份，當我們還在糾結於設計師與程序員之間一像素的恩怨情仇，為馬航MH370至今還未被找到，亞航另一架飛機又墜入大海而扼腕嘆息的時候，今天下午快下班的時候，一則讓我們更有切身體會的血案開始在各大設計開發與產品經理群中傳開，據傳，深圳某辦公園區某間公司的五個程序員殺了兩個產品經理，圖文並茂，血淋淋的案發現場讓我們不禁唏噓和感到惋惜 ( 最新消息為離職員工與老闆的勞資糾紛，請以網路新聞為准，如描述有偏差，還請見諒 )。網上一下子炸開了鍋，針對產品經理，開發與設計師之間的吐槽此起彼伏。靜電的同事–一位產品經理甚至自嘲道，老闆，以後要給所有員工買份人身保險，哦不，產品經理要買十份!還有人插嘴：“看見沒，以後不要給開發搞那麼復雜的需求知道不?要不被xx了可太不值了!” 人人都是PM?產品經理的前世今生 相信很多讀者都讀過靜電的這篇《一像素的恩怨情仇!程序員與設計師的那些事兒》，緣起一像素，開發人員覺得改產品里一像素的錯位沒有必要，設計師認為如果不改，會影響產品的整個體驗，於是問題就來了，一場比電影還要精彩無數倍的故事就這么開始並且無休無止的進行下去了。其實靜電忘記說了一個角色，就是產品經理。這到底是一個什麼角色呢?咱們先把時間往前調，回到大概2000年左右，那是國內互聯網剛剛起步走向繁榮的幾年，各種網站及互聯網產品層出不窮。但那個時候，還沒有真正意義上的產品經理，有的只是剛剛接觸這個行業沒多久的開發人員和“做網頁”的。記得04-05年左右，當時靜電所在的公司，沒人知道產品經理會是怎樣一個角色，大家都憑著某些默契在工作，做網頁的做網頁，做開發的做開發，搞銷售的搞銷售，誰有需求誰提，誰來執行。直到06-07年，在做設計的我第一次開始接觸產品經理這個職位，那個時候的產品經理多半是在某一行業資歷較深的人員擔當，相當於半個部門經理。接著，產品經理越來越多的出現在每個人的視野中，不管是初入職場的新人，甚至是設計師和開發工程師，很多人都會在自己職業發展的某個時刻華麗變身為產品經理。可是這個介於設計與開發之間的角色，卻改變了每個人的工作方式。每天都跟產品經理與開發打交道的設計師朋友，相信大家一定不會陌生。 我們來看看產品經理的職能： 項目管理35% 個人能力(領導及個人親和力等)15% 業務能力(業務管理技能)20% 技術能力(技術能力對於產品經理是必備的技能，技術能力讓產品經理更好的理解產品的性能和特點，更好的進行產品的團隊管理)15% 產品經理的職能中，有很大一部分職能是協調溝通及處理沖突。15% 看過產品經理的職業技能，很多朋友可能要倒吸一口冷氣了，如此多的隱性及復合能力讓產品經理看起來真的不是那麼容易當，這簡直就是全才有木有?但不管我們願不願意，這個職位在我們的工作中越來越常見。有的沒的，經理這么高大上的職位，再加上那本《人人都是產品經理》，又讓多少人蠢蠢欲動的做起了產品夢?畫個原型圖，就是產品經理?也許不是，但我們必須接受，這確實是個不可或缺的角色。靜電認為，產品經理在是程序員和設計師中間不可或缺的一座橋梁，或者說是潤滑劑，產品經理為產品質量負責，也為各個職位之間加入潤滑劑，讓整部機器良好運轉。 什麼仇——程序猿與射雞師的煩惱 言歸正傳，說完了產品經理的職責，我們來聊一聊時不時就會出現在我們周圍的產品經理與開發，甚至設計師的那些事兒。這三者之間到底真的有這么大的仇，以至於要拔刀相向，兵戎相見?對於設計師與開發工程師，產品經理很多時候扮演的是這種，還有這種角色。 這幾張圖一定會是大部分射雞師與程序猿在工作中最真實的寫照。所以，我們必須來聊下，程序猿與射雞師的苦惱(深仇大恨?)，靜電總結下，大概就是下面這幾類： 催催催：十點提的需求十一點就要，完全沒有思考的時間，更別提保證質量了，做完後又要被產品吐槽做的爛沒用心。 改改改：今天提的需求明天就來個180°大轉彎，寫的代碼全部白費，做的設計被無數次推翻 指指指：悄悄的問一下各位射雞師與程序員，你們的屏幕被戳過多少次了?是不是很想摔桌子來一句you can you up! 接著分析各位射雞師與開發為什麼會如此煩惱，原因一定有很多，但靜電認為一個最重要的問題就是：在整個工作流程中，你處在流程的最下游，看圖： 相信大部分的公司都遵循著這樣的工作流程，在沒有pm的時代，流程短一些，矛盾相對較少，但由於產品經理的介入，流程變長，產品經理整理與推動需求並由設計師與程序員執行。想想自己在工作中是否很晚才知道上邊的決策，產品與其他部門討論完成了，扔給你照著做就可以的方案，後知後覺，喂，就是說你的!怨念值+1 另外一點，流程變長必然存在目標傳達不清的情況，程序員不知道為什麼要這么做。大家是否玩過一個游戲：一排人站好，從左邊第一個人開始傳達一個詞語，只能描述或身體表演，下一個人依次描述直到最後一個人，90%的情況下，最後一個人得到的詞與答案完全不同。信息的准確度在傳達過程中一步步的流失，歪曲，最終產品成為一個四不像。怨念值+1 再者，處在流程下游的開發者無法掌握時間與整體進度。突擊工作，成了救火隊員，卻不知道自己在忙什麼，成就感缺失嚴重。怨念值+1 最後，在加上產品經理的不專業(比如不懂技術與設計的難處，隨意修改;沒有項目管理經驗，執行混亂)，設計師與程序員怨念值幾乎爆表。 怨念值爆表的結果大家懂的。執行者要麼敷衍了事，要麼拒絕完成，抵觸情緒嚴重，態度惡劣也就不難理解了。 說的更直白一點，在下游就出現很嚴重的問題就是，你喪失了很多的主動權，設計師與程序員大部分時候只是過程執行者，缺乏對過程的掌控以及參與的樂趣，別人說什麼就做什麼，這樣的工作，你會有樂趣嗎? 什麼怨–產品經理的苦逼與憋屈 用執行者來描述大多數產品經理的身份，相信一定會有很多人贊同。拋開上面5條產品經理必備的素質，更多的人甚至從一畢業就踏上了產品經理的崗位，以最終成為一名優秀的產品經理為目標而努力，靜電不置可否。但有一點毋庸置疑的是，處在這個階段的產品經理大部分為了積累經驗值，必然會經歷許許多多的磨練，打怪升級以取得進步。無怪乎今天下午看到產品經理血案的時候，群里很多小夥伴的反應居然有那麼一點點奇妙(這個是不對的，大家一定要冷靜~)。產品經理並不像我們想的那麼風光，他們必然會在執行及推動整個項目的過程中跌無數個跟頭，被領導，開發和設計師吐槽無數次卻毫無怨言(真的嗎?)，只不過他們大部分時候情商較高，不會表現出來。看看產品經理苦逼在哪裡? 1. 大部分產品經理只是產品的推動者和執行者，很多時候他們無力改變一些固有的現狀和決策。 2. 相比設計師，產品經理更應是個雜家，但打怪升級的過程並不會那麼順利切相對漫長，他們需要了解和學習的內容包括但不限於設計，管理，代碼，用戶體驗，市場行情等等等等等等。面對設計師的設計稿還好，指點下江山尚可;但開發工程師會用那高深莫測的技術專業術語讓產品經理如同聽天書，加上之前的各種怨念，項目執行不下去或者最終效果縮水太大，被用戶罵老版罵設計罵開發罵。 3. 老闆說要改需求，剛讓技術做的項目要推翻，只好厚著臉皮求改，可想而知，免不了又要被罵，誒。 4. 溝通方式不當，態度欠佳加劇開發與產品經理之間的矛盾。 產品經理與程序員——和平共處沒那麼難 什麼仇什麼怨?讓原本可以避免的悲劇在我們身邊以這樣的方式發生?本文無意吐槽處在流程中的任意一方，也無意為處在流程中下游的開發人員辯護，但通過以上的分析，相信大家都會或多或少的明白些什麼?那我們究竟要如何做才能讓事情變的大家都滿意呢?在此靜電提幾點自己的拙見。 開發者與設計師： 與其抱怨或者付諸暴力，不如思考如何通過改進流程與提升自身來改善現有的狀況。 1. 停止抱怨，主動溝通，由被動執行變為主動參與項目中，了解項目進行的最終目的及計劃，只有站的更高，才能看的更遠。不願溝通，不想溝通，不屑溝通，過於自我的觀念存在於很多程序員與設計師的固有意識中，這其實是大部分技術人員的短板所在，也是禁錮很多人發展的一大障礙。 2. 自我增值：不管是程序員還是設計師，都應該留出自己思考與整理思維的時間，通過一系列的自身努力提升自己。 3. 擴寬眼界：程序猿如果還只是埋頭於代碼，兩耳不聞窗外事，那就是真out了，優秀的程序員會非常有興趣了解並尊重其他同事的工作，比如問問產品經理為什麼要進行這個需求，玩一玩用戶體驗絕佳的網頁或app，提升自己的審美，你會發現這一定很有趣。 4. 心理疏導：如今看來，加上這么一條還是很有必要的。如此緊密配合的職位之間必然會發生各種的小矛盾，沒關系，大家坐下來一起聊聊，相互溝通與理解，相信沒有什麼事是大到血濺辦公室這種地步的，各個boss，領導們，這個靠你們啦! 友情提醒，這么做必然是違法的哦，不管你再怎麼不喜歡給你安排工作的產品經理。 產品經理： 1. 懂點代碼，懂點用戶體驗，懂點審美，你會發現，溝通會如此順暢，你和程序員與設計師居然可以聊到一起了。 2. 你身邊的同事是與你一起同甘共苦並讓事情邁向成功的好夥伴，不要冷落他們，適當的時候，邀請他們參與並加入你的討論會議吧。 3. 善待你們身邊的設計師與程序猿，尊重他們的工作成功，即使要指點江山神馬的，起碼來的溫柔點。比如親王馬伯庸就是一個特別溫柔的甲方 4. 成為程序猿與設計師之間的潤滑劑，他們會感謝你的。 5. 你所經歷的一切一定會成為職業生涯中寶貴的財富。 6. 中國人獸最近推出的產品經理高危專屬人身保險一定會適合大家，我不告訴你是朋友的朋友的朋友的賣保險的大姨媽告訴我的。 最後為慘劇中離開人世的同行們默哀，什麼愛恨糾葛，什麼仇什麼怨? 生命誠可貴，讓這些都隨風去吧~ 《產品經理是條狗》歌詞送給大家，願大家都能在工作中找的自己的價值所在。收聽地址： 我睡得比貓晚起得比雞還早/工作在拼體力武器得用大腦/ 左手的PRD右手的產品稿/什麼才是你想要我每天在煩惱/ 郵件又來催催催/產品開發累累累/你們永遠對對對 我是產品狗我要大聲說/產品經理是條狗/ oh狗狗狗GOGOGO/ 除了海賊只剩魔獸女神在夢里游(OHNO!)/ 產品經理是條狗/oh狗狗狗GOGOGO/ 屌絲不哭擼個夠也不會放棄加油 如果我的產品讓你快樂請摸摸我的頭 如果我的產品讓你快樂快拍拍你的手 他說加個鏈接你說搞個按鈕/70後的需求90後又沒夠 實在眾口難調想的我快瘋掉/這里省掉兩萬字別再逼我咆哮

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

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

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

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

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

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

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

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

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

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

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

❽ 暴風影音為修復bug殺了個程序員祭天被投訴舉報是真的嗎

8月25日下午，風影音軟體在蘋果商店的下載頁面更新了最新版本，出現了一段描述為「修復了閃退的bug，還殺了一個程序員祭天」。

之後這張截圖在網路刷屏截圖引發關注，有網友稱其用語輕松，也有部分網友質疑，作為一款軟體的官方說明，暴風影音類似表述有渲染暴力意味，甚至有網友曬出截圖稱，將對其進行舉報。

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

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

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