PM 如何使自己的觀點有說服力，讓技術人員覺得你說得有道理，願意按你說的做？
以我7年來做pm的經驗來看，說服他人，特別是研發、設計、前端這些研發部門的同事，最重要的不是口才、溝通能力和數據，而是專業。專業就是：第一，你要用內行的思維方式、表達方式和處理方式來思考、溝通和執行；第二，你要經常可以做出正確的決定。
一個人要先相信你能說出正確的話，才有可能認真去聽你說的內容，進而才有可能認可你的話。通常人們認為只有內行才有可能說出正確的話來，而外行只能瞎指揮。所以pm要時時刻刻表現的很內行，很專業。有些pm很苦惱：我明明說的是對的，為什麼研發人員聽不進去？是的，你說的可能是對的，但是由於你平時的表現讓研發人員覺得你很外行，他們根本就沒有認真聽你在說什麼。只有盡量多、盡量深入的了解上下游相關崗位的專業知識，並且有一定的實踐經驗，才能讓我們顯得專業。在與相關崗位的溝通中，獲得對方的信任感，進而採納我們的意見。有幾個小技巧可以介紹一下，不過在看這些技巧之前，我必須重申一遍：讓自己變得專業的根本辦法是自己要盡量多的了解各個崗位的專業知識，小技巧只是一種手段，不要幻想著只憑藉技巧就能真正的專業起來。
技巧1：盡量說術語。在我們與研發人員溝通的時候，盡量不要說大白話，而是使用術語。這樣會讓人家感覺我們很懂技術。例如有一次我和一個客戶端工程師說：「我希望彈出的窗口是模態的。」工程師聽完後很詫異的說：「你還知道模態？」我說：「當然啦，這對交互設計很重要啊。」於是工程師立刻就把窗口改成模態的了，根本沒問我為什麼。那麼什麼叫模態呢？用大白話說就是彈出一個窗口，窗口以外的地方都是黑的，或者不可以操作，只有這個窗口可以操作，類似於win裡面經常彈出來的討厭的錯誤提示。但是你要是跟工程師這麼描述，碰上脾氣好的說不準幫你改改，碰上不好的準保反問一句：那多討厭啊，我就討厭win彈錯誤提示。技巧2：思維要周密，在說話之前要盡量把所有可能的情況及其解決方案想清楚。比如你要修改一個按鈕的位置，人家自然要問你，空出來的位置怎麼辦，改過去之後會不會影響現有的功能，用戶能不能習慣等等，如果你能胸有成竹的一一化解，別人自然會聽從你的建議。
技巧3：讓對方自己得出結論。人都是有自尊心的，都希望自己的決定是正確決定，如果你總是說：「你這樣是錯的，我是對的」必然引起別人的反感。所以你可以先把遇到的問題擺出來，在提出自己的解決方案後立刻說：這方面你是專家，如果你覺得這個方案能用就用，如果有更好的方案我也沒什麼意見。
人嘛，通常都是比較懶的，既然你能提出一個還算說得過去的解決方案，而且又讓對方覺得是他自己的選擇，通常也就不會為難你了。技巧4：看人下菜碟。不是對每個都用同樣的話說服的，人和人都有所不同。以我的經驗，對待工程師、設計師、老闆是不同的。
對待工程師要有條理，邏輯要清晰，講究數據。例如：方案1會造成數據伺服器負荷過重，並發量在2萬/秒以上，並且至少要佔用10g的儲存空間，最重要的是，我們付出了這麼大的代價，其實只滿足了20%的用戶，而且這部分用基本上都是不付費的用戶。這一大套話說完，研發人員會認真想一想：也是啊，萬一伺服器宕機了責任就大了，還是用方案2吧。對待設計師要以情動人，因為設計師一般都是學美術出身的，特別感性。例如：大姐，你就給我改改吧，為了畫這個原型我昨天都加了一宿班了，你今天不改，明天指不定又插進來什麼活兒呢，我這個項目得什麼時候上線啊。再說也不是我想改啊，是銷售那邊兒一會兒說用戶喜歡這個，一會兒說用戶喜歡那個，我們也擰不過他們啊。設計師一聽，都是同事，誰還沒個難處啊，得了，加班兒給人做了吧。
對待老闆要學會畫藍圖，例如：根據競品研究的結果看，這個產品非常有前景，XX剛上線1個月，就已經有100萬用戶，10萬同時在線，收入也差不多有400來萬。我們在技術上、渠道上、政府關係上都比他們強，我覺得只要能夠在2個月內推出，各項數據肯定比他們強。更何況，我們的產品線目前缺乏的就是用戶沉澱，而這個產品正好提供了強大的社交功能，彌補了產品線的空缺。老闆一聽，小夥子想的挺清楚啊，成，給你兩個工程師，一個設計師，1萬塊項目獎金，1個月給我做出來。業績好的話再給你發年終獎。
當然啦，還有些人江湖氣很濃，他只要當你是兄弟，你怎麼說他怎麼做，沒原因，沒為什麼。對於這種人平時多吃幾頓飯，多送點小禮物，到時候自然幫你。
技巧5：人格魅力。做人要有幽默感，要學會緩和氣氛。沒必要每次需求討論的時候都板著臉訓人。說說笑話，插科打諢，給設計師倒杯水，給工程錘錘肩，送給運營的小姑娘幾塊兒巧克力，給運維的同事買幾瓶水。你平時這麼注重積累，在你需要的時候別人自然不會為難你。能做的就做了，不能做的睜一眼閉一眼也就做了。
最後再說一遍，所有的技巧都是一種手段，真才實幹才是王道。（理想情況下，拋開細節，你應該比技術人員更懂技術。不過的確難以事事盡如人意。。。）
禁止僅僅否定，所有否定都必需配合更好的替代方案。所謂建設性意見。
說明你的理由，詢問他的理由。比較「術語」，我更喜歡「數字」和「先例」。他們往往能在說人話的同時，帶來良好的說服力。另外好的交流能力，也可以避免無謂的對抗。
如果技術人員的考慮真的靠譜，承認自己SB，當眾表揚他。這會讓你和你的團隊在以後更好的互動。
雙方應該都可以承認，有些決定本身並不重要，關鍵是有一個決定。
關鍵時刻你做決定。
無論你選了誰的方案，你為這個決定承擔責任。
有的產品經理，說白了，就是內部用戶需求反饋。說出個功能，漏洞百出，還要程序員找出來邏輯漏洞問怎麼繼續，然後就是先讓我們做看看實際效果。當程序員的工作象你那麼簡單？想想就完了？好不容易寫個架構，結果讓你毫無邏輯的展示弄的面目全非，直接面向過程算了。還有吐槽，怎麼總把pm這個詞弄混？pm不是產品經理。
把事情自己弄明白了，才能說明白。各種溝通技巧再強，開發不是傻子，還是要看要做的事是否靠譜。
當然要說服別人要有鍥而不捨的主動，自己搞明白，然後讓技術明白~ 我覺得我還是不擅長總結，愛講故事，那就講幾個說服技術的故事吧~第一個：
之前跟外包公司合作一個產品，開發是外地的外包的。在運營過程中出現了一些問題，我們錄入的數據發現後台價格自動會變，而且上線賣的商品價格也會變。 反饋給開發查，他們查了好久沒有結果。（到底有沒有真的查不得而知），通常項目外包，產品開發完後，外包公司會隨便找個資歷淺的開發來做一下維護。或者有什麼問題，只要沒有太嚴重的，他們都會讓它慢慢不了了之。 於是我自己在錄入數據的時候特別留意，終於有一次發現後台數據真的自動變了，然後截圖郵件給他們。他們派一個開發來找我，讓問題重現給他們看。但是當時操作也不知道怎麼出現的，他們說沒辦法說後續會關注的。 於是我拿著這個問題去問認識的開發，把他的話（專業術語）去跟開發溝通，一點點地問，通過這個過程自己也模糊地了解了。在那段時間，腦袋裡總想著這個問題，把想到的各種可能的理由跟開發溝通，雖然通常他都不太花精力來討論，但是從他糖篩我的 話中，我還是了解到不少東西。 有一天隨便聊的時候問到他們公司都是在一個大的架構框架上做的各種項目，然後我問是不是他們那個框架有問題，他把問題反饋到架構組查，還真是。原來那個用的國外的一個框架，據說過時了存在一個bug。我一個不懂技術，不是他們公司的人，幫他們發現了這個bug，從此以後我查什麼問題，讓他幫忙做的事，基本非常配合了。總結就是：
1、把他們當兄弟，就算是外包的開發，還是要當哥們來溝通。讓他從心底接受我們的合作。 2、在溝通過程中，不要局限只跟一個人溝通，先到別處了解更多然後學著用技術術語跟他們聊。 3、內心要強大，在沒有拿到結果前，不要放棄。通常他們敷衍回復的一個答案就想把你給打發了。但是不要緊，自己多去別處了解點情況，然後帶著新的知識跟他們溝通，讓他們有所收穫、有所悟，他們就會反過來想要了解更多。 第二個： 我們在一個產品改版的時候，設計師給的視覺稿，不太滿意。改了很多版，後面改到他見到我就跑去抽煙。 要讓他繼續改下去，我不能說不大氣，不精緻那種話來。於是，自己跑去看設計原理的書，在網上到處看，自己也苦思冥想，也去找一些設計師的朋友提建議。總一些頁面，設計給他參考。 那段時間腦袋滿是那個設計稿，就是看書里的插圖也能聯想到如果用到我們的改版中怎麼樣？自己心裡要大概明白自己想要的是什麼，然後描述具體些，另外一部分要相信設計師。你把自己想要描述了，也讓他們看到可改的空間，他們再發揮一下，差不多也可以做到你想要的結果。 想PD、PM推動別人去做事，真的是比較辛苦的。要想讓他們陪著一起玩，那就得讓他們看到我們有在努力想，有在說還是算靠譜的話，有尊重他們。提需求不要張口就來，要深思熟慮，有理有據。
產品提需求，開發實現，本來開發就有一定程度排斥心裡，換位思考下也是人之常情：你動下嘴，別人就要負責實現，二者的成本是不對等的。如果你的需求本身又禁不起推敲，結果可想而知。
所以說產品的工作要做在前面。。
就題論題，回答如下:1： 專業 （professional)2： 友善 (friendly)3： 利益 (benefit)
在說服之前，首先會審視自己的觀點是否正確，先把想法沉澱幾天，多角度在自己腦子裡過上幾遍，如果沒有發現問題再去說服別人，如果自己都能推翻自己的想法，那就要重新審視之前的觀點。所以說，說服別人之前首先要說服自己，只有這樣才能意志堅定，在沉澱過程中你已經考慮過各種能推翻觀點的可能，再去應對他人的質疑就會容易許多了。
首先要先判斷一下你和團隊中工程師之間的關係處於什麼狀態：如果是一個互相信任的狀態，你說的問題其實很難存在，所以說最重要的是建立信任關係。而被工程師所信任的基礎，就是能憑藉自己的專業能力給出正確的產品判斷；如果是一開始建立信任的狀態，那麼溝通前的準備就相當重要了。工程師是邏輯嚴謹數據說話的，在溝通之前是否把需求的背景、目標、前因後果都有邏輯的論述清楚，如果有數據支撐就更容易達成目的。還要主要不要朝令夕改；上線後還能及時反饋效果，進行總結分析，讓工程師覺得你是靠譜的，這樣以後質疑你的判斷會越來越少。
如果已經是不被信任的關係了，則更需要謹慎對待。如果已經到了情緒對立的階段，建議還是請你的leader出面幫忙調解吧，先把這個事情落實了再說。這裡PM是指Product Manager還是Project Manager?我猜是前者吧。
從用戶需求到功能設計到實現，在多人團隊中是一個溝通和妥協的過程。簡單的說，產品經理提出需求，項目經理主要負責分析論證需求，開發人員主要負責編碼以實現需求。但實際情況是，據我粗淺的認識，目前很多小公司做網站，僅僅配一個產品經理，其餘都是開發人員，而且常常沒有測試。所以產品經理和開發人員的矛盾就更加突出。產品經理不懂技術，或者對技術一知半解，常常覺得「某某功能有什麼難的，只需要...."。而從軟體開發人員的角度來說，通常的問題是由於網站需要快速開發/快速發布，一開始僅僅為了實現功能而編碼，很難去考慮設計問題。代碼基礎沒有打好，尤其不適應改變，導致修改一個功能要涉及太多的方面，因此很容易產生抵觸情緒。並且很多開發人員，對產品本身也有很多自己的想法，當產品經理提出的功能需求不能被很好的理解的時候，雙方也容易出現矛盾。
私以為，每個人都需要明確自己的主要職責在哪裡，這是溝通順暢的第一步。產品經理提出的功能，需要依賴開發人員的透徹理解和消化，然後才能實現。軟體開發人員也必須明確自己的職責，知道自己對產品功能和設計的認識一定不會比產品經理更深，自己的本職應該是儘力去保證軟體的質量，做好軟體設計。
代碼是軟體開發人員一行行寫出來的，不論好壞，都是他的勞動成果。每個人對自己的勞動成果都有一個下意識的保護心理，我不知道心理學家是如何解釋這種現象，但這確確實實是存在的。代碼的修改和重寫否定在某種程度上都是對其勞動成果的否定，這常常會引起開發人員下意識的抵觸。
不論公司/團隊大小，不論職位高低，有四個字是必須遵守的，就是「以理服人」。產品經理不要把軟體開發人員僅僅看作是一台編程機器，而開發人員也不要覺得產品經理什麼也不懂就「指手畫腳」。不論是誰，都不要覺得自己的觀點是有多麼正確，別人就應該接受。坦誠的溝通，才能夠達到最好的效果。
有一個比喻，我忘記出處了，說「每個軟體開發人員就像一隻驕傲的貓」。個人覺得，要管理好軟體開發人員，起碼需要一個專門的角色，不管是叫Project Manager還是Team Leader，需要他/她懂技術懂管理，讓其他開發人員認同。
-----更新----
作為對 @zhaosj 的回應，也算是對我的觀點的補充，我想再多說兩句。我個人不認同「什麼什麼是誰的責任，你不用擔心。」這種觀點。這種說法雖然在道理上是說得通的，但是在實際工作中不見得奏效。原因有二：1. 軟體產品是整個團隊合作的勞動成果，這種觀點更多的會容易誤導團隊，造成」個人自掃門前雪「的氛圍，這對團隊建設是有害的。我們應該強調產品的質量是每一個人的責任。
2. 如果一旦出了問題，比如是PM的責任，你能怎麼樣？扣工資？扣獎金？還是公開道歉？自我批評？然後呢？問題最終還是要解決，還是要依賴PM和開發人員一起來解決問題。因此我覺得，儘管每個人都有自己專長的領域，但是不要過於對自己的觀點或者勞動成果過於保護，應該保持一個開放的心態，能夠善於傾聽別人的觀點。有則改之，無則加勉。有沒有有搞錯，PM本來就必須說了算，沒有argu的餘地好不好。
其實感覺把「責任/權利/義務」搞清楚了就好。比如，這個設計你喜歡與否無關，作為開發人員，只要你按期保質保量的完成，我PM就會給你個高評價；至於這個設計本身的成敗責任，不需要你們開發人員去承擔，失敗了是我PM的責任，絕對不會責怪大家；但是如果開發本身出問題，不好意思，各位開發者責無旁貸。上述是執行階段，如果在研討階段則有所不同。因為我自己是技術出身，所以諸如我認可而開發人員不認可的方案，可能性是很低的。我自己就是開發人員，能說服我的理由，也能說服其他開發人員，除非技術水平還不到位，或者考慮不夠周全。這屬於信息不對稱引起的，而不是思路不同，所以只要把必要的資訊共享即可。如果是不同背景的PM和開發人員之間，換位思考就很重要了。對於高學歷空降類型的PM可能有些難度，如果是經驗積累升級類型的PM，則閱歷和口才都有了足夠的鍛煉，不妨考慮一下，可能存在的不同意見會有哪些，為什麼會存在這些argu。有時候反對意見甚至和方案完全無關，而是由例如個人的私事、意氣之爭、偶發事件等非理性因素引起的。所以說，解釋和說明是有限度的，可以在會議上盡情的討論、釋放，但是該說的說了、該做的做了，最終必須要有結論，剩下的就應該是執行。所以PM請大膽的相信自己就該說了算。你一次沒對過，只有你的知己會信你。
你贏過一次，會有一批和你一起贏的人，以及一些了解你的人信你。你一直贏，絕大部分人都會信你。失敗是成功之母那種話只能安慰自己的～對別人來說百嘛不是～只有成功才能累積成功～
所以關鍵問題就簡化了，你第一次怎麼樣才能贏？！很多人的做法是刷簡歷～
那麼簡化出另一個問題，你簡歷慘不忍睹，怎麼樣贏第一次？好吧，有種說法叫做，你要在某件事上做到最好，就要在其他方面做到最糟。那麼你已經把你的簡歷搞的慘不忍睹了，你就必須從敗者組殺出。那你一個人就要手眼通天，像一支部隊一樣去戰鬥～一個人怎麼樣才能像一支部隊？策劃、設計、開發、運營，你都得身體力行。如果你還要問，如果這些你都幹了，還要其他員工幹嘛，你這PM有個屁用。那就是一個簡單的答案，以你現在的程度，別人叫你聲PM是給你面子，不理你也是本分～你就別太拿自己當回事兒～在中小企業中，很多時候都是產品幾天一個需求，PM今天給說了要怎麼樣，可能明天PM在來告訴不需要了，由於長期這樣積累的矛盾和不滿越來越多。
PM需要做正確的決定，而不是把自己一時的想法當決定。其實產品經理在提需求的時候，最主要是"改"需求最容易讓開發同學反彈，為什麽呢？
將心比心思考一下，改需求就代表：
- 你之前沒想清楚，結果要開發來承擔？
- 這次改完，你真的想清楚？會不會明天又改？
- 之前開發做的等於白做，心情一萬點OOXX
....等理由
當了解團隊的心情之後，是不是比較知道該如何溝通？說明原因最重要！但最好放低姿態，體諒一下開發的感受，好好溝通理由（開發最討厭，明明錯了還理直氣壯）
- 悲情牌：老大要改的我也很無奈（老大：這鍋我不背）
- 誠懇牌：我之前想錯了，這樣對於用戶最好...（直接道歉最直白）
- 數據牌：數據證明....（確實沒人能想清楚，最好用數據說話）
- 討打牌：我感覺要這樣改！（純憑感覺很危險，除非你是張小龍或者部門老大）
哈哈哈希望大家可以好好溝通～天天向上！
更多小訣竅可以看我們的書：網易一千零一夜。或關注NetEasePM
做了這麼多年，經常聽到有人說管理問題，溝通問題，技巧問題。
其實這些都是一種不知道問題根源的託詞。其實都是人的問題，管理模式再好，關鍵是人在執行。而人是又感情和情緒的。
再說溝通問題，任何兩個的的溝通都是有問題的。因為不是一個人，想法必然不同。再說技巧問題，任何技巧在人的本性面前都是乏力和蒼白的，人家一聽就知道你是假話還是真話。所以關鍵是人的問題，我們經常崇拜美國的文化。可是我們真的了解美國文化嗎？
我問大家一個悖論的問題，既然美國那麼講究制度，為什麼大家還都要去關心總統是誰的呢？任何管理都是人在執行，任何溝通也都是人在溝通。
這要這個人的本質，本性我們了解，其他的任何問題都不是問題。這個方面我們中國上下5千年已經總結的很徹底了。
孫子兵法開篇：一曰道，二曰天，三曰地，四曰將，五曰法。這個道講的就是人的重要性。一個昏君，你做啥也沒有。到頭來象岳飛一樣，只得個名聲，但大多數連這個都沒有。
所以什麼管理，溝通都是浮雲。重要的是跟對人，選對人，用對人。
提升綜合知識體系，在設計功能之前先想清楚為什麼要這麼設計，思維縝密，專業，在討論階段就要和開發人員達成共識，換位思維，很多開發人員也會從使用的角度考慮問題的。
everybody is a sales. 推銷自己和推銷商品一樣。如樓上所言，除了自身能力的積累，tricks也有必要性。
因為你不尊重別人的勞動，別人自然也不尊重你的勞動。你一個設計失誤，讓別人返工擦屁股，誰不煩啊。相比新增需求，技術更怕砍需求，改需求。別人加班熬夜趕出來的功能，因為你考慮不周，結果砍掉了，這就是浪費別人的生命。今天你說要這樣，明天你說要那樣，連你自己想要什麼都不確定，這不是折騰人嗎。用說服才能得到認可的需求可以不做，即便是做也沒有太大的價值。
正是因為大多數市面上的產品經理不斷的把時間精力放在了給自己的需求找理由讓別人做上，才讓市面上出現了一批又一批屎一樣的產品。難道，做不做一件事情不是由價值決定的么？你的每一個設計改動不是為了更好的解決問題么？想想，你自己為什麼要做這個修改想想，這個設計解決了什麼樣的問題想想，你當時為什麼堅定的認為這麼做能解決問題想想，別人不同意是不是他有更好的辦法把所有用於說服的心思用在解決問題上，由表面轉向深層細節不願意被修改，是因為細節能帶來的體驗最不能讓人直觀的感知。改顏色，你能清晰的講出這些顏色色值對於人們情緒波動產生的影響么？改大小，你能清楚的講出大小對於用戶眼部視覺焦點的導向曲線么？改布局，你能清楚給給出不同布局會使得用戶點擊發生什麼樣的轉變么？你該做的不是如何說服別人，而是如何充實自己
讓自己清晰的知道每一個細節為什麼這樣，讓自己清晰的知道每一個改動解決了什麼事情，創造了什麼價值一個能把梳子賣給和尚的銷售，以如何把梳子賣給和尚的理念去做一個互聯網產品，最終能呈現的無非是一系列荒誕可笑的段子做你該做的事，解決你沒解決的問題，不要嘗試著說服任何人，而是把時間放在一系列有意義的事情上，讓你做的事情本身就有意義，清晰的告知別人為什麼有意義，從中找到是否會有做法能讓這件事情更加有意義，這才是職責@李楠 順便鄙視一下你，你能教人干點正事不，怪不得看你們手機每次更新出來的東西全是你們看起來很好的設計，這些設計都是靠說服才做出來的是么
溝通的藝術，要想有立足還是得對自己感興趣的領域深入研究
其實做任何一件事都是妥協的結果，PM的視角也不一定是完全正確的，需要與客戶、技術、設計等人員深入充分的溝通。做一個決定有爭議是正常的，但一旦決定了就要緊決執行。
推薦閱讀：
※作為產品經理，如何對應用的質量狀況進行監控？
※你為什麼做產品經理？
※產品經理如何進行市場調研？
※產品經理需要背負銷售額么？
※mockups和墨刀還有axure，三個對於產品的發展來說哪個更好？