知乎上有人問「如何跟工程師優雅地撕逼?」,以下是我的回答。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. 塑造良好的溝通氛圍

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

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

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

3. 了解技術背景

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

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

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

4. 特殊的情況

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

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

#專欄作家#

劉飛,微信公眾號:劉言飛語,人人都是產品經理專欄作家。互聯網產品經理,先後在鎚子科技、嘟嘟美甲和點我吧任產品經理,知乎產品經理領域最佳回答者之一。豆瓣閱讀《最好的時代》作者。

本文原創發佈於人人都是產品經理,未經許可,不得轉載。