產品經理如何贏得開發人員的尊重和支持？-摘自infoq

對於產品經理來講，贏得開發人員的尊重和支持，從某種意義上講，是產品邁向成功的堅實一步。最近，知乎社區上的開發人員和管理者在前、後兩個帖子中對此展開了激烈的討論，其中不乏真知灼見。

林志霖Cray認爲產品經理的決策和行爲都應該爲項目的目標服務，不要熱衷於鬥爭，團隊管理值得注意的幾點包括：

1. 瞭解美術/前端/後端工做原理。     若是你知道美術設計主菜單懸停二級的不規則投影會浪費前端大把的時間調試，你還能想像前端看到了多難過，你就及時建議改用規則統一透明度的投影。若是你知道後端用for循環輸出20條左右結構的新聞列表，你就應該讓前端用CSS控制自動左右佈局，而不是左右拆成兩份。
2. 給團隊成員足夠的信息和空間。     這三個職業都不是工具，尤爲後端工程師。再初級的程序員也會嚮往人月神話，他們能爲你提供合理的高效的架構設計。你要給予他們足夠多的信息，給他們留出恰當的時間，讓他們完成合理的架構。先後端工程師大多對複用和高性能報有成就感，你儘量提供多的信息，由他們來處理。這也是爲他們後期維護和迭代提供便利，你不要有所保留！若是你真的思惟不縝密，藏不住的，最後連朋友都交不成。
3. 敢於溝通和學習。     工程師跟你說之後用velocity來編輯頁面，你不理解，那麼就問。若是他鄙視你，那麼是他的問題，也多是你的問題。大多數工程師願意給你講解的，他們也懼怕表達，這是雙方的修爲。若是工程師說必須從MySQL換成Oracle了，你問爲何，他說沒法承載了，你問要多久，他說要兩週，你崩潰了可是問爲何，他說要寫數據轉換腳本，你問爲何，他說兩個數據庫之間數據類型不一樣須要有一些轉換，索引規則也不一樣，你問什麼是索引……這都是能夠的，你要帶着學習的心態而不是問責，不然他越答越反感。最後你若懂了，他會以爲你理解他。
4. 當心處理需求變動。     這是個永恆的話題。你能夠坦誠表達：需求變動是不免的，是不斷探索和調整而來的，做爲PM我自認沒法一次性想到最好，很抱歉。接着就是技巧活了，原則是儘量避免反覆修改。若是有一個頁面的數據呈現，你沒法想象怎樣更好，你能夠用Chrome開發者工具先去調整查看，別直接讓技術修改並看成你的參考。若是你不會用工具能夠去學，實在複雜你就懇請技術輸出兩份效果給你比對，而不是改了說很差再改回去。     第二點就是，若是有的數據呈現模塊要裁剪，但有可能往後換個形式換個地方呈現，你就要跟技術說明白，讓他只是註釋暫時隱藏。你不知道一個簡單的數據呈現它用了緩存仍是別的什麼。
5. 成就感是你能給予的共鳴。     你要知道各位同窗都在乎什麼，物質需求可能你沒法給予，吃個飯之類的實際上是瓜熟蒂落，沒必要刻意。各位同窗踏入互聯網江湖，大多想在各門各派混出個名堂。若是你有機會，不要吝嗇這樣的稱讚。代碼註釋，產品主創介紹，向上彙報各同窗的技術成果，鼓勵同窗往各渠道分享技術心得。同時適當認同各位在架構性能上的新想法新思路，包括交互體驗上也應該給前端人員發揮空間若是他們願意。其實最根本的，你要熱愛產品並竭盡所能，產品的受衆範圍和影響力是個自然的成就感。
6. 敢於擔當。     你多承擔一些考覈壓力和物質壓力，同窗們才能更有精力投入到工做中。同爲打工的你，能作的不過如此了。特別是當項目失敗時，怎麼可能跟你不要緊，該推的不應推的都不應推，早幹嗎去了？若出現項目成員能力問題和態度問題，儘早反映，說按此下去結果最好只能如何，把問題丟給你的頭。

流浪貓則舉了一些親身經歷的反面教材：

1. 彈性上班，拍板的事情常常找不到人。     前任上司本身首先實行彈性上班制度，下午纔來，技術經理常常都找不到他，咱們也不敢去拍板。就算問題是解決了，技術也會以爲你一點都不緊張項目（產品）。連本身的孩子都不緊張，誰替你去緊張。
2. 前端作到想吐也要作。     跟前任上司討論關於項目的問題（個人意見是初版不用作得太精美，之後能夠迭代上線，他的意見是初版就要作到很出衆，以便往後更好地請求資源）。上司跟我談到他之前的經歷：他說在之前公司作，他們策劃出的效果有N種狀況，因爲策劃出來的時間點比較靠後，致使前端切圖切到想吐，最後仍是如期上線，勸我不要太過於考慮實現方面的問題。當時我就想，就爲了那些效果而把別的同事搞到想死的感受，值得麼？效益與成本對好比何？你咋知道那些效果就是好的？或者是壞的呢？反正到最後，那期的項目仍是有各類效果，同時也讓設計加了三週的班，技術到最後上線的時候，連續作到次日早上（次日是公司年會）。
3. 技術加班，產品跑去吃飯。     在上線deadline，前任上司跑去跟人吃飯了（交代下背景，在策劃期間，他常常都出去吃飯看電影，我跟另一位策劃都只是出去過幾回，週六日都在作），而技術兄弟姐妹都在修復bug。我跟另一位策劃不斷在檢查，有問題立刻反饋修復。某經理晚上十點回來，我立馬就訓斥他一頓：人家技術都在爲咱們的項目而加班，晚餐是吃餅乾、喝汽水，你還出去吃飯？太說不過去吧？被我訓斥了一頓，某經理就立刻搞了個麥當勞外賣，還算是將功補過。後來我再提出，要讓某經理本身出錢給技術搭的士。
4. 項目失敗了，沒有後續的反饋。     個人我的意見，就算項目失敗了，做爲項目或產品的發起人，都須要跟你們講清楚狀況（特殊狀況除外），在最後總結一下。而後在請你們吃飯啊什麼都好，畢竟你們都是爲了項目認真努力付出過的，就算失敗，也要慰勞一下。

吳偉以其7年的PM經驗來看，說服他人，特別是研發、設計、前端這些研發部門的同事，最重要的不是口才、溝通能力和數據，而是專業。專業就是：第一，你要用內行的思惟方式、表達方式和處理方式來思考、溝通和執行；第二，你要常常能夠作出正確的決定。  他介紹了幾個小技巧：

1. 儘可能說術語。     在咱們與研發人員溝通的時候，儘可能不要說大白話，而是使用術語。這樣會讓人家感受咱們很懂技術。例若有一次我和一個客戶端工程師說：「我但願彈出的窗口是模態的。」工程師聽完後很詫異的說：「你還知道模態？」我說：「固然啦，這對交互設計很重要啊。」因而工程師馬上就把窗口改爲模態的了，根本沒問我爲何。那麼什麼叫模態呢？用大白話說就是彈出一個窗口，窗口之外的地方都是黑的，或者不能夠操做，只有這個窗口能夠操做，相似於Windows裏面常常彈出來的討厭的錯誤提示。可是你要是跟工程師這麼描述，碰上脾氣好的說不許幫你改改，碰上很差的準保反問一句：那多討厭啊，我就討厭Windows彈錯誤提示。
2. 思惟要周密，在說話以前要儘可能把全部可能的狀況及其解決方案想清楚。     好比你要修改一個按鈕的位置，人家天然要問你，空出來的位置怎麼辦，改過去以後會不會影響現有的功能，用戶能不能習慣等等，若是你能成竹在胸的一一化解，別人天然會遵從你的建議。
3. 讓對方本身得出結論。     人都是有自尊心的，都但願本身的決定是正確決定，若是你老是說：「你這樣是錯的，我是對的」必然引發別人的反感。因此你能夠先把遇到的問題擺出來，在提出本身的解決方案後馬上說：這方面你是專家，若是你以爲這個方案能用就用，若是有更好的方案我也沒什麼意見。人嘛，一般都是比較懶的，既然你能提出一個還算說得過去的解決方案，並且又讓對方以爲是他本身的選擇，一般也就不會爲難你了。
4. 看人下菜碟。     不是對每一個都用一樣的話說服的，人和人都有所不一樣。以個人經驗，對待工程師、設計師、老闆是不一樣的。對待工程師要有條理，邏輯要清晰，講究數據。例如：方案1會形成數據服務器負荷太重，併發量在2萬/秒以上，而且至少要佔用10g的儲存空間，最重要的是，咱們付出了這麼大的代價，其實只知足了20%的用戶，並且這部分用基本上都是不付費的用戶。這一大套話說完，研發人員會認真想想：也是啊，萬一服務器宕機了責任就大了，仍是用方案2吧。對待設計師要以情動人，由於設計師通常都是學美術出身的，特別感性。例如：大姐，你就給我改改吧，爲了畫這個原型我昨天都加了一宿班了，你今天不改，明天指不定又插進來什麼活兒呢，我這個項目得何時上線啊。再說也不是我想改啊，是銷售那邊兒一下子說用戶喜歡這個，一下子說用戶喜歡那個，咱們也擰不過他們啊。設計師一聽，都是同事，誰還沒個難處啊，得了，加班兒給人作了吧。對待老闆要學會畫藍圖，例如：根據競品研究的結果看，這個產品很是有前景，XX剛上線1個月，就已經有100萬用戶，10萬同時在線，收入也差很少有400來萬。咱們在技術上、渠道上、政府關係上都比他們強，我以爲只要可以在2個月內推出，各項數據確定比他們強。更況且，咱們的產品線目前缺少的就是用戶沉澱，而這個產品正好提供了強大的社交功能，彌補了產品線的空缺。老闆一聽，小夥子想的挺清楚啊，成，給你兩個工程師，一個設計師，1萬塊項目獎金，1個月給我作出來。業績好的話再給你發年終獎。
5. 人格魅力。     作人要有幽默感，要學會緩和睦氛。不必每次需求討論的時候都板着臉訓人。說說笑話，插科打諢，給設計師倒杯水，給工程錘錘肩，送給運營的小姑娘幾塊兒巧克力，給運維的同事買幾瓶水。你平時這麼注重積累，在你須要的時候別人天然不會爲難你。能作的就作了，不能作的睜一眼閉一眼也就作了。

Hexybaby的經驗總結包括：

1. 儘可能在需求肯定後再提交開發，需求變動要給出充分的理由。
2. 隨時準備着，並儘可能用最短的時間爲技術解決任何非技術問題。例如部門間協調、文檔和素材的準備。
3. 言之有物，不要說空洞的片兒湯話，一針見血、思路清晰的描述需求。
4. 謙虛和威信並存，不懂就問，虛心接受技術提出的產品意見，但原則問題不妥協。 

你們對此有什麼建議，歡迎發表本身的見解。