我

用

眼

看！！行麼？

產品經理提的要求確實沒法實現，說明這個產品經理沒有文化，在其次我覺得這個程式設計師可能有點衝動，但是我覺得正常，程式設計師工作本來就壓抑，你提需求不能實現，你還強制讓人家去弄，不打你就不正常了

「 肢體衝突的起因 」

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

「 事件的處理結果 」

很多看過現場影片的網友是這樣分析的，禿頭的是程式猿，沒禿頭的是產品，假裝勸架的是運營和設計，看戲的是測試，拍這個影片的應該是商務，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 一下就能找到答案的問題，節約雙方時間；

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

想清楚產品可能出現的各種狀態（404、零資料、極端用例、轉場……）；

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

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

勇敢承認你的錯誤；

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

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

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

「 給專案管理層的建議 」

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

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

這也是大多數比較有經驗的網際網路公司的常規做法。

「 結尾 」

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

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

產品/UI每天給程式設計師提任務，程式設計師每天給產品做任務。

如果同一個人可以分飾產品/UI和程式設計師兩角，那麼他就會變成永動機。

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

如果是我，我就去技術總監那告PM一狀，或者經理那也告一狀（這個不用懂技術也知道無法實現）。先把難題提出來，總之就是先將這PM一軍（誰讓他不懂還裝逼）。等公司處理了這件事後，再提出替代方案。其實吧也是可以實現的。這個就是實現方案問題，應該不屬於程式設計師考慮的問題，但我考慮到了。就是APP開啟的時候強制使用者選擇手機殼顏色不就解決了。