「深度剖析」程序員由於奇葩需求暴打pm，而後被雙雙開除

「 前言 」

想必你們都據說了，這兩天關於中國平安一個產品經理因奇葩需求和程序員爆發肢體衝突的事件在朋友圈被刷屏，更有現場打架視頻在技術羣裏瘋傳。

在這裏先帶你們簡單文字回顧下事情通過，N次打架視頻和截圖就不給你們放出來了，相信你們都在技術羣和朋友圈裏親眼目擊過了（固然，沒看過的朋友能夠找我微信私聊），最重要的一點是爲了社會和諧。

「 肢體衝突的原由 」

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

「 事件的處理結果 」

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

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

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

「 如何向外行解釋內情 」

可能一些非軟件行業內的吃瓜羣衆，想不通爲何程序員和產品經理要幹架？我徹底能夠經過一張表情圖合集，來生動形象地告訴你，一家軟件公司的項目是如何上線的。

「 打架是不對的 」

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

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

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

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

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

• 臥推：90kg
• 深蹲：140kg
• 硬拉：160kg

「 衝突的根源是什麼 」

先來講說不少公司的現狀：產品經理和「老闆們」關起門來開了個會，趕出原型和UI圖，以後交給程序員們的就是「聖旨」，「反正咱們就這麼定了，你照着開發吧。

程序員說：目標是需求，技術只是手段。
產品經理說：目標是用戶，需求是方式。
立場不一樣，定位不一樣，矛盾就來了。

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

技術和產品撕逼，無非就是如下幾個緣由：

1，產品沒有想明白，而後來來回回的改；
2，開發沒有理解清楚需求，開發東西和產品的要求有出入
3，產品的需求有問題
4，技術的時間不夠用

因此說，一個不懂項目管理的程序員不是好程序員，一個不懂軟件開發的產品經理，不是一個好的產品經理。

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

「 說點掏心窩兒的話 」

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

「 給程序員的建議 」

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

通常很懂技術的產品經理是不和程序員幹架的。
懂一點，可是就拿出來講事的這種，通常和程序員關係很差。
一點都不懂的產品經理有的謙卑，有的不懂裝懂亂說一通。

對於懂一點，就拿出來講事的這種，就要想法設法在技術上反問他，讓他以爲本身其實真的知道的不多。
這時候再動之以情，說明本身作這個的難度。

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

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

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

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

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

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

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

「 給產品經理的建議 」

好多pm搞不懂，爲何產品經理頻繁更改需求會令程序員小哥哥們煩惱不堪？我想，大多時候是由於大家pm平時在工做中的這些口頭禪吧：

1.「先作出來看看吧」
2.「我就要這種效果，怎麼實現是你的問題」
3.「這應該很簡單吧，不就是XXX，而後XXX嗎」
4.「這個需求，先這樣這樣，再那樣那樣，用XX技術很快就搞定了」
5.「你就說能不能作吧」
6.「我有一個絕妙的idea，什麼都準備好了，就差一個寫代碼的了」
7.「這個需求老大已經贊成了，你照着作就是了」

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

程序員最討厭朝秦暮楚的產品經理了。

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

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

傳達「要作什麼（What）」，還有「爲何這麼作（Why）」；

學習基礎開發知識（好比 HTML/CSS），方便彼此溝通；

不要讓他們成爲最後知道的人，一塊兒討論能夠少走彎路；

儘量用數聽說話；

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

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

作好設計規範（我的很喜歡 Mavel 的 Styleguilde）；

儘量和他們坐在一塊兒；

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

不要很差意思發問，其實他們都很熱心解決問題；

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

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

想清楚產品可能出現的各類狀態（40四、零數據、極端用例、轉場……）；

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

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

勇敢認可你的錯誤；

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

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

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

「 給項目管理層的建議 」

其實，誰都有想不到的地方，和想不明白的東西。可是本身都沒有搞懂以前就以爲只有本身是對的，那就只能撕了。

在咱們公司的團隊裏，程序員和PM一塊兒討論需求，勾畫原型，提出本身不一樣角度的不一樣理解，讓程序員更接觸「原始需求」，能參與到產品的生命線裏會更好，畢竟每一個人都有思考能力，不是機器，一張需求甩過來就照作的程序員不是好的程序員。

在產品需求會議上，容許程序員參加並發表意見，這樣能夠從技術的角度及早發現產品功能中存在的問題，從而避免後期需求的頻繁改動。

這也是大多數比較有經驗的互聯網公司的常規作法。

「 結尾 」

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

文章最後，若是想完全解決pm和coder的矛盾衝突，土叔有個不成熟的終極方案，朋友們不妨一聽：

產品/UI天天給程序員提任務，程序員天天給產品作任務。
若是同一我的能夠分飾產品/UI和程序員兩角，那麼他就會變成永動機。
這款永動機有個廣爲人知的名字，叫作獨立開發者。

---

更多文章我會第一時間更新在公衆號<閏土大叔>裏面，歡迎關注~