產(chǎn)品經(jīng)理如何避免被程序員打？產(chǎn)品經(jīng)理如何避免與程序員發(fā)生爭執(zhí)？

剛看到這個標題的時候，可能很多新手產(chǎn)品經(jīng)理還很納悶，被打?我還沒開始上班呢，咋就會被打呢?

曾經(jīng)看過一組搞笑漫畫，講的是產(chǎn)品經(jīng)理和程序員之間的愛恨交割。里面開玩笑的提到產(chǎn)品經(jīng)理的三板斧：這個需求很簡單，怎么實現(xiàn)我不管，不服可以找老板!當然，如果真的這樣做了，被打或者至少被針對的概率還是挺高的。

那在實際工作過程中，產(chǎn)品如何避免被開發(fā)暴揍呢?給大家提幾點建議：

第一，學會對需求說不;互聯(lián)網(wǎng)公司里面的這幫人，很討厭的一個詞是“改需求”。產(chǎn)品經(jīng)理作為直接的需求對接人，需要學會分辨需求，承擔來自需求方的壓力，或者盡量少將需求方的壓力傳遞給下游的UI、開發(fā)、測試。

這里分兩種情況討論下：

剛到公司，對需求方和開發(fā)都不熟;光腳的不怕穿鞋的，碰上改需求的情況，產(chǎn)品經(jīng)理先分析這個需求的改動是否大;比如說，只是個別地方改改文字，這種是完全可以的;如果是需求的大變更，可能需要在消化需求的基礎上，給開發(fā)團隊爭取到足夠的時間。

已經(jīng)是公司的老油條了;這種情況下，對于需求的修改，要建立自己的規(guī)則。比如說，當天上線的需求，在中午12點之前，都接受需求的小范圍改動;如果是當天中午12點之后提出變更需求，直接要求延期或者加人手，在規(guī)則層面對改需求進行限制。當然，這也是有前提的，需要產(chǎn)品經(jīng)理的個人能力得到廣泛認可，不然一個小菜鳥提的這種規(guī)則，沒人會遵守。

第二，盡量別提不靠譜的需求;之前在平安的開發(fā)團隊，發(fā)生了一個搞笑的斗毆事件;產(chǎn)品經(jīng)理提出了個需求“APP的顏色跟隨手機殼的顏色變化而變化”，且不論該需求的實現(xiàn)難易程度，這個需求做了之后的意義到底有多大?對用戶體驗的提升有多少?

產(chǎn)品經(jīng)理在接需求的時候，要對需求本身進行過濾，對于不靠譜的需求進行辨別并處理。需求是否要處理，不僅可以通過需求方、領導的反饋，還可以多做競品分析和用戶調(diào)研，確認是要做的需求之后，再進行產(chǎn)品設計、推動上線。

第三，不要對自己不專業(yè)的內(nèi)容指點江山;想象一個場景，你正在拿Axure畫原型呢，開發(fā)對著你屏幕指指點點“這里，不應該用矩形啊，用占位符!”“那個地方，弄個藍色的更舒服...”可能想當場暴揍他的心都有了。

是的，很多時候，一個有編程基礎的產(chǎn)品經(jīng)理(只是有基礎，缺少大量的開發(fā)的項目經(jīng)驗)，喜歡對著滿屏幕的源代碼，嘲笑這里BUG多，那里代碼不工整;一會兒說用的框架不對，一會兒又說什么打包工具很落伍。這個時候，開發(fā)的手上缺根棍子，不然就下死手了。

第四，將心比心，提升自己的用戶思維;可能有朋友要說了，咋還提到了“用戶思維”。產(chǎn)品經(jīng)理需要有很好的用戶思維，有很強的同理心。但不只是在針對用戶上，在工作中，對同事、對領導、對下屬等，都需要多換位思考。

比如，開發(fā)在評審的時候說，這個需求做不了。是真的技術(shù)不成熟，實現(xiàn)不了?還是說，開發(fā)難度高，需要的周期長?還是說，開發(fā)的個人能力不夠，做不出來?我們需要跟開發(fā)確認好，不同的情況，再有針對性的去處理。

第五，多充充電，找共同語言;沒人說產(chǎn)品經(jīng)理和開發(fā)一定是宿敵啊，想要成為朋友，先找找共同語言。一方面，產(chǎn)品經(jīng)理補充一些開發(fā)的基礎知識，有利于提升自己的專業(yè)能力;另一方面，多跟對方請教，有利于促進雙方的關系，當然前提是不要問太多過于基礎的問題，這樣會消磨對方的耐心。

關于如何不被開發(fā)打，我們提了五個方面的建議，對于新手產(chǎn)品經(jīng)理來說，可以好好看下，希望對大家有幫助。

猜你喜歡：

流程圖怎么畫?做為產(chǎn)品經(jīng)理的你會畫流程圖嗎？

產(chǎn)品經(jīng)理為什么學習數(shù)據(jù)分析？

什么是MRD？如何撰寫MRD？

流量池思維的核心

傳智教育產(chǎn)品經(jīng)理培訓課程