來源：崔康@infoQ
對於產品經理來說，贏得開發人員的尊重和支援，從某種意義上講，是產品邁向成功的堅實一步。最近，知乎社群上的開發人員和管理者在前、後兩個帖子中對此展開了激烈的討論，其中不乏真知灼見。
林志霖Cray認為產品經理的決策和行為都應該為專案的目標服務，不要熱衷於鬥爭，團隊管理值得注意的幾點包括：
1、瞭解美術/前端/後端工作原理
如果你知道美術設計主選單懸停二級的不規則投影會浪費前端大把的時間除錯，你還能想像前端看到了多難過，你就及時建議改用規則統一透明度的投影。如果你知道後端用for迴圈輸出20條左右結構的新聞列表，你就應該讓前端用CSS控制自動左右佈局，而不是左右拆成兩份。
2、給團隊成員足夠的資訊和空間
這三個職業都不是工具，尤其後端工程師。再初級的程式設計師也會嚮往人月神話，他們能為你提供合理的高效的架構設計。你要給予他們足夠多的資訊，給他們留出恰當的時間，讓他們完成合理的架構。前後端工程師大多對複用和高效能報有成就感，你儘可能提供多的資訊，由他們來處理。這也是為他們後期維護和迭代提供便利，你不要有所保留！如果你真的思維不縝密，藏不住的，最後連朋友都交不成。
3、勇於溝通和學習
工程師跟你說以後用velocity來編輯頁面，你不理解，那麼就問。如果他鄙視你，那麼是他的問題，也可能是你的問題。大多數工程師願意給你講解的，他們也害怕表達，這是雙方的修為。如果工程師說必須從MySQL換成Oracle了，你問為什麼，他說無法承載了，你問要多久，他說要兩週，你崩潰了但是問為什麼，他說要寫資料轉換指令碼，你問為什麼，他說兩個資料庫之間資料型別不同需要有一些轉換，索引規則也不同，你問什麼是索引……這都是可以的，你要帶著學習的心態而不是問責，否則他越答越反感。最後你若懂了，他會覺得你理解他。
4、小心處理需求變更
這是個永恆的話題。你可以坦誠表達：需求變更是難免的，是不斷探索和調整而來的，作為PM我自認無法一次性想到最好，很抱歉。接著就是技巧活了，原則是儘可能避免反覆修改。如果有一個頁面的資料呈現，你無法想象怎樣更好，你可以用Chrome開發者工具先去調整檢視，別直接讓技術修改並當作你的參考。如果你不會用工具可以去學，實在複雜你就懇請技術輸出兩份效果給你比對，而不是改了說不好再改回去。
第二點就是，如果有的資料呈現模組要裁剪，但有可能日後換個形式換個地方呈現，你就要跟技術說明白，讓他只是註釋暫時隱藏。你不知道一個簡單的資料呈現它用了快取還是別的什麼。
5、成就感是你能給予的共鳴
你要知道各位同學都在意什麼，物質需求可能你無法給予，吃個飯之類的其實是順理成章，不必刻意。各位同學踏入網際網路江湖，大多想在各門各派混出個名堂。如果你有機會，不要吝嗇這樣的稱讚。程式碼註釋，產品主創介紹，向上彙報各同學的技術成果，鼓勵同學往各渠道分享技術心得。同時適當認同各位在架構效能上的新想法新思路，包括互動體驗上也應該給前端人員發揮空間如果他們願意。其實最根本的，你要熱愛產品並竭盡所能，產品的受眾範圍和影響力是個天然的成就感。
6、勇於擔當
你多承擔一些考核壓力和物質壓力，同學們才能更有精力投入到工作中。同為打工的你，能做的不過如此了。特別是當專案失敗時，怎麼可能跟你沒關係，該推的不該推的都不該推，早幹嘛去了？若出現專案成員能力問題和態度問題，儘早反映，說按此下去結果最好只能如何，把問題丟給你的頭。（參閱《如何在Google成為一名優秀的產品經理？》一文中的“1. 對產品以及所有相關的問題負責。”）
流浪貓則舉了一些親身經歷的反面教材：
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、謙虛和威信並存，不懂就問，虛心接受技術提出的產品意見，但原則問題不妥協。
大家對此有什麼建議，歡迎發表自己的看法。