分析：產品運營如何與研發建立良好的合作關系

運營和研發建立良好合作的重要性：通常一個互聯網項目團隊包括如下幾個職能的人員(排名不分先后，且根據具體情況和不同時期人員配置會有增減)：產品、設計、研發、測試、運維、運營、市場、商務，其中的產品主要起到業務需求方(運營/市場/商務)和技術研發之間的橋梁紐帶的作用，那么運營作為典型的業務需求方，只要把需求跟產品溝通清楚就好了，為什么還要和研發建立良好的合作呢？第一、很多時候，運營要承擔一部分產品的工作，必須和研發打交道產品都是有生命周期的，一般來說，產品從無到有的孵化階段是以產品人員和研發人員為主導，確保產品按需完成，如期上線；當產品上線后進入相對穩定的上升發展期時，運營逐漸成為主導角色，收集提煉出大量來自用戶的，和運營過程中調研挖掘的產品需求，推動產品不斷迭代優化。而且很多公司里，產品和研發資源并不是完全從屬于某一個產品線，這個產品上線穩定一段時間后，可能就會調去參與其它項目，不會有很多精力能夠投入該產品的持續優化了。這個時候運營就必須責無旁貸地承擔起一部分產品的工作，要和研發同學直接打交道。第二、運營是最終擔業績的人，但無法獨立完成業績，需要其它職能的配合在幾乎所有的互聯網產品中，運營都是最終承擔KPI的人，而且運營的工作相對容易量化，可以各種數據指標的變化來衡量。但互聯網產品數據的提升，是不能僅靠運營單方面來達成的，一定是各個職能多方面通力合作的結果：產品界面不友好，運營拉來用戶也留不住；系統性能不穩定，經常閃退或者報錯，運營每天處理用戶吐槽和救火就疲于奔命了，哪里還有精力去完成業績。可是往往運營又并不具備能夠充分調動產品和研發資源的權限，如果自己團隊有配備專屬的產品研發還好，否則只能是多方面尋求資源協作，能否與研發建立良好的合作關系就尤為重要了。三、靠譜的研發能避免很多不必要的資源浪費見識過不靠譜的研發，你就知道能有靠譜的研發是多么幸福的事情。靠譜的研發，不會拍著胸脯說這東西簡單得很兩天就上線，但是一旦承諾了排期就不會拖延；靠譜的研發，會保證產品開發質量，提交測試基本就是沒有bug；靠譜的研發，不會想方設法推卸責任，很多拖了很久懸而未決的問題，到他手里研究一番就可以得到完美的解決；靠譜的研發，能結合運營的需求，做出方便又好用的后臺，大大提升運營工作效率；跟靠譜研發合作，運營不需要無休止地重復測試，提交bug；不需要沒完沒了地開需求溝通會，天天追著問進度；不需要擔心某個需求無法實現，從而無法開展新業務。你說如果你是運營，是不是一定要努力找出那些靠譜的研發小伙伴組隊啊？運營如何和研發建立良好的合作：第一、謹慎處理需求，不要讓研發白做工通常技術都是業務的支持部門，技術要為業務服務，運營會結合業務發展不斷提出需求改進產品是很正常的，但提需求絕不是隨意的和漫無邊際的。一定是：經過充分的論證調研——現有產品確實無法滿足業務發展——研發成本不會超出現有資源范圍——才靠譜。心血來潮、拍腦袋就上、不顧實際資源情況就開干的項目多半最后都是慘淡收場，參與人員付出的時間和精力也就白搭了。研發最怕什么？最怕辛辛苦苦加班加點做出來的產品，最后沒人用啊！等于研發這段工作的價值沒有得到承認。你如果說我不在乎，反正做什么不是做，每周都要寫工作周報哦，我是研發只管實現你的需求就好了，做完了有沒有用那是你們業務部門的事情跟我沒關系。這樣想的研發也就是混日子的心態，最后業務沒發展、公司沒發展難道研發日子就會好過嗎？真的有想法有上進心的研發絕不會這樣想的，一定是希望自己開發的產品真的能夠得到實際的應用，對公司的業務能夠起到很好的支撐，進而自己的價值也得到了體現。我曾經親眼見過真實的案例：業務方迫切地要做一個新產品，理由是舊有的產品不適應客戶的需求了，必須要有新的產品來承載客戶需求的變化，而且給出了要實現的時間點(還比較緊迫)。當時技術部門派出了最精英的程序員來負責這個產品的開發，產品如期做完了，結果業務方的反饋是：這不是他們要的東西……后來我自己負責的項目運營中應用過該產品，覺得還是比較好用的，為什么業務方會否定它我個人不得而知，也許公司戰略、需求變更、客戶變化種種都是可能的原因，但最后的結果是這個程序員被這個項目傷了心，不久離職了。還有更極端的案例：業務方把業務未完成的原因歸結于產品研發不給力，不能對客戶的需求做到7*24小時響應，百分百解決，客戶投訴也讓研發來背鍋，也許研發可能是存在一些問題，但是這樣的合作方式只能是雙輸，業務完成了嗎？也并沒有。所以說運營在處理需求時是一定要謹慎的，關于如何提煉產品需求，我以后會專門發文陳述我的觀點。第二、充分說明需求，調動研發的積極性上文說過，靠譜的研發，有想法有上進心的研發，一定不是機械地只管接活干活的人。他們對業務也有自己的理解和想法，有時甚至能從別的角度給出更好的解決方案，前提是要讓他們充分了解這個需求的來龍去脈，這個需求的背景，不僅僅是知道我們要做什么事，更重要的是我們為什么要做這個事：現在的這個產品需求是我運營經過調研分析確定的，我的解釋是否能讓你足夠清楚明白了？然后從研發的角度，請你看看是不是有其他的隱藏問題？你有沒有更好的解決方案？我們一起再探討。最后達成共識確定的需求，并不是運營單方面‘壓下來’的需求，而是經過業務方和研發討論后共同認可的需求，研發也充分認識到了這個需求的價值和意義，你說他不會積極主動地完成嗎？一定會的。而且事先雙方確認了需求和排期，后期的責任也非常明確，即使又有了臨時緊急的需求變更(有時不可避免)，也會更容易溝通。相反，如果運營只是說我要做某個東西，告訴研發我要這樣這樣實現，你不要管為什么總之你必須給我做了，還得在指定時間點完成，否則到時影響業績責任在你……這樣研發就成了被動接工單的角色，如何規避風險避免擔責任是他們要考慮的首要問題。這過程中各種扯皮推卸互撕都有可能出現，程度輕重取決于工程大小和工期長短。如果遇到在公司里地位相對強硬的研發，還可能出現項目進度推遲甚至根本無法推進的情況。姑且不論責任究竟出在哪一方，寶貴的時間就這么耗過去了，錯過了多少好業務。最后誰獲利了？都沒有啊。第三、掌握溝通技巧，研發最怕頻繁打擾運營的工作廣泛而又瑣碎，很多時候要求‘多線程任務并行’，經常要和各種用戶打交道，因此運營的思維是比較發散的，需要具備相當的靈活性，這是運營工作的特點決定的。研發則是邏輯性非常強的工作，要求考慮完整周密，天天跟機器打交道，非1即0，非正即負，沒有模糊的中間狀態可言。寫代碼按照一定的邏輯順序來，據說有人寫代碼激情迸發，寫到high了物我兩忘，完全沉浸在代碼的世界里也是有的。如果，隔個幾分鐘就打擾他一下，改個這里，修個那里，問個問題……研發的思路就中斷了，這些單線程的同學們多半會抓狂。所以我們必須利用工具來管理需求。把所有產生的需求統一放到項目管理工具中，如JIRA就是一種很常用的工具，匯總一批需求定期(這個時間間隔可以和研發事先溝通好，比如每周一次)和研發溝通，確定優先級和排期。如果是緊急的需求，或者重大的bug出現(比如用戶無法登錄了)，這種可以隨時找研發處理，但是盡量不要零敲碎打地報需求，尤其是不要用即時溝通的方式，比如qq，電話給研發報需求，容易遺漏，不好統計和反饋，而且也給研發造成打擾。第四、最好懂點技術，方便跟研發溝通看到這里你可能會說：運營要懂技術還要研發干什么？這個當然不一樣。這里指的懂技術不是說運營要會親手寫代碼，而是說對技術的一些基本概念，名詞，表現形式和行業趨勢有點了解是很有好處的。研發是專業性較強的工作，在和研發溝通產品需求和進度的時候，多少要涉及一些技術相關的問題，如果遇到善于溝通又懂些業務的研發，他能盡量用非技術人員能夠理解的方式跟你溝通，但這類人真心不多，能做到的基本都是技術管理層了。有些人還有一種研發范兒的傲嬌，哎你們運營連這都不懂……從我個人經驗看來，如果有產品人員在，那么運營基本不用懂技術，只要把業務需求跟產品理清楚，就讓產品去跟研發溝通好了；但是在缺乏產品資源，或者要直接和研發合作的場景，以及運營做到一定年限和職位的時候，懂一些技術的運營跟研發溝通會更有優勢。表現在溝通更加順暢，省去了很多專業方面的鋪墊，提需求時能夠從研發角度進行一定的考慮，研發提出的方案和排期，心里基本也能有數，效率提高很多。現在各種學習編程的資源非常豐富，我個人覺得運營學習一些編程知識，對思維的鍛煉，產品的了解，視野的提升都有益。第五、發掘共同利益，大家好才是真的好說到底，運營的目標是要最大化產品的價值。這中間無論運用何種手段，只要合理合法不違反公司規定都是沒問題的。但如果總想著利用別人，占點便宜，也許一時可以，長久都是不奏效的。最好的方式：是讓參與的人有共同的利益，這事成了，大家都獲利，而不只是單純的部門之間工作配合或者幫忙而已。一方面，需要從組織結構上理順，為一個產品線配備齊全人員的產品事業部制，就比按職能劃分按任務派活的大部門制更能激發員工對產品的責任感和積極性；另一方面，要舍得分享，賞罰分明，產品做得好了，大家都有功勞，該分錢分錢，該團建團建。大家都知道跟你做事不吃虧，時間長了，靠譜的人會愿意持續跟你配合，你的口碑和職場信譽也就建立起來了。運營眼中的靠譜研發是什么樣的？技術好，還用多說么。。。還懂點業務，理解需求快，而且能結合需求完善更好的解決方案；好溝通，能換位思考，我曾經合作過的一位研發leader，需求完美解決不說，還會自己主動琢磨‘怎么把這個后臺做得讓你們運營好用一些’，好感度提升一萬點啊！最后，顏值還高……這算附加值了，能把自己打理得干凈整潔精神煥發的研發更是稀少，遇上請務必珍惜。以上我從運營角度談了如何與研發建立良好合作的五點經驗總結。如果你合