程序員如何和產品經理優雅的幹架

早前，平安產險科技一名外包程序員和一名外包產品經理幹架的視頻幾乎在互聯網圈都傳遍了，由於產品提了一個需求：要求用戶App的主題顏色能根據手機殼自動調整。

首先說這個需求對於應用開發工程師來講，確實是有點奇葩，固然並不是不能實現。這塊涉及圖形圖像處理，用機器學習和人工智能來提取圖像顏色，這是基本圖像識別過程，對於採集圖像，能夠提示對着鏡子自拍一張，上傳圖片，經過大量的訓練數據，來識別手機體顏色。固然並不能保證百分百成功，由於圖像可能模糊或者，不明顯等其餘緣由，就算不斷用CNN(卷積神經網絡)卷積運算。仍是有可能不成功。這是對這個需求自己一些見解。下面進入今天的主題：程序員如何和產品經理優雅的幹架（這裏優雅的幹架，主要是有效的溝通）

每次產品來提需求時，是這樣的

每次產品來改需求時，是這樣的

我在初出茅廬的時候，老是被產品牽着鼻子走，一個需求，接到後就作。開發過程當中，發現各類坑，因而又和產品溝通，而後好不容易完成。提測後，一堆Bug，有些同時知足多種狀況，自己就是定義矛盾，最後本身填坑。後來雖然漲了記性，每次和產品討論需求時，想讓對方不這麼作，老是沒有很好的理由說服別人。這個問題我曾不僅一次向老大去請教，每次都受益不淺。我姑且總結以下，之後幹架撕逼定能派上用場：

一、弄清楚產品需求出發點是什麼？
產品不會平白無故提需求，就算是看到被的產品實現了某個功能，咱們要實現。出發點是什麼？如暴露會員權益，暴露廣告位。給公司創更多收益。定義上是否和之前衝突，後續計劃是怎樣？想別人之所想，而不是你所想。你得站在產品上思考問題，不斷反問，正向推演，反向推演。若是沒有把握，給定一個時間調研，在此以前，不答覆必定能作下這個需求。答應後，作不到，你就是背鍋俠。由於不少事情咱們都是沒有作過的。

二、需求文檔須要定義清晰

差一字差千里，尤爲多Case時，流程圖，產品須要畫的清楚，這種狀況怎麼處理，那種狀況怎麼處理。異常時又怎樣。要是不會，你教他。
你在反問對方時，對方也是在學習和成長。他就會想，這人厲害了，能想這麼個場景，有些他本身都沒想到。時間長了，他下次就會事先把各個場景想清楚，而後再和你討論。這樣產品的質量和健壯度也會更好。因此，不要以爲程序員不要作這些事，你這樣，不光能獲得別人的敬重，還能推動後續愉快的合做。幫助別人就是幫助本身，這是我最大的體會。而不是，這不關我事，我只搞個人開發就行。

三、留取證據
和你口頭溝通的需求，必定要發出正式郵件或者寫入需求文檔更改項，否則萬一他哪天忘記了，你就百口莫辯了。好比，某天產品忽然找到你，說以前某個定義有點問題。能不能改爲這樣？雖然你很容易改，仍是須要讓他發出郵件，讓你的領導知曉。你們都有可能犯錯，很正常，犯錯纔會深入成長，尤爲你被別人懟你的日子，你確定難忘，反思後，搞清緣由，之後你確定能走更長遠。

四、需求背景要明確
不少產品，其實本身也不知道產品要作成什麼樣，你們都是互相借鑑，互相學習其餘產品。這麼作爲了什麼？否則腦殼一熱，咱們屁顛屁顛開發後，其實用戶一點都不想用，須要看產品的重點戰略方向，商業價值最大化，仍是體驗最優化，既要體驗好，又要商業價值好，只有付費模式纔是出路。固然不管是知識付費，仍是其餘付費，已經愈來愈被你們所接受。

五、對事不對人，學會甩鍋，甩鍋也是要證據充分。
這樣體現你的專業度，溝經過後的東西，用郵件複述一遍。表示確認。最怕產品忽然來一句，這個需求不是這樣的，我沒提過這個需求。

六、學會收斂
路還長，碰上不講道理的產品，你問我怎麼辦，道理行不通，只有來拼刺刀了。不過相信通過此次以後，產品經理和程序員都會收斂些吧~