產品經理和程序員因手機殼顏色打架？

想必大家都聽說了，這兩天關于中國平安一個產品經理因奇葩需求和程序員爆發(fā)肢體沖突的事件在朋友圈被刷屏，更有現場打架視頻在技術群里瘋傳。

在這里先帶大家簡單文字回顧下事情經過，N次打架視頻和截圖就不給大家放出來了，相信大家都在技術群和朋友圈里親眼目睹過了，最重要的一點是為了社會和諧。

「 肢體沖突的起因 」

以下是網上流傳的本次打架事件的文字敘述：

「 事件的處理結果 」

事情的起因大概就是這樣，先不討論本次事件中pm提出的需求是否合理，程序員能否實現，本身這起辦公室沖突事件的發(fā)生，引起了圈內很大的熱議，“成功地”推上了互聯網熱點頭條，同時也給中國平安公司的名譽帶來了負面影響，最后涉事的兩位外包人員慘被雙雙開除。

很多看過現場視頻的網友是這樣分析的，禿頭的是程序猿，沒禿頭的是產品，假裝勸架的是運營和設計，看戲的是測試，拍這個視頻的應該是商務，pm下次記得戴安全帽提需求。

分析地頭頭是道，活脫脫一個國內社會看熱鬧不嫌事兒大的縮影，也是厲害。

「 如何向外行解釋內情 」

可能一些非軟件行業(yè)內的吃瓜群眾，想不通為什么程序員和產品經理要干架？我完全可以通過一張表情圖合集，來生動形象地告訴你，一家軟件公司的項目是如何上線的。

「 打架是不對的 」

看完這張圖，我們再來說說pm和coder打架的事兒

年輕人血氣方剛，一言不合就互懟，借用孫紅雷在電視劇《征服》里的一句臺詞：不氣盛，還叫年輕人嗎？

但是，以暴制暴是不對的，朋友，畢竟就算打贏了也是真的疼啊。

在亂提需求的前提下，至少得練得跟我一樣吧。

不然，還真不一定打得過我，說一下我三大項的數據吧：

· 臥推：90kg

· 深蹲：140kg

· 硬拉：160kg

「 沖突的根源是什么 」

先來說說很多公司的現狀：產品經理和“老板們”關起門來開了個會，趕出原型和UI圖，之后交給程序員們的就是“圣旨”，“反正我們就這么定了，你照著開發(fā)吧。

程序員說：目標是需求，技術只是手段。

產品經理說：目標是用戶，需求是方式。

立場不同，定位不同，矛盾就來了。

產品經理永遠是用戶需求的代名詞，自以為是研發(fā)人員的上帝，動不動就要改需求，他們覺得好像很簡單的事情，殊不知給程序員添了多大的麻煩。

技術和產品撕逼，無非就是以下幾個原因：

1，產品沒有想明白，然后來來回回的改；

2，開發(fā)沒有理解清楚需求，開發(fā)東西和產品的要求有出入

3，產品的需求有問題

4，技術的時間不夠用

所以說，一個不懂項目管理的程序員不是好程序員，一個不懂軟件開發(fā)的產品經理，不是一個好的產品經理。

程序員和產品經理似乎天生就有不可調和的矛盾，和平共處很難么？

「 說點掏心窩兒的話 」

就這次事件，土叔我不站隊，也不說誰對誰錯，抱著一顆同理心，我分別來站在程序員、產品經理，以及項目管理層的角度，給coder、pm，以及manager分享幾點我的小想法。

「 給程序員的建議 」

程序員和產品經理干架其實需要理性，查查他的經歷，要分析下他懂不懂技術，懂的話有多懂。

一般很懂技術的產品經理是不和程序員干架的。

懂一點，但是就拿出來說事的這種，一般和程序員關系不好。

一點都不懂的產品經理有的謙卑，有的不懂裝懂亂說一通。

對于懂一點，就拿出來說事的這種，就要想法設法在技術上反問他，讓他覺得自己其實真的知道的很少。

這時候再動之以情，說明自己做這個的難度。

對于不懂裝懂的產品經理，就倆字：你來。

還剩下一種是不講理的，對于這種不講理的就只有一句話，我他娘的意大利炮呢？

玩笑歸玩笑，土叔在這里分享幾點走心又走腎的建議：

做好需求更改的準備，提高代碼的擴展性和可維護性；

預留出修改bug和需求的時間；

對需求理解透徹再開始寫代碼；

代碼不要寫死，防止需求變動。

「 給產品經理的建議 」

好多pm搞不懂，為什么產品經理頻繁更改需求會令程序員小哥哥們煩惱不堪？我想，大多時候是因為你們pm平時在工作中的這些口頭禪吧：

1.「先做出來看看吧」

2.「我就要這種效果，怎么實現是你的問題」

3.「這應該很簡單吧，不就是XXX，然后XXX嗎」

4.「這個需求，先這樣這樣，再那樣那樣，用XX技術很快就搞定了」

5.「你就說能不能做吧」

6.「我有一個絕妙的idea，什么都準備好了，就差一個寫代碼的了」

7.「這個需求老大已經同意了，你照著做就是了」

產品經理頻繁的需求變更，和程序員有限的工時是存在矛盾的，除非讓程序員加班。特別是上次的變更剛剛改完，這時又提出再次修改，朝令夕改，一步一步很巧妙地惹惱了程序員。

程序員最討厭朝三暮四的產品經理了。

如何與單純的程序員共處，土叔的走心建議要不要聽一下：

不要隨時打擾，尤其在他們戴著耳機的時候；

傳達「要做什么（What）」，還有「為什么這么做（Why）」；

學習基礎開發(fā)知識（比如 HTML/CSS），方便彼此溝通；

不要讓他們成為最后知道的人，一起討論可以少走彎路；

盡可能用數據說話；

配合工具（哪怕是紙筆）來表達你的想法；

提供有用工具給他們參考（比如 AniCollection）；

做好設計規(guī)范（個人很喜歡 Mavel 的 Styleguilde）；

盡可能和他們坐在一起；

他們可能羞于/不善于表達，多給一些耐心；

不要不好意思發(fā)問，其實他們都很熱心解決問題；

不要問那些 Google 一下就能找到答案的問題，節(jié)約雙方時間；

縷清用戶流程，不要讓他們來處理你的工作內容；

想清楚產品可能出現的各種狀態(tài)（404、零數據、極端用例、轉場……）；

該你決策就由你來決策，不要分擔責任；

相信他們的技術水準（如果他們確實不會，他們會學）；

勇敢承認你的錯誤；

記得給他們展示用戶/客戶的反饋；

改需求不要超過 3 次，再改就先跪下；

就算月餅被搶了，也要友愛和睦相處。

「 給項目管理層的建議 」

其實，誰都有想不到的地方，和想不明白的東西。但是自己都沒有搞懂之前就覺得只有自己是對的，那就只能撕了。

在我們公司的團隊里，程序員和PM一起討論需求，勾畫原型，提出自己不同角度的不同理解，讓程序員更接觸“原始需求”，能參與到產品的生命線里會更好，畢竟每個人都有思考能力，不是機器，一張需求甩過來就照做的程序員不是好的程序員。

在產品需求會議上，允許程序員參加并發(fā)表意見，這樣可以從技術的角度及早發(fā)現產品功能中存在的問題，從而避免后期需求的頻繁改動。

這也是大多數比較有經驗的互聯網公司的常規(guī)做法。

「 結尾 」

身在江湖，誰都不易，只要換個角度思考，互相多點體諒，這種矛盾自然就可以化解。

文章最后，如果想徹底解決pm和coder的矛盾沖突，土叔有個不成熟的終極方案，朋友們不妨一聽：

產品/UI每天給程序員提任務，程序員每天給產品做任務。

如果同一個人可以分飾產品/UI和程序員兩角，那么他就會變成永動機。

這款永動機有個廣為人知的名字，叫做獨立開發(fā)者。

程序員學習交流請?zhí)砑幽秸n網官方客服微信：mukewang666回復暗號“前端面試”可進前端交流群回復暗號“Java”可進Java交流群回復暗號“專欄”可進程序員交流群