作為產品經理如何優雅的與工程師們撕逼？

---

不要去跟技術同學爭論「這個有多難或者多簡單」
產品經理關注的重點永遠是「這個有多重要」
——這個重要取決於有多少用戶需要、有多需求、跟產品核心有多契合等。
只要在這個層面上達成了共識，那麼問題就自然而然地從「做不做？」變成了「怎麼去做」
嗯，這個時候請尊重技術同學的意見。

如果一個產品經理在「需求的必要性」這一點上都沒有說服技術同學
那請回過頭再仔細想想自己的需求。

---

說實話，除了在創業的時候經常跟工程師瞎鬧、吵架，在其它公司但凡流程正規化一點，「撕逼」就是嚴禁出現的現象。就算是創業時候的「撕逼」，也只是因為比較熟而已。

很多人會從抽象概念上強調，真理是越辯越明的啊、只要在理就不怕撕啊、撕也是溝通的一種技巧啊等等。在我看來是有問題的。

我過去也是這種死工科男的思維，認為只要道理在，我就不怕吵到多狠，反正最後大家認理就行。

事實上這樣是大有問題的。

如果是在雙方平等的情況下，怎麼吵架都沒關係，更容易就事論事。但是產品經理和工程師的撕逼、吵架（或者說好聽點，激烈的碰撞）是雙方不平等的狀態，前者更像甲方，後者是乙方。這樣造成的局面就是：

1. 產品經理吵贏了。工程師會覺得，有理就可以聲高嗎？有理就可以這麼吼我嗎？又不是你來寫代碼，我提出這些質疑不行嗎？你何必這麼趾高氣揚？
2. 工程師吵贏了。工程師會覺得，艹，你看你提需求這麼不靠譜，想問題不周全，給我埋這麼多坑，我以後還能不能信任你了？
3. 兩邊都沒吵贏，勉強達成了共識。工程師會覺得，你的道理都說服不了我，那你做產品經理有什麼意義？還跟我這麼吵，你這是什麼態度？

不管哪種情況，都會引起工程師非常負面的情緒。原因很簡單，從本質上說，產品經理是想主意的，工程師是實現的。想主意的一點錯漏、沒想明白的地方，會給實現方造成巨大的麻煩；而如果想得很清楚、想得很明白，那是應該做的。

經常撕的話，會讓工程師漸漸失去信任、也沒有做好產品的動力。他寫每行代碼的時候，腦海里可能都會復現當時討論功能時你猙獰得意的臉，這是件很噁心的事情。

我覺得撕逼不可取，但希望撕逼解決的一些問題其實仍然存在，在跟工程師的溝通中，解決這些問題的方式可能有這麼幾種：

1. 事前把方方面面想周全。

對產品經理來說，提的方案有明顯的邏輯問題（比如前後矛盾、不合理、有明顯錯漏），那就占不了什麼理，這也是會讓工程師失去信任的最關鍵因素——你想不清楚就來跟我提需求，是不是不靠譜？

在我們需求評審時，一旦被工程師問住了，並且回答不出個所以然，我們就認為是產品經理的失職。這種情況我們認為是等同於開發的 bug，是產品經理的失誤，要記錄在案，不斷復盤和鞭策自己。

如果方方面面想的足夠周全，那所有工程師提出的「我不覺得這個有意義」或者「我認為這個沒道理」的問題，都能用功能的業務背景和用戶需求來解答——「實際場景下，用戶會在 XXX 的時候用到 XXX，這是我們功能的初衷」或者「你覺得這個功能沒有意義，但我們通過數據/調研/訪談觀察到，用戶確實有這個需求」。

「這個... 我也說不太清」「等我去跟 XXX 再確認下吧」「你說的沒道理，你不懂」這些都是產品經理的禁用句式。

2. 塑造良好的溝通氛圍

題主有句很拗口的話「本題皆在討論溝通戰術的施行與技法，戰略上的完美亦為吾輩平生之追求，但不在此題目當中」，其實翻譯過來大概是想說：「本題不討論怎麼把需求想清楚，只討論問題沒想清楚的時候怎麼跟工程師溝通」。

首先，如果真的是想清楚了，那就跟工程師信息同步，讓他也明白所有需求的背景和價值，不要反感；其次，像我剛剛說的，如果沒想清楚，那就是產品經理的失職。錯漏經常在所難免，但既然是產品經理不佔理，那為什麼一定要撕逼來解決？

在這種情況下，讓工程師覺得，我們是竭盡全力在幫助他們更好地工作，而不是隨便想了個點子、不負責任地提給了他們。對工程師，他們未必能知道我們也在冥思苦想、費勁心思地做功能設計，在他們看來，只要有幾個漏洞和問題，就會想像出一副產品經理花天酒地不關心開發民生疾苦的畫面。

一旦有了問題，要表現出「我們馬上改」和「下次不會犯」的態度，這才能讓工程師更信任。硬說「人都會犯錯啊，你不是也會出 bug 嘛！還不高興我們也出點問題嘛！」既不能挽回顏面，也不能挽回工程師的認可。

3. 了解技術背景

良好的溝通都是雙向的。既然我們希望工程師能了解產品和業務背景，那麼我們也應該了解技術背景。這也是「產品經理要不要懂技術」的解答。

對我們來說，未必要會寫代碼，但要知道他們所說的「做不了」和「很難做」是什麼意思。他們沒有耐心講，我們也要有耐心學。這些知識掌握之後，能更有利於我們做出讓他們更滿意的方案，促進更好的溝通。

知彼知己，是最好的溝通方法。如果信息不對稱，撕逼再多也沒用；如果信息對稱了，那為何還要撕逼？

4. 特殊的情況

還存在著一種特殊情況，就是某些工程師確實性格或者職業操守比較一般，會以各種借口做擋箭牌，習慣性跟產品經理撕逼，故意推延實現需求甚至刻意刪減需求。這種是我認為的唯一能接受撕和吵架的場景。不過針對這種情況，最好的解決方案是反饋給他的上級，讓上級來判斷孰對孰錯，同樣不要指望撕逼能帶來質的提升。

總結下來，就是對產品經理而言，盡量避免撕逼才是溝通的技巧，而掌握如何撕逼併沒有卵用。

---

你一個產品 不好好研究需求 你研究撕逼？？

產品最重要的是說清楚你為什麼要提這個需求，如果你說清楚了 你以為程序員閑的慌非得跟你撕逼？？

意見統一是你跟他說我為什麼要做，以及這個需求的重要性。如果程序員能力不足或者這個需求確實很難，這個時候你需要適當的讓步，在保證核心功能實現的前提下弱化對於技術的需求

知道為什麼那麼多程序員討厭產品么，程序一說難，你們就一句 這也不難啊 挺簡單的

呵呵 不難你為什麼不做技術？不難你做呀，你行你上！

---

首先說一點，認為產品經理是傻逼的程序員，和認為程序員是傻逼的產品經理，都不合格。工作就工作，撕什麼逼?

在知乎這個程序員扎堆的地方，貌似挺程序員就是政治正確，我只能說你們把知乎當成垃圾桶了？有啥不滿就不講事實的隨便亂噴?

還有人說，不懂技術的產品經理都是垃圾?我只能說你太年輕，產品經理，pm這個概念出現的可比程序員早多了。當然近年來才外延擴展變成科技公司的一個特殊職位。原來一個大企業的產品經理大都是mba出身，負責管理一個品牌的，也叫brand manager。

所謂管理這個產品，就是負責把控這個產品會變成什麼樣，要達到什麼效果。一個產品經理最需要掌握的技能就是排優先順序。什麼是必要的，什麼是nice to have。

而程序員的職責是把東西在時間允許的範圍內做出來。

所以這雙方沒有根本的利益衝突。

會撕逼的原因，無非兩個

1. 產品經理不合格，產品vision不清，優先順序選擇不對

2. 程序員太懶，技術不行

沒有誰是有原罪的，戾氣不要這麼重

---

能不能有點專業素養，學會「溝通」和「調解」，而不是 「撕逼」。還「優雅」地「撕逼」，「撕逼」 本身就是個很不優雅的詞。連話都無法說優雅，又談何「優雅」地溝通。

還有，請不要簡單地把「溝通」說成「撕逼」。你以為「撕逼」這個詞好接地氣，好單純好不做作？「撕逼」是個非常負能量的詞，而詞語會影響我們的認知。

」撕逼「這個詞的語境是雙方成敵對狀態。當你想著如何"撕逼」 的時候，你是把開發放在敵對方而不是合作方。你會把關注度放在如何贏上而不是一起找到對產品最好的解決方案。

如果你腦袋裡滿是」撕逼「這個詞，慢慢地，你的思維就會變得二元化，你跟開發的交流不是發號施令，就是爭論。
----------------
如果題目完全是關於如何讓別人聽你話，如何讓別人為你做事，那麼這跟「產品經理」 和 「前端工程師」又有什麼直接關係？去「心理學」 或 「溝通」 那些話題下面能找到更有深度的答案。

---

達成核心目的，適當讓步，相互理解！

---

應該也有像我這樣，做前端出生，技術、架構比前端好的產品經理吧。

---

請問一下，為什麼產品會和開發的撕逼，我們公司開發的歸產品管的。。。。

---

---

---

抽空學習一些前端的知識，多了解技術，
當前端說無法實現的時候，
你就可以說，
這個不是用CSS裡面的吧啦吧啦就能實現嗎？

其實我想表達，
當你熟悉技術以後，
撕逼的頻率就會下降很多很多。
因為熟悉技術以後，
就知道到一個怎麼的需求才是最合理的，
既能滿足用戶，
又能便於開發維護，
而不是先提出需求，
你先去做，做完再說。

---

說明白做這個需求對前端的好處而不是對產品經理的好處就行了

渴望成就感就從客戶價值說
希望升職就從合作關係說，最起碼多在人老大面前表揚人
如果就是不認同觀點就拿數據說，自己也不肯定的事情就別盛氣凌人，大不了做AB

---

要與程序PK，我以為最重要的是能用程序語言與之溝通
了解程序語言，並不是說要會寫代碼，只是為了能聽懂程序們在說什麼。
據本人不完全觀察，對於一些新人，程序經常會以類似「這沒法討論了，根本不在同一個頻道上」這樣的話宣告一次PK的結束。
這種雞同鴨講的情況，雙方的內心都是一樣的崩潰。

如果把程序語言比作漢語這種一般意義上的語言。我們只需要擁有舊社會文盲的水平就足夠，而程序員就好比是那些能寫文章的讀書人。
厲害點的程序員屬於新概念作文大賽得獎的水平，Torvalds(寫Linux的)、Wozniak(寫Apple的)這種神級程序員就好比諾貝爾獎得住。
我們作為文盲，雖然寫不了文章、看不懂文章，但是正常交流沒有問題，即使對方偶爾會說些我們聽不懂的成語、典故，但只要不是滿口晦澀的文言文，並不會對溝通造成太大的障礙。

那麼問題來了，如何學慣用於溝通的程序語言？個人覺得自己搗騰下個人網站是全面了解程序語言的有效方式。我靠著高中里搞論壇的那一年多經驗，吃老本吃到現在。鑒於我時至今日仍是只會改不會寫的初級水平，對程序的理解肯定不夠深刻，不敢妄談如何學習，就簡單說一下各種程序語言對我的一些實際幫助吧。

• HTMLCSS
  了解各種頁面元素都有哪些屬性可以設置，各元素之間的相對位置關係、對齊方式
  關於這些，其實更多是屬於程序和美術之間的交流鴻溝。相對坐標還是絕對坐標？相對於屏幕對齊還是相對於其他元素對齊？當美術不了解程序語言的時候，只有我們這種既不會美術又不會程序的中間崗位來翻譯了。
  

  擴展閱讀 HTMLCSS系列教程

• JavaScript
  了解各種操作事件的具體差異
  就以最簡單的「點擊一下滑鼠」，對程序而言，可能需要確定具體是click、down還是up事件，會不會有額外的hold事件。
  

  擴展閱讀 HTML DOM Event 對象

• SQL
  了解了基本的數據結構，以及讀寫、查詢等數據處理方式。
  寫系統規則時先自己建立好表結構，即使不是最優解，程序也更能理解，討論時也不至於空談。
  一個界面里的列表用select寫一遍，排序規則對程序而言就一目了然，用人話來寫反而太啰嗦
  

  擴展閱讀 SQL 教程

當然，還有很多其他的一些基本的概念，比如遍歷、析構之類等等，都在後來工作中慢慢積累的「新單詞」。
對於懂程序的人來說，這些都是非常非常淺顯的入門級別。不過日常工作中的討論溝通，也大多為這些雞毛蒜皮的小事，驚天動地的大型架構一款產品能有幾次？
了解一些程序語言，避免與程序溝通時一臉茫然、二臉懵逼的窘境。

PK之前，自己的分內工作一定要先做到位
如果你的文檔、示意圖都非常馬虎，別人問起來都是「沒想過、隨便放的」，那無論與誰PK都是毫無勝算。
只有雙方實力接近時才有PK技巧可言。

假設對手是巴西男足，並不是一定要義大利、德國這種強隊才能出戰。
只要能達到中國男足的水平就有資格同場競技，說不定可以進一球、得一分。
但倘若派出的是益民食品廠代表隊，那真的只有依賴膜法才能獲勝了。

回顧一下我戰敗的那些情況。通常原因只有一個：邏輯不夠嚴密，考慮不夠周祥。
我與我們那個變態主程的戰績，勝率最多只有50%。

由於主程負責的通常都是大系統，幾乎每次都會被他的一連串「極端邊緣情況如何處理」的連擊給打到。
面對這種失敗，除了繼續提高自己的姿勢水平，只能微微一笑、無可奈何。

最後

一次又一次撕嗶之戰，目的是什麼？不是為了爭輸贏，最重要的是為了推動項目。
切莫本末倒置，為了贏而贏。

專欄鏈接：如何在與撕嗶之戰中戰勝程序、美術及老闆。 - PlayUX - 知乎專欄

---

果然又看到有人說懂點技術就好撕了，真是呵呵。
除非把產品的整個技術架構弄懂，然後了解新需求應該怎麼樣在這個局限的架構上添加。技術最怕的就是在原有的架構上添加不合適的需求。所謂牽一髮而動全身，其中酸爽，只有一線程序員才能懂，只知道用啥技術卻不知細節的產品能了解體會？。
當然你也可以說架構不好，但世界上哪有一種架構可以通用所有需求的？特別是改來改去的需求。。。
所以我都是自己提需求，然後自己做出來的。蜜汁笑臉。

---

我是有理有據的好好說話 弄出一大堆策劃聽不懂的專業名詞 比如介面 參數 埠 函數什麼的 然後他們就老實多了

---

本人是技術出身的產品經理和項目經理，
如果你是想著跟技術撕逼的話，那還是別做產品了。
什麼叫高效的撕逼？
作為產品經理，你需要向技術說明的是你需要實現的需求對項目和公司的重要性，現在不懂技術的產品經理很多，那麼不懂技術的產品經理還需要多做一個工作，該需求技術實現的可行性，這個事情是和技術總監商量，基本上產品經理出一個需求跟技術實施人員沒有半毛錢關係。
產品經理能跟技術產生矛盾的也就是需求不明確，不善表達自己的需求，和想法太多喜歡改來改去。
做好需求分析，知道項目需要什麼，不要想些有的沒的，不要看別人什麼好就想抄，安心分析產品市場和怎麼去完善用戶體驗，沒人吃飽了沒事喜歡撕逼。
如果你是受到阿里月餅門的啟發，這個就是需求分析不到位的鍋。

---

陷入撕逼的心理，那麼項目離死也就不遠了。

大家坐在一起，不是為了爭個高低，撕個你死我活的。都是為了生存。
項目失敗，顯然對大家都沒有好處。
既然如此，可以從根源上談一談。從共同的認知談一談。

對夢想認可的，ok，從夢想開始
對項目認可的，ok，從項目開始
對職責認可的，ok，從職責開始

如果沒有一點共識，那麼，可以考慮直接離開了。因為我相信，每天活在撕逼中的工作，一定不快樂。
不快樂，又掙不到錢，還留在這幹嘛呢？

另外，做產品，要勇於接受程序的質疑。
而且，是好事情。

程序質疑，至少說明他在認真思考這個需求，是否合理，是否可行。那麼，他實現的程序，可能會超乎想像的達到要求。比如，性能需求，優化類需求什麼的。
同時，也是產品一次提升自己的機會。程序質疑的點，可能就是產品工作做得不足。發現不足，改正，不就是提高自己的機會么。
更爽的是，程序質疑後，你有理有利有節的將需求始末，形態方案講的頭頭是道，贏的程序的信任，這種成就感難道不應該追求么

工作就是工作，可以激烈的討論。但撕逼就沒必要了

---

其實有時候覺得，問產品怎麼撕逼，其實跟問怎麼談戀愛很像。

產品就是你的兒子，你兒子生病了，當媽的讓當爸的下樓買個葯。

道理再簡單不過。

如果你的團隊讓你感到不適，一種可能是你的業務能力不行，要麼就是大家不夠職業，對待工作不夠認真，最差的就是衝突者不講理。

這些情況，也知道怎麼做吧。

---

產品經理的溝通的主要對象是項目經理 而不是程序員

---

我從來不撕逼，都是在研究實現方式

---

推薦閱讀：