産品經理與程式員的沖突從何而來？（給産品經理們的建議，給程式員的建議。程式員處在資訊傳導到最末端，是以比較弱勢、資訊不準确）

今天我們來讨論一下在軟體開發過程中的一個很常見，也是令很多程式員頭疼的問題，那就是與産品經理直接的沖突到底是怎麼形成的。

先看下面的一張圖檔，我想大家都明白其中的意思。

一、産品需求經常變動

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

二、産品經理對程式員的不了解

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

三、程式員處在軟體開發流程的最底層

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

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

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

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

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

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

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

學會體諒程式員，尊重程式員的工作成果；

給程式員的建議：

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

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

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

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

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