大廠產品專家教你：如何做好跨部門溝通在職場中，跨部門溝通是一個非常重要的軟技能，不管是要完成日常項目，還是接手新的業務，或者平時項目匯報和晉升答辯，這些都需要有良好的跨部門溝通能力。本文作者總結了幾點跨部門溝通技巧，一起來看一下吧。學姐還記得十幾年前自己剛入職這行的時候，滿腦子都是想著“做出有價值的產品”，當時的組織架構也比較精簡，幾乎是在“橫沖直撞”地做項目。隨著行業的發展，公司規模也越來越大，一開始是業務線越來越多，后來是BU越來越多，最后甚至有的業務線成立了“公司”，公司變成了“集團”，跨部門溝通變成了日常。曾經有一個大老板提醒我，需要提升一下自己職場的“軟技能”，當時不太理解這玩意兒有啥用，咱能做出有價值的產品不就完事了嘛？不過越到后期越能感受到，跨部門溝通這個軟技能尤為重要：產品經理沒有辦法一個人完成項目，幾乎所有的項目都需要和跨部門的同事合作，簡單的一個功能點可能需要與設計師、研發合作，復雜點需要運營、法務、財務，甚至可能要和其他公司的同事溝通（關于做項目的流程，可以看學姐的這篇文章）產品經理經常會轉崗、或跳槽，這時候就需要接手新的業務，如果缺乏溝通技巧，往往會在這些關鍵節點上栽跟頭（關于如何接手一個新業務，可以看學姐的這篇文章）不管是平時的周會、月會，項目匯報還是晉升答辯，都需要平時良好的跨部門溝通作為打底，不然很容易被其他部門的老板“拆臺”（關于項目匯報模版，可以看學姐的這篇文章）接下來學姐就分享一些自己總結出的跨部門溝通技巧～Part.1端正態度和談戀愛差不多，跨部門溝通的時候，我們一定要先端正自己的態度。很多童鞋覺得，工作場合大家公事公辦嘛，我提的建議是對事不對人的，該怎么樣就怎么樣咯～這種做法在大家已經建立起信任關系的時候是OK的，但如果大家都不熟悉，或者關系本來就有點對立的話，學姐就建議童鞋們在溝通的時候注意態度。首先，大家一定要告訴自己，任何工種都是有價值的，有些童鞋在工作的時候總覺得別的同事是來給自己項目添亂的。比如學姐曾經在職場上遇到一個產品總監，在和老板開會的時候討論設計方案，因為設計總監在設計方案上有一些自己的想法（那不是很正常嗎），就直接說了句“你們設計師就喜歡糾結這些”，言語中透露著對他人工作的不尊重，讓設計總監暴跳如雷。自此以后這位產品總監力推的需求，在設計師那里都很磕磕絆絆，沒多久他就被離職了……其次，我們要多傾聽其他部門同事的建議和想法，雖然他們沒有你這么了解這個項目/業務（甚至有時候我們會覺得他們提的建議很傻），我們也不能粗暴打斷別人。應該先嘗試理解他們的出發點，和他們耐心解釋，是否可以換一個路徑，來達成他們的目的，或者等后續資源充足的時候再來實現他們的需求。最后，也可以適當建立一些私人關系啦～比如，在開會前拉拉家常，一方面可以更好地幫助你了解這位同事，另一方面也可以活躍下氣氛，不要做一個無情的“推項目機器”，其實大家的工作有時候挺枯燥的，都需要適當放松下。Part.2換位思考態度擺正之后，我們還要學會換位思考，說起來簡單，做起來有點小難度，學姐在這里就給大家支三個招。首先，我們學習不同工種的基礎知識。舉個例子，如果我們想和設計師溝通更順暢，就可以多去看看競品的設計方案，多去找一些設計得比較精美的App，在設計師做視覺還原的時候也可以多參與，盡量提升自己的審美。再比如，我們可以學習一些編程、SQL等，對于不同工種的專業術語，比如技術名詞等，我們也可以去網上多查查他們的含義（問AI也很方便）。其次，我們要了解其他部門的指標。每個部門其實都有自己的業績要完成，也面臨著鴨梨，如果我們在推進項目的時候，能把他們部門的指標考慮進去，做到雙贏，那溝通自然也就順暢了，退一步說，我們至少不能拖累他們的指標。當然，有時候我們也難免遇到一些不能兩全的時候，比如上線一個新功能或者新活動，必然就會增加一些用戶投訴，這時候客服部門的指標就容易被拖累，這時候我們一方面要盡可能把這個影響降到最低，另外一方面要及時通知對方，避免因為我們的項目讓對方部門“背鍋”，這樣才能維系好關系。最后，我們也要了解他們的組織架構，有時候合作部門提出一些角度刁鉆的建議，很有可能是因為他們受到了老板的“指示”，雖然他們心里也不一定認同老板說的，但也只能硬著頭皮過來給我們提建議。這時候我們去否定他們就比較難了，可以考慮讓自己的老板出面去和對面的溝通，這樣同level的人去溝通，效率會更高一些，千萬不要盲目相信什么互聯網扁平化管理之類的～Part.3良性循環在跨部門合作中，有時候出現因為溝通不到位導致兩個部門結下“梁子”，學姐還記得以前還遇到過兩個同事互相拉黑的情況，導致陷入惡性循環。怎么樣才能避免這種情況呢？學姐覺得，溝通不僅要做到“及時”，更要做到“超前”，這樣才能形成一個良性循環。在項目前期，我們往往會做一些客戶調研，比如訪談、問卷之類的，雖然這時候研發和設計的同事還不需要跟進，需求方案也是八字還沒一撇，我們還是可以把一些調研的結果通過郵件或者分享會的形式共享給他們。這樣等到后續輸出方案的時候，他們就有更多的背景知識，也更容易和你站在同一條戰線上。在項目中期，開需求評審會之前，我們也可以私下約設計、研發、運營的同事，簡單講一下大致的方案，特別是溝通一些我們覺得會有挑戰的地方。這樣，到了正式開會的時候，就不至于被“突然襲擊”，被挑戰得太慘。在項目開始啟動研發之后，任何的變更，我們都要及時告知合作部門，讓他們心里有底，可千萬不能“先斬后奏”～在項目后期，比如可以開始測試、UAT的時候，我們也要及時告知合作部門，讓他們都參與到產品體驗中，避免上線了之后他們再提出一些意見，這時候改起來就很麻煩了。項目上線后，我們也要及時把上線后的數據分享給對方，當然