從事運營工作的人往往自嘲是打雜的，的確這份工作通常做些很瑣碎的事情。在運營實際工作中，需要和其他各個部門配合，以提升運營效率，達到運營目的。在和各個部門的配合中，溝通是非常重要的，良好的溝通往往可以使配合更加有效，項目推進也會比較順利。在和不同的部門溝通中，自然也會有些不同的技巧，今天就來聊聊運營中，和其他部門溝通的技巧。

和產品的溝通

產品和運營其實是一條船上的人，兩者是處于同一戰線的兄弟，甚至在一些小團隊里，產品和運營之間的界限也是模糊的。某些產品指標也是二者共同負責的，比如日活、次日留存等等。因此和產品的溝通會比和其他部門溝通更簡單一些。

運營會提出功能上的需求，產品來評估優先級，這個時候會有分歧，因為運營提出功能需求，往往是為了提升運營的效率和數據，而產品評估優先級的維度會更多，首先是用戶層面，然后是公司戰略，也許最后才會是運營上的方便。這個時候運營去和產品溝通的策略就是從用戶層面、公司戰略上拔高某項功能需求的重要性，最好是有數據支撐。

舉個例子，一個線教育產品，其核心功能是看課，社區討論功能就屬于次要功能，但對社區運營人員來說，社區的功能完善對于其運營工作極其重要，這塊功能的完善可以大大提升社區的活躍度，在產品和開發資源有限的情況下， 如何去和產品溝通，才能使其重視社區上的功能呢？

那就從學生學習的角度分析，社區討論有老師答疑， 看課滿足的是學生的一般需求，而答疑是滿足學生的個性化需求，答疑功能的完善對于學生的使用體驗來說非常重要，并且我們通過數據分析看到越來越多的學生來社區向老師提問，老師的回答也很及時，這塊功能不盡快上線，對用戶體驗會有極大的影響。并且從公司戰略的角度分析，公司正在摸索課程之外的其他用戶服務方式，這就是非常重要的一種，因此這部分功能優先級能否提升呢？相信通過這樣一番溝通，運營提出的功能需求，自然會得到產品的重視。

和技術的溝通

運營和技術直接溝通的情況不太多，因為技術只接產品PRD中的需求。只有在兩種情況下，運營會直接和技術溝通，那就是發現bug和項目性的功能支持。

發現bug的溝通會稍微簡單一些，只需將發現的bug傳達給相關技術負責人，并要求對方給予一個解決日期，后續跟進就可以了。在這里，對bug的描述越清晰越好，可以通過截圖的方式記錄，并盡可能描述出現該bug的操作步驟，使用環境等，這是為了技術排查bug出現的原因，然后說明該bug影響的范圍和用戶行為，并陳述其重要性，這是為了給技術解決該bug的優先級評估。作為運營，不需要技術給出bug出現的原因以及如何解決，只需要對方給我們一個解決的時間節點，以便我們能及時跟進。

關于項目性的功能支持，則需要反復溝通，要講明白需求，提前寫好驗收標準。比如找前端寫個專題頁面，運營策劃好專題內容，風格特色，交由設計做出設計稿，就可以和前端去溝通了。有時候對功能的需求和標準描述不夠專業，會讓對方聽不明白，這個時候拿著案例去說就會好很多，我就想要做成某某頁面的樣子，這樣對于前端理解運營的需求會很有幫助。不要去和技術探討專業的東西，只談邏輯就好。另外，讓人幫忙做事，態度一定要好喲。

和市場的溝通

市場有很多工作種類，有一線的推廣人員，也有品牌公關人員。和他們的配合往往是對雙方都有利的。

一線推廣人員是最了解用戶的，他們會給運營反饋一線的情況，甚至競品做的一些事情，這對運營提升效率非常有用，因此和一線推廣人員的溝通，以聽為主，并根據他們提供的信息，做一些判斷和分析，并適時做一些能夠輔助一線推廣人員的運營活動。

和品牌公關人員的配合會稍微少一些，與他們配合也多是內容上的配合，他們有時會需要一些運營上的數據，產品上內容詳情，這些按流程配合就好，溝通不存在障礙。倒是可以多去和他們聊聊他們做的事情，或許能在運營上帶給你一些靈感。

和客服的溝通

我想客服是對產品最熟悉的人，也是最能發現產品、運營上漏洞和問題的人?？头墓ぷ鲀热菀话闶墙邮苡脩舻淖稍?，解決用戶使用過程中的問題，處理用戶的抱怨和投訴。和客服溝通，可以知道自己哪里做的不夠好，用戶面臨哪些問題。

在運營活動中，一份客服文檔是保持信息互通的很好方式，也是避免很多不必要溝通的方法?？头臋n，通常包括活動的基本內容（活動形式、活動時間、活動獎品等等）和常見問題的解答。這樣客服收到用戶關于活動方面的咨詢和反饋時，可以根據客服文檔及時作出回應，而不是再來找運營人員溝通詢問。

總結

和不同部門溝通技巧雖有差別，但根本上是有相同的，就是清楚自己的目的，站在對方的角度，以對方能聽懂的方式溝通。當你掌握了這些溝通的技巧，對于推進自己的項目進度，提升運營效率一定會大有幫助的。

本文由 @奔雷?原創發布于人人都是產品經理。未經許可，禁止轉載。