打造開發人員喜歡的產品經理

　　在實際工作當中，產品經理是經常需要和開發人員打交道的，而人際交往的前提是相互之間有一個良好的感觀，甚或是已經建立起來的友情，這樣溝通或交流起來會非常的順暢。產品經理和開發人員之間，屬於工作範疇的關係，一般來講還分屬於不同的部門，如果再加上所揹負的考核KPI是不一樣的話，兩者之間很難說能夠為了一個共同的目標而無間的配合。從正常情況來說，產品經理要從大局出發，所考慮的要更加全面，某個設計可能包含了後續運營以及資料收集的前瞻性東西在裡面，而開發人員更多考慮的是如何去實現，實現的難易程度以及程式碼量的多少，不同的角度做同一件事，比然會引發很多的討論，所以產品經理所要參加的會議一直都是很多的。如何能夠和開發人員保持良好且高效的溝通交流，一直是產品經理們所需要解決的問題。

　　按說，產品經理和開發人員之間也是可以建立起很深的友誼的，這個需要工作之外的溝通和多次愉快的合作之後才能慢慢建立起來。已經在一個環境下工作了較長時間的產品經理和剛入職進入一個新環境的產品經理，都得和產品線所對應的開發人員搞好關係，否則會影響到後面的工作開展。經常聽到一些同行抱怨在公司裡與團隊成員之間如何如何溝通不暢，導致對產品失去信心之類的，我想說的是，無論是和UED、設計、開發等整個團隊都溝通不暢還是隻和開發人員有溝通問題，產品經理都是要自我反思的，問題都出在你自己的身上，因為人際交往的宗旨就是在面對不同性格不同背景的人要採取迥異的方式來營造良好的人際交往環境。要想做一個讓開發人員喜歡的產品經理，排除一些個人魅力因素，還是有一些方法的。個人在這方面做的還比較好，兩家公司待下來都能與整個團隊打成一片，還與一些開發人員建立了深厚的友誼，下面就講講一些個人的經驗。

　　講道理式的溝通

　　溝通是人際交往過程當中的必要手段，良好的人際關係從溝通開始。單從溝通的角度來說，面對不同性格的開發人員時，是要採取不同的溝通方式的，這點上需要一些閱歷才能做到，因此剛從學校出來打拼的同行們可能有點吃虧，不過如果你在學校裡參與了足夠多的社交團體活動，相信也應該能從中學到一些方式。簡單點來說就是，學會換位思考，從他人的角度出發去溝通。對性格沉悶的開發人員，在溝通的時候邏輯儘量嚴謹，語言儘量帶些專業術語；對性格開朗的開發人員，還可以適當的有一些口頭禪啊，插科打諢之類的；對待年長的（相差三歲以上吧），一定要謙卑有禮貌，同輩之間可以隨意一點，但也不能肆無忌憚，對待開發新人，要一視同仁，不要帶任何的輕視。人與人之間的關係相處是最為複雜的，需要慢慢積累和學習，個人現在也不敢說自己能應對所有的情況，只能儘量去做到最好，總之，保持謙遜有禮貌總是沒錯的，任何人都喜歡和有禮貌的人打交道，低調行天下啊。

　　有了良好的溝通開端，就能開啟話茬開始溝通了，但要達到溝通的目的，只有這一點還不夠。人和人之間的相處最講究平等，因此在溝通的時候要特別注意不要拿老大的命令啊，KPI啊之類的去壓人，要講道理。你不僅要告訴開發人員他們應該做什麼，還告訴他們為什麼這樣做，這樣做的目的在哪裡，最好還能告訴他們這樣做的價值點。誰都希望自己所做的事情是有價值有意義的，而不是無用功，因此明確的目的和價值有很好的說服力。當溝通遇到分歧的時候，要努力的去說服他們，而不是簡單說領導要求或者上面就要這麼幹，這會引起開發人員的反感。雖然有些時候確實會做一些領導要求的說不出價值的功能，產品經理也要盡力讓這件事看起來是正確的，讓開發人員認識到現狀，認同你的無奈。在這點上，個人的做法是相互之間講道理，誰能說服對方就聽誰的，產品經理也會犯錯，有時開發人員說的反而是對的，畢竟從不同的角度思考問題會有不一樣的結構，且旁觀者清嘛。

　　專業的文件撰寫能力

　　一份好的PRD的要求是正確清楚的描述了產品的所有功能點，功能描述無二義性，功能點之間描述是一致的，各個功能對產品而言都是必要且完備的，所有功能的設計都是可驗證和可實現的，所闡述的是要做什麼而不是怎麼做。其他的都較好理解，好的文件讓人看起來非常的順暢，可以一目瞭然，而不必去逐字逐句的深究，這樣也會節省開發人員看文件的時間和精力。不過最後一點要稍微注意一下，怎麼做一般是要有開發人員來決定的，產品經理最多指定一下資料來源，組織邏輯，所要實現的展示效果即可，不需要告訴開發人員怎麼實現。只有在一種情況下可以，那就是你設計的東西你認為可以實現，而開發人員認為實現不了，在保證這個功能在業務上是非常有必要而且有價值的前提下，你可以通過舉例或者委婉的描述實現方法的方式來告訴開發人員，儘量不要讓開發人員覺得自身能力不足，總之要引導成為這是一件有挑戰的事情。文件撰寫能力在開發人員的角度看不是必要的，但卻是加分項，這個能力也是產品經理的必備能力，如果不夠強的話，還是好好修煉一下吧。

　　基礎的技術知識

　　首先強調這點也不是必備項，但是加分項。有些產品經理是有研發背景的，即在轉行做產品經理之前，有從事過開發工作的，這樣就非常的有優勢，如果之前的開發工作與現在產品所需的是一樣的話，就完美了，可以在設計的時候就進行一定程度的實現性和可行性考慮，評估所設計的功能是否可以在現有條件和資源下實現，也能在開發人員寫的系統設計說明書評審會上聽懂，可以大致瞭解是否符合要求。開發人員都是喜歡和同行交流的，就像我們自己喜歡和產品經理同行交流一下，因此做過開發的產品經理在和開發人員的溝通上有優勢，但需要注意的是，千萬不能裝大佬，不要以為自己做過開發了不起，就指手畫腳的參與系統設計，這樣反而會令人反感，要記住你的技術背景只能停留在產品設計階段和PRD溝通階段，不要過多的給出技術方面的意見或建議，況且你都轉行了，說不定你所知道的東西已經過時了。

　　沒有研發背景的產品經理就需要修煉了，其實也不需要去學習開發技術，但是要知道一些專業術語，比如要知道JS指令碼、Ajax、資料庫、儲存過程、BI等等名詞到底是什麼東西，否則你會發現你在和開發人員溝通的時候會一愣一愣的，因為他們說的你聽不懂。學習的時候要有針對性，比如公司產品都是採用JAVA開發的，那就去了解一下JAVA相關的基礎知識，資料都都是採用MYSQL的，那就去簡單瞭解一下這個資料庫相關的知識，我們的目標是能聽懂開發人員說的話，以免陷於被動。如果讓開發人員發現他說了半天，你都沒有聽明白，如果要他講第二遍或者一一解釋一下，估計首先要有點不耐煩，其次會有點嫌棄你了，呵呵。

　　聽得進去建議

　　前面也提到，有時候開發人員是會提一些意見或者建議的，雖然大家都很專業，經驗都很豐富，但大家都是很忙的，很多時候都無法考慮的那麼細那麼完美，總有紕漏的時候，而開發人員有時候會適時的給出一些關於細節的建議與修改，這個時候你要評估一下，看是否是有價值的，如果是改變需求的，是要認真評估一下的；如果不改變需求，你要評估一下哪種更好，兩種方案實現起來的難易程度，是否可以折中等等，這種時候要儘量站在開發人員的角度去考慮。能聽的進去建議的人也是受了歡迎的，就像曹操，下面的謀士都是對其忠心耿耿的，因為曹操善於採納建議。

　　最後，其實開發人員也是很可愛的，只不過外面很多人會給程式設計師們冠以各種帽子，那都是有失偏頗的，要注意的是，不是所有的開發人員都會有類似的行為，你要是先入為主了，往往會做出錯誤的判斷。前面講到有研發背景的產品經理，就是從開發人員轉行過來的，這證明開發人員當中是有很多與大家類似的人群的，況且還時不時有一兩個美女開發嘛。以上只是個人的一些工作經驗總結，前面兩點個人覺得在和團隊成員協作時都適用。