關于做web產(chǎn)品某些細節(jié)方面的改動，有的時候技術不愿意輕易改動（也包括前端人員），有時候想法會很多，但他們有時候不在乎你所說的。這時我們應該怎么辦？

我們來看看知乎網(wǎng)友的回答：

吳偉

以我7年來做pm的經(jīng)驗來看，說服他人，特別是研發(fā)、設計、前端這些研發(fā)部門的同事，最重要的不是口才、溝通能力和數(shù)據(jù)，而是專業(yè)。專業(yè)就是：第一，你要用內(nèi)行的思維方式、表達方式和處理方式來思考、溝通和執(zhí)行；第二，你要經(jīng)�？梢宰龀稣�確的決定。

一個人要先相信你能說出正確的話，才有可能認真去聽你說的內(nèi)容，進而才有可能認可你的話。通常人們認為只有內(nèi)行才有可能說出正確的話來，而外行只能瞎指揮。所以pm要時時刻刻表現(xiàn)的很內(nèi)行，很專業(yè)。

有些pm很苦惱：我明明說的是對的，為什么研發(fā)人員聽不進去？是的，你說的可能是對的，但是由于你平時的表現(xiàn)讓研發(fā)人員覺得你很外行，他們根本就沒有認真聽你在說什么。

只有盡量多、盡量深入的了解上下游相關崗位的專業(yè)知識，并且有一定的實踐經(jīng)驗，才能讓我們顯得專業(yè)。在與相關崗位的溝通中，獲得對方的信任感，進而采納我們的意見。

有幾個小技巧可以介紹一下，不過在看這些技巧之前，我必須重申一遍：讓自己變得專業(yè)的根本辦法是自己要盡量多的了解各個崗位的專業(yè)知識，小技巧只是一種手段，不要幻想著只憑借技巧就能真正的專業(yè)起來。

技巧1：盡量說術語。在我們與研發(fā)人員溝通的時候，盡量不要說大白話，而是使用術語。這樣會讓人家感覺我們很懂技術。例如有一次我和一個客戶端工程師說：“我希望彈出的窗口是模態(tài)的。”工程師聽完后很詫異的說：“你還知道模態(tài)？”我說：“當然啦，這對交互設計很重要啊。”于是工程師立刻就把窗口改成模態(tài)的了，根本沒問我為什么。那么什么叫模態(tài)呢？用大白話說就是彈出一個窗口，窗口以外的地方都是黑的，或者不可以操作，只有這個窗口可以操作，類似于win里面經(jīng)常彈出來的討厭的錯誤提示。但是你要是跟工程師這么描述，碰上脾氣好的說不準幫你改改，碰上不好的準保反問一句：那多討厭啊，我就討厭win彈錯誤提示。

技巧2：思維要周密，在說話之前要盡量把所有可能的情況及其解決方案想清楚。比如你要修改一個按鈕的位置，人家自然要問你，空出來的位置怎么辦，改過去之后會不會影響現(xiàn)有的功能，用戶能不能習慣等等，如果你能胸有成竹的一一化解，別人自然會聽從你的建議。

技巧3：讓對方自己得出結(jié)論。人都是有自尊心的，都希望自己的決定是正確決定，如果你總是說：“你這樣是錯的，我是對的”必然引起別人的反感。所以你可以先把遇到的問題擺出來，在提出自己的解決方案后立刻說：這方面你是專家，如果你覺得這個方案能用就用，如果有更好的方案我也沒什么意見。

人嘛，通常都是比較懶的，既然你能提出一個還算說得過去的解決方案，而且又讓對方覺得是他自己的選擇，通常也就不會為難你了。

技巧4：看人下菜碟。不是對每個都用同樣的話說服的，人和人都有所不同。以我的經(jīng)驗，對待工程師、設計師、老板是不同的。

對待工程師要有條理，邏輯要清晰，講究數(shù)據(jù)。例如：方案1會造成數(shù)據(jù)服務器負荷過重，并發(fā)量在2萬/秒以上，并且至少要占用10g的儲存空間，最重要的是，我們付出了這么大的代價，其實只滿足了20%的用戶，而且這部分用基本上都是不付費的用戶。這一大套話說完，研發(fā)人員會認真想一想：也是啊，萬一服務器宕機了責任就大了，還是用方案2吧。

對待設計師要以情動人，因為設計師一般都是學美術出身的，特別感性。例如：大姐，你就給我改改吧，為了畫這個原型我昨天都加了一宿班了，你今天不改，明天指不定又插進來什么活兒呢，我這個項目得什么時候上線啊。再說也不是我想改啊，是銷售那邊兒一會兒說用戶喜歡這個，一會兒說用戶喜歡那個，我們也擰不過他們啊。設計師一聽，都是同事，誰還沒個難處啊，得了，加班兒給人做了吧。

對待老板要學會畫藍圖，例如：根據(jù)競品研究的結(jié)果看，這個產(chǎn)品非常有前景，XX剛上線1個月，就已經(jīng)有100萬用戶，10萬同時在線，收入也差不多有400來萬。我們在技術上、渠道上、政府關系上都比他們強，我覺得只要能夠在2個月內(nèi)推出，各項數(shù)據(jù)肯定比他們強。更何況，我們的產(chǎn)品線目前缺乏的就是用戶沉淀，而這個產(chǎn)品正好提供了強大的社交功能，彌補了產(chǎn)品線的空缺。老板一聽，小伙子想的挺清楚啊，成，給你兩個工程師，一個設計師，1萬塊項目獎金，1個月給我做出來。業(yè)績好的話再給你發(fā)年終獎。

當然啦，還有些人江湖氣很濃，他只要當你是兄弟，你怎么說他怎么做，沒原因，沒為什么。對于這種人平時多吃幾頓飯，多送點小禮物，到時候自然幫你。

技巧5：人格魅力。做人要有幽默感，要學會緩和氣氛。沒必要每次需求討論的時候都板著臉訓人。說說笑話，插科打諢，給設計師倒杯水，給工程錘錘肩，送給運營的小姑娘幾塊兒巧克力，給運維的同事買幾瓶水。你平時這么注重積累，在你需要的時候別人自然不會為難你。能做的就做了，不能做的睜一眼閉一眼也就做了。

最后再說一遍，所有的技巧都是一種手段，真才實干才是王道。 

孫立偉

這里PM是指Product Manager還是Project Manager?我猜是前者吧。

從用戶需求到功能設計到實現(xiàn)，在多人團隊中是一個溝通和妥協(xié)的過程。簡單的說，產(chǎn)品經(jīng)理提出需求，項目經(jīng)理主要負責分析論證需求，開發(fā)人員主要負責編碼以實現(xiàn)需求。但實際情況是，據(jù)我粗淺的認識，目前很多小公司做網(wǎng)站，僅僅配一個產(chǎn)品經(jīng)理，其余都是開發(fā)人員，而且常常沒有測試。所以產(chǎn)品經(jīng)理和開發(fā)人員的矛盾就更加突出。產(chǎn)品經(jīng)理不懂技術，或者對技術一知半解，常常覺得“某某功能有什么難的，只需要...."。而從軟件開發(fā)人員的角度來說，通常的問題是由于網(wǎng)站需要快速開發(fā)/快速發(fā)布，一開始僅僅為了實現(xiàn)功能而編碼，很難去考慮設計問題。代碼基礎沒有打好，尤其不適應改變，導致修改一個功能要涉及太多的方面，因此很容易產(chǎn)生抵觸情緒。并且很多開發(fā)人員，對產(chǎn)品本身也有很多自己的想法，當產(chǎn)品經(jīng)理提出的功能需求不能被很好的理解的時候，雙方也容易出現(xiàn)矛盾。

私以為，每個人都需要明確自己的主要職責在哪里，這是溝通順暢的第一步。產(chǎn)品經(jīng)理提出的功能，需要依賴開發(fā)人員的透徹理解和消化，然后才能實現(xiàn)。軟件開發(fā)人員也必須明確自己的職責，知道自己對產(chǎn)品功能和設計的認識一定不會比產(chǎn)品經(jīng)理更深，自己的本職應該是盡力去保證軟件的質(zhì)量，做好軟件設計。

代碼是軟件開發(fā)人員一行行寫出來的，不論好壞，都是他的勞動成果。每個人對自己的勞動成果都有一個下意識的保護心理，我不知道心理學家是如何解釋這種現(xiàn)象，但這確確實實是存在的。代碼的修改和重寫否定在某種程度上都是對其勞動成果的否定，這常常會引起開發(fā)人員下意識的抵觸。

不論公司/團隊大小，不論職位高低，有四個字是必須遵守的，就是“以理服人”。產(chǎn)品經(jīng)理不要把軟件開發(fā)人員僅僅看作是一臺編程機器，而開發(fā)人員也不要覺得產(chǎn)品經(jīng)理什么也不懂就“指手畫腳”。不論是誰，都不要覺得自己的觀點是有多么正確，別人就應該接受。坦誠的溝通，才能夠達到最好的效果。

有一個比喻，我忘記出處了，說“每個軟件開發(fā)人員就像一只驕傲的貓”。個人覺得，要管理好軟件開發(fā)人員，起碼需要一個專門的角色，不管是叫Project Manager還是Team Leader，需要他/她懂技術懂管理，讓其他開發(fā)人員認同。

我個人不認同“什么什么是誰的責任，你不用擔心。”這種觀點。這種說法雖然在道理上是說得通的，但是在實際工作中不見得奏效。原因有二：

1. 軟件產(chǎn)品是整個團隊合作的勞動成果，這種觀點更多的會容易誤導團隊，造成”個人自掃門前雪“的氛圍，這對團隊建設是有害的。我們應該強調(diào)產(chǎn)品的質(zhì)量是每一個人的責任。

2. 如果一旦出了問題，比如是PM的責任，你能怎么樣？扣工資？扣獎金？還是公開道歉？自我批評？然后呢？問題最終還是要解決，還是要依賴PM和開發(fā)人員一起來解決問題。

因此我覺得，盡管每個人都有自己專長的領域，但是不要過于對自己的觀點或者勞動成果過于保護，應該保持一個開放的心態(tài)，能夠善于傾聽別人的觀點。有則改之，無則加勉。

延伸閱讀：產(chǎn)品經(jīng)理如何贏得程序員的尊重和支持？

本文系站長之家整理自知乎網(wǎng)，轉(zhuǎn)載請注明出處鏈接。

標簽： 產(chǎn)品經(jīng)理 產(chǎn)品經(jīng)理能力 團隊溝通 

版權(quán)申明：本站文章部分自網(wǎng)絡，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。