程序員與產品經理干架的前因後果

本文轉載自51CTO（ID：weixin51cto）,作者：熊小妹

程序員和產品經理實在是一對冤家，有私交很好的程序員和產品經理，但是沒有在工作中不起爭執的程序員和產品經理。那麼程序員為什麼和產品經理「干架」呢？

為了深入了解「程序員與產品經理干架的前因後果」熊小妹在冬粉群里發起了話題討論，且看他們是因何干架的吧。。。

燭光晚餐引起的群毆事件

圖片來源於網路

臨時晚餐阻止產品汪的絮叨

產品：what are you 弄啥嘞？來需求了，我覺得這個功能不錯，把這個功能加上。

程序猿：....

產品：這個什麼時候能做好？要儘快

程序猿：....

產品：今天下班前能做好不？不行啊，那明天中午之前做好。

程序猿：....（苦逼加班加點中）....

產品：上次那個功能需要改一改，這樣...這樣...這樣會更好。

程序猿：.....xxxx.....

產品：那個功能好像反響不是多麼好，我重新做了個功能原型，把這個實現下，要儘快。

程序猿：....（一臉嫌棄中）....

產品：哎呀，為了更好的用戶體驗，我在那基礎上添加了些東西，這個不錯，肯定會吸引更多用戶，巴拉巴拉小魔仙中....

程序猿：....（-_-）....

產品：我想到一個不錯的功能，這個挺炫酷的，一定會吸引更過用戶。我給你講講這個功能，來把這個實現下，要儘快。

程序猿：....（默默忍受了不少唾沫星子>-_-<）....這個實現不了，從技術層面難度很大，這麼短時間不好實現...

產品：這不就是一個簡單的功能麽，這麼...這麼...不就行了...

程序猿：....（不懂不要瞎BB... -_-...依舊苦逼加班加點研究怎麼實現中）.....

產品：上次那個功能不是說很難麽，不是也搞出來了。效果還不錯啊。

程序猿：...（what is the fuxk，老子可是拼了命的在搞，沒日沒夜）..

產品：看到別的應用有一個不錯的功能，我畫了一個功能原型，需要實現下，這個可以不那麼急的。

程序猿：.......，呵呵呵，好的。要不，晚上吃飯一起？我請客，我們好久都沒聊聊了，（得需要給這傢伙加點buff）

產品：好啊，晚上走了我喊你。

.....

程序猿：世界一片清凈了，真好！

.....

據理力爭，武力抗衡

圖片來源於網路

領導參與，卻也輸於「性別差異」

圖片來源於網路

技術和產品開撕的根源

和平共處很難么

（冬粉昵稱：Shengwei）先看下面的一張圖片，我想大家都明白其中的意思。

01

產品需求經常變動

由於產品經理經常改動需求，導致程序員不得不把做好的東西重新再做，結果可想而知。有的時候程序員加班加點剛做完的東西，被產品經理一句話給推翻了，說需求變動了，不能這麼做。嚴重的時候連核心模塊都完全大變樣。就一直這樣改完做，做完改，無限循環下去。這個小編我可是深有體會。

02

產品經理對程序員的不理解

遇到一個懂技術的產品經理不容易。程序員經常聽到的一句話就是，"這麼簡單的功能為什麼要這麼長時間？"這樣的話令很多程序員惱火，是最能激發與產品經理矛盾的導火索。

03

看一下下面的圖片，是大多數公司標準的軟體開發流程。

從圖中我們可以看出，產品經理可以直接跟客戶討論需要，而程序員處於流程的最底端。我們都知道，如果流程越複雜越不容易傳達，對於需求的理解，最後傳遞到程序員這裡，有可能就變了味道。如果產品經理把握不好，可能最終結果跟客戶想要的完全不一樣。

有的產品經理技術上和項目管理上的不專業，對產品需求的理解不深刻，隨意改動需求，導致程序員的怨念值再一次上升。

換一句話說，程序員處於流程的底層，只是執行者，產品經理怎麼傳達就怎麼執行，完全沒有主動權，這也是導致需求改動的一個原因。比較聰明的公司的做法是，在產品需求會議上，允許程序員參加並發表意見，這樣可以從技術的角度及早發現產品功能中存在的問題，從而避免後期需求的頻繁改動。

在此也給產品經理們提點建議：

• 對需求要詳細理解，不能一知半解就把需求交給開發；

• 懂點技術，懂得怎樣與程序員溝通；

• 學會體諒程序員，尊重程序員的工作成果。

給程序員的建議：

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

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

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

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

大家互相理解。這樣才能相處融洽，為同一個目標共同奮鬥。

請添加小編微信：2518988391(備註崗位）