隨著網際網路產品逐漸發展成熟，運營的職能和重要性相比以往愈來愈凸顯，尤其在產品進入相對穩定發展階段由運營主導的時候，以及初創公司團隊由於人手有限運營可能要身兼數職的時候，運營與團隊其他成員尤其是研發（其實也包括設計）是否能夠建立良好的合作就顯得尤為關鍵了。

運營和研發建立良好合作的重要性

通常一個網際網路專案團隊包括如下幾個職能的人員（排名不分先後，且根據具體情況和不同時期人員配置會有增減）：產品、設計、研發、測試、運維、運營、市場、商務，其中的產品主要起到業務需求方（運營 / 市場 / 商務）和技術研發之間的橋樑紐帶的作用，那麼運營作為典型的業務需求方，只要把需求跟產品溝通清楚就好了，為什麼還要和研發建立良好的合作呢？

第一、很多時候，運營要承擔一部分產品的工作，必須和研發打交道

產品都是有生命週期的，一般來說，產品從無到有的孵化階段是以產品人員和研發人員為主導，確保產品按需完成，如期上線；當產品上線後進入相對穩定的上升發展期時，運營逐漸成為主導角色，收集提煉出大量來自使用者的，和運營過程中調研挖掘的產品需求，推動產品不斷迭代最佳化。

而且很多公司裡，產品和研發資源並不是完全從屬於某一個產品線，這個產品上線穩定一段時間後，可能就會調去參與其它專案，不會有很多精力能夠投入該產品的持續優化了。這個時候運營就必須責無旁貸地承擔起一部分產品的工作，要和研發同學直接打交道。

第二、運營是最終擔業績的人，但無法獨立完成業績，需要其它職能的配合

在幾乎所有的網際網路產品中，運營都是最終承擔 KPI 的人，而且運營的工作相對容易量化，可以各種資料指標的變化來衡量。

但網際網路產品資料的提升，是不能僅靠運營單方面來達成的，一定是各個職能多方面通力合作的結果：產品介面不友好，運營拉來使用者也留不住；系統性能不穩定，經常閃退或者報錯，運營每天處理使用者吐槽和救火就疲於奔命了，哪裡還有精力去完成業績。

可是往往運營又並不具備能夠充分調動產品和研發資源的許可權，如果自己團隊有配備專屬的產品研發還好，否則只能是多方面尋求資源協作，能否與研發建立良好的合作關係就尤為重要了。

第三、靠譜的研發能避免很多不必要的資源浪費

見識過不靠譜的研發，你就知道能有靠譜的研發是多麼幸福的事情。

靠譜的研發，不會拍著胸脯說這東西簡單得很兩天就上線，但是一旦承諾了排期就不會拖延；

靠譜的研發，會保證產品開發質量，提交測試基本就是沒有 bug；

靠譜的研發，不會想方設法推卸責任，很多拖了很久懸而未決的問題，到他手裡研究一番就可以得到完美的解決；

靠譜的研發，能結合運營的需求，做出方便又好用的後臺，大大提升運營工作效率；

跟靠譜研發合作，運營不需要無休止地重複測試，提交 bug；不需要沒完沒了地開需求溝通會，天天追著問進度；不需要擔心某個需求無法實現，從而無法開展新業務。你說如果你是運營，是不是一定要努力找出那些靠譜的研發小夥伴組隊啊？

運營如何和研發建立良好的合作

第一、謹慎處理需求，不要讓研發白做工

通常技術都是業務的支援部門，技術要為業務服務，運營會結合業務發展不斷提出需求改進產品是很正常的，但提需求絕不是隨意的和漫無邊際的。

一定是：

經過充分的論證調研——

現有產品確實無法滿足業務發展——

研發成本不會超出現有資源範圍——

才靠譜。

心血來潮、拍腦袋就上、不顧實際資源情況就開乾的專案多半最後都是慘淡收場，參與人員付出的時間和精力也就白搭了。

研發最怕什麼？最怕辛辛苦苦加班加點做出來的產品，最後沒人用啊！等於研發這段工作的價值沒有得到承認。

你如果說我不在乎，反正做什麼不是做，每週都要寫工作週報哦，我是研發只管實現你的需求就好了，做完了有沒有用那是你們業務部門的事情跟我沒關係。這樣想的研發也就是混日子的心態，最後業務沒發展、公司沒發展難道研發日子就會好過嗎？

真的有想法有上進心的研發絕不會這樣想的，一定是希望自己開發的產品真的能夠得到實際的應用，對公司的業務能夠起到很好的支撐，進而自己的價值也得到了體現。

我曾經親眼見過真實的案例：

業務方迫切地要做一個新產品，理由是舊有的產品不適應客戶的需求了，必須要有新的產品來承載客戶需求的變化，而且給出了要實現的時間點（還比較緊迫）。

當時技術部門派出了最精英的程式設計師來負責這個產品的開發，產品如期做完了，結果業務方的反饋是：這不是他們要的東西……

後來我自己負責的專案運營中應用過該產品，覺得還是比較好用的，為什麼業務方會否定它我個人不得而知，也許公司戰略、需求變更、客戶變化種種都是可能的原因，但最後的結果是這個程式設計師被這個專案傷了心，不久離職了。

還有更極端的案例：業務方把業務未完成的原因歸結於產品研發不給力，不能對客戶的需求做到 7*24 小時響應，百分百解決，客戶投訴也讓研發來背鍋，也許研發可能是存在一些問題，但是這樣的合作方式只能是雙輸，業務完成了嗎？也並沒有。

所以說運營在處理需求時是一定要謹慎的，關於如何提煉產品需求，我以後會專門發文陳述我的觀點。

第二、充分說明需求，調動研發的積極性

上文說過，靠譜的研發，有想法有上進心的研發，一定不是機械地只管接活幹活的人。

他們對業務也有自己的理解和想法，有時甚至能從別的角度給出更好的解決方案，前提是要讓他們充分了解這個需求的來龍去脈，這個需求的背景，不僅僅是知道我們要做什麼事，更重要的是我們為什麼要做這個事：現在的這個產品需求是我運營經過調研分析確定的，我的解釋是否能讓你足夠清楚明白了？然後從研發的角度，請你看看是不是有其他的隱藏問題？你有沒有更好的解決方案？我們一起再探討。

最後達成共識確定的需求，並不是運營單方面「壓下來」的需求，而是經過業務方和研發討論後共同認可的需求，研發也充分認識到了這個需求的價值和意義，你說他不會積極主動地完成嗎？一定會的。

而且事先雙方確認了需求和排期，後期的責任也非常明確，即使又有了臨時緊急的需求變更（有時不可避免），也會更容易溝通。

相反，如果運營只是說我要做某個東西，告訴研發我要這樣這樣實現，你不要管為什麼總之你必須給我做了，還得在指定時間點完成，否則到時影響業績責任在你……這樣研發就成了被動接工單的角色，如何規避風險避免擔責任是他們要考慮的首要問題。

這過程中各種扯皮推卸互撕都有可能出現，程度輕重取決於工程大小和工期長短。如果遇到在公司裡地位相對強硬的研發，還可能出現專案進度推遲甚至根本無法推進的情況。姑且不論責任究竟出在哪一方，寶貴的時間就這麼耗過去了，錯過了多少好業務。最後誰獲利了？都沒有啊。

第三、掌握溝通技巧，研發最怕頻繁打擾

運營的工作廣泛而又瑣碎，很多時候要求「多執行緒任務並行」，經常要和各種使用者打交道，因此運營的思維是比較發散的，需要具備相當的靈活性，這是運營工作的特點決定的。

研發則是邏輯性非常強的工作，要求考慮完整週密，天天跟機器打交道，非 1 即 0，非正即負，沒有模糊的中間狀態可言。

寫程式碼按照一定的邏輯順序來，據說有人寫程式碼激情迸發，寫到 high 了物我兩忘，完全沉浸在程式碼的世界裡也是有的。

如果，隔個幾分鐘就打擾他一下，改個這裡，修個那裡，問個問題……研發的思路就中斷了，這些單執行緒的同學們多半會抓狂。

所以我們必須利用工具來管理需求。把所有產生的需求統一放到專案管理工具中，如 JIRA 就是一種很常用的工具，彙總一批需求定期（這個時間間隔可以和研發事先溝通好，比如每週一次）和研發溝通，確定優先順序和排期。

如果是緊急的需求，或者重大的 bug 出現（比如使用者無法登入了），這種可以隨時找研發處理，但是儘量不要零敲碎打地報需求，尤其是不要用即時溝通的方式，比如 qq，電話給研發報需求，容易遺漏，不好統計和反饋，而且也給研發造成打擾。

第四、最好懂點技術，方便跟研發溝通

看到這裡你可能會說：運營要懂技術還要研發幹什麼？這個當然不一樣。

這裡指的懂技術不是說運營要會親手寫程式碼，而是說對技術的一些基本概念，名詞，表現形式和行業趨勢有點了解是很有好處的。

研發是專業性較強的工作，在和研發溝通產品需求和進度的時候，多少要涉及一些技術相關的問題，如果遇到善於溝通又懂些業務的研發，他能儘量用非技術人員能夠理解的方式跟你溝通，但這類人真心不多，能做到的基本都是技術管理層了。有些人還有一種研發範兒的傲嬌，哎你們運營連這都不懂……

從我個人經驗看來，如果有產品人員在，那麼運營基本不用懂技術，只要把業務需求跟產品理清楚，就讓產品去跟研發溝通好了；但是在缺乏產品資源，或者要直接和研發合作的場景，以及運營做到一定年限和職位的時候，懂一些技術的運營跟研發溝通會更有優勢。

表現在溝通更加順暢，省去了很多專業方面的鋪墊，提需求時能夠從研發角度進行一定的考慮，研發提出的方案和排期，心裡基本也能有數，效率提高很多。

現在各種學習程式設計的資源非常豐富，我個人覺得運營學習一些程式設計知識，對思維的鍛鍊，產品的瞭解，視野的提升都有益。

第五、發掘共同利益，大家好才是真的好

說到底，運營的目標是要最大化產品的價值。這中間無論運用何種手段，只要合理合法不違反公司規定都是沒問題的。

但如果總想著利用別人，佔點便宜，也許一時可以，長久都是不奏效的。

最好的方式：是讓參與的人有共同的利益，這事成了，大家都獲利，而不只是單純的部門之間工作配合或者幫忙而已。

一方面，需要從組織結構上理順，為一個產品線配備齊全人員的產品事業部制，就比按職能劃分按任務派活的大部門制更能激發員工對產品的責任感和積極性；

另一方面，要捨得分享，賞罰分明，產品做得好了，大家都有功勞，該分錢分錢，該團建團建。大家都知道跟你做事不吃虧，時間長了，靠譜的人會願意持續跟你配合，你的口碑和職場信譽也就建立起來了。

運營眼中的靠譜研發是什麼樣的？

技術好，還用多說麼。。。

還懂點業務，理解需求快，而且能結合需求完善更好的解決方案；

好溝通，能換位思考，我曾經合作過的一位研發 leader，需求完美解決不說，還會自己主動琢磨「怎麼把這個後臺做得讓你們運營好用一些」，好感度提升一萬點啊！

最後，顏值還高……這算附加值了，能把自己打理得乾淨整潔精神煥發的研發更是稀少，遇上請務必珍惜。

以上我從運營角度談了如何與研發建立良好合作的五點經驗總結。

如果你合作的都是靠譜研發那自然好，大多數人沒那麼幸運，就只能從自身出發，把自己本職範圍內的事都做到位，要求對方靠譜，自己一定要先儘量靠譜吧，然後儘量能換位思考理解合作伙伴，幫對方著想一下。

大家都是一起工作的，沒有誰天生就和誰是對頭，尤其在現在工作壓力大的時代，每天和同事相處的時間比和家人都多，如果各個職能的小夥伴都能合作愉快，建立統一戰線為實現共同目標高效地工作，那真是個清平安樂的美好人間。