“這是產品經理要考慮的，我只管寫好代碼就好了”，我曾有過這種想法。產品經理就要把所有產品邏輯考慮清楚，然后交付PRD給開發(fā)人員進行研發(fā)，瀑布or迭代研發(fā)一個個里程碑。不過想法總是美好的，現(xiàn)實是大家總是刀劍相向。

[[213042]]

產品經理如何惹怒開發(fā)人員?

1. 業(yè)務不清晰，研發(fā)人員不懂業(yè)務語言，產品經理不能把業(yè)務講明白;
2. 產品深度太淺，經不起推敲，研發(fā)人員覺得是敷衍，不專業(yè);
3. 產品流程不順甚至復雜，用戶體驗糟糕;
4. 不聽開發(fā)人員建議，覺得他們沒有產品思維;
5. 狀態(tài)設計不全，還堅持己見;
6. 沒有完整的PRD，把想法告訴研發(fā)直接開始碼代碼，沒有評審;
7. 沒有數據指標，亂拍腦袋定東西;
8. 這么簡單的功能，怎么需要這么久;
9. 著急上線，不給開發(fā)人員留思考時間，實際上并沒有那么著急;
10. 把需求扔給開發(fā)人員就不管了，不追進度，不看效果;
11. 非功能性需求根本不考慮;
12. ……

開發(fā)人員如何惹怒產品經理?

1. 一味追求技術，不學習業(yè)務語言，不學習領域知識，聽不懂需求;
2. 評審PRD時不提出問題和風險，等項目快上線了才暴露出來;
3. 碼代碼前不好好讀PRD，出問題直接怪產品;
4. 以為技術是***的，不去拒絕一些不合理的需求，***做砸了;
5. 數據狀態(tài)和異常流程這事需要好好跟產品經理梳理，產品經理沒我們想的全這是一定的，不要怪他們;
6. 只為代碼負責，用戶體驗不是我們要考慮的;在涉及到網絡、設備等方面的用戶體驗，我們比產品經理更懂;
7. 遇到問題不找產品溝通，隨意定方案;
8. 代碼一團糟，不可維護，不可擴展，新需求遲遲做不了;
9. 老出問題，怪產品經理設計不合理，考慮不全;
10. 很明顯的產品體驗問題，不提出來，不解決;
11. ……

產品經理應花大部分時間在商業(yè)畫布、產品規(guī)劃、產品邏輯、產品運營、用戶體驗上。涉及到具體功能點應該大致給出研發(fā)方向，不然研發(fā)是沒有方向的，很可能導致不斷地返工。

業(yè)務開發(fā)人員、系統(tǒng)開發(fā)人員、SRE或運維人員，其實已經有產品思維了，比如我們梳理業(yè)務架構、系統(tǒng)架構、功能點、系統(tǒng)流程、異常流程、數據流程、數據狀態(tài)、系統(tǒng)配置等等，這些不都是產品的一部分嗎?只是這些跟技術綁定的比較緊密而已。

產品經理在產品細節(jié)、異常流程、數據狀態(tài)等方面很可能不如研發(fā)人員。這個時候需要大家一起坐下來溝通并梳理。我的觀點是：越透明，越高效。

我們首先應該是一名產品經理，然后才是一名開發(fā)人員。而且我們是一個團隊，應該一起考慮如何做好產品。不過我們應該把自己的專業(yè)度提高，否則產出的方案經不起推敲，老是產出殘次品，大家的信任危機接踵而來，誰也說服不了誰，決裂廝殺，最終產品失敗。

小馬哥說過：產品經理要把自己當做一個“最挑剔的用戶”。開發(fā)人員要用心思考產品，而不是公事公辦的態(tài)度。你要知道用戶、同行會關注你的產品，在這種驅動下開發(fā)人員要有責任心去主動完成。不能說等到產品做好了，流水線一樣送到面前再做。40%~50%產品的最終體驗應由開發(fā)人員決定的。

【本文是51CTO專欄作者張開濤的原創(chuàng)文章，作者微信公眾號：開濤的博客( kaitao-1234567)】

戳這里，看該作者更多好文