起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識運營避免和產品撕逼的8個技巧
都說產品是親媽，運營是奶媽/養母，一個生一個養，但都把孩子當作自己的，自然免不了常有撕逼發生。
在公司經常會出現這樣的場景：
場景1：
運營對著產品說，為什么別人能做我們不能做，我們就是要做。產品說，和你解釋不清，不能做就是不能做。運營哭著說，這屆產品和開發不給力。
場景2：
運營對產品說，這個需求領導說要改成這樣。產品說，怎么又要改？運營說，領導就是這么要求的。產品蔑視說，這屆運營真笨蛋，一點都不專業，需求變來變去。
場景3：
運營對產品說，我剛寫了個運營需求給你，你今天和開發說明天活動要用這個功能，讓他們趕緊開發。產品說，時間不夠不可能。運營說，都說好明天上線了，加班加點完成吧。產品和開發邊加班邊說，這孫子是想折騰死我們。
場景4：
運營說，你怎么這么開發的，我需求里明明是那樣寫的。產品說，你的表述有分歧，沒有溝通清楚，現在到這個時間了你看怎么辦吧。運營吐出一口老血。
以上這些，是不是似曾相識的場景？
當然，這都還是比較和諧的場景，背后投訴后面罵人，性子火爆點的都是直接開罵直接開撕，最后視同水火，產品給運營設小門檻，運營給產品使小心機，扯皮推諉，活兒推進越來越難。
如果確實是對方人品問題，開撕自然得撕。但事實卻是：很多都是因為不了解不信任溝通不暢造成的不必要的撕逼。就和家庭教育，家長最好要保持教育觀念一致一樣，其實對于產品來說，也只有產品運營親如一家，孩子的教育才能夠做得更好，孩子也才能夠健康成長。今天就說說運營避免和產品撕逼的小技巧。
1、自己梳理先行
運營在提需求前，建議一定要先做梳理：
- 這個需求的目的是什么？
- 這個需求涉及到哪些功能？是否與已有功能相關？
- 這個需求外部（包括競爭對手）的常規做法是怎么樣的？
- 這個需求是常規性需求還是偶發性需求？是長需求（升級改版）還是短需求（功能優化）？
- 這個需求的緊急程度怎么樣？
等等，不止是做到對將要提的整個需求心中有數，而且最好進行記錄，用條理清新的文字、流程、框架將需求一一理順。
2、內部溝通先行
需求準備好了，然后就可以和產品溝通了？當然不。因為運營是一個整體的團隊，建議在需求對外前，一定要組織運營內部外議，對已經梳理清楚的流程進行內部溝通。溝通的點包括：
- 需求是否能夠滿足接下來的運營要求？
- 對緊急度、常規/偶發、長/短的判定是否存在不同意見？
- 需求是否有什么遺漏的地方？
- 對需求的各個細節，大家是不是還有不同意見和建議？
- 需求對外時可能遇到什么問題，如果遇到，我們的應對性方案是什么？最高標準是什么，最低準則又是怎樣？
內部先就整個需求達成一致性意見，將避免對外的時候需求一旦出現不同想法和差錯，要對需求進行頻繁變更。而且，內部溝通可以讓運營的需求目的性更明確，需求更完善。
3、信任是溝通的前提
當內部達成一致之后，運營就要與產品進行初步溝通了。
常常有這樣的運營，在溝通開始之前就預設了立場，覺得公司的開發人員能力不行，公司的產品邏輯不好，諸如此類。正是因為預設立場，一旦溝通一開始沒有得到認同和滿足，就覺得對方是在為難和刁難。
正因為預設了立場，在正式溝通的時候，一旦遇到了挫折，比如需求會駁回或需求時間被延長等時，就會覺得是對方的問題。
但事實上，我經常遇到的情況是，幾乎沒有一個產品和開發是不希望自己的“孩子”更好的，需求被駁回背后通常有他的客觀情況，繼續溝通通常都會有對應的解決方案，有時候從產品方給出的解決方案會比原本的更加完滿。而需求時間被延長更是常態，但最終的結果卻是沒有一個需求會要到截止時間才交付，deadline只是產品希望給自己和開發都留下更多的余地。
總之多一點信任，溝通就會順暢很多，結局也可能會好很多。
4、運營產品是協作關系，不是上下級關系
因為運營在面對產品、設計、數據分析等其他部門的時候，都是提需求的一方，所以經常會讓有些運營產生一種整個公司都是在圍著自己轉的錯覺，于是在提需求時會不自覺使用一些命令式的語氣，比如“你應該”“必須”“一定”“就是”“你別管”之類的，覺得產品都應該服從運營的需求。
但運營和產品從來就不是從屬關系，而是相輔相成的協作關系。運營更多的接觸用戶，了解需求，而產品則比用戶和運營都更加了解產品，一起碰撞，才能帶來更多火花。
職場上有些人天生就喜歡用命令式的語氣，但這種人要有足夠的氣場、能力、資歷和知識儲備來支撐，否則就是外強中干徒增笑柄。所以，如果不是實力超群，還是低調點，先學會合作再說。而且，大多數越是實力超群的人都越是沒脾氣，越是愿意和人平等交流與溝通。
5、把握原則，適當妥協
不能輕易和產品撕逼，要盡量達成意見統一的合作，是否就意味著運營要一味相讓，產品怎么說就怎么聽呢？當然不。
這就是我之前在說第二點時，為什么建議運營內部在需求對外前，一定要溝通確認需求的基本原則和基本底限。
運營需求基本原則最核心的是要以目標為導向，當產品否認運營提出的需求時，需要產品提出的替代方案，而替代方案能夠在指定時間內達到運營要求的指定目標。
在此基礎上，一些無關大局的小問題可以適當妥協，比如功能的后臺操作位置是放在哪里，原本的功能要求是以天為單位而產品要求以次為單位等等，目標是一致的，面對產品從開發的邏輯和產品的專業性角度提出的建議，不要一味堅持己見。
6、主動承擔，主動尋找替代方案
當然，并不是每一個需求，產品都能夠根據運營的目標要求找到替代方案，更多的時候是，產品有自己的一層判斷，比如覺得運營的需求因某個關鍵接口沒有開放權限完全沒有可行性，又或者開發后運營起來可能會帶來其他具大風險，又或者評估的結果是開發周期、投入成本與實際需求的產出不成正比。
面對這些情況下，運營需要做出分析，主動承擔起一些對外溝通，風險運維管理等的活，甚至一些產品流程梳理的活，運營不妨多多承擔，既是自己學習的一個過程，也能夠讓產品看到你的誠意，進而再重新評估，與主動幫忙考慮替代方案。
當然，實在是不靠譜的需求，就不要一味死撐，大家一起重新來尋找一個新的替代方案，或者比死嗑在原來的想法上更為有效。
7、反復溝通，多點耐心，細節是王道
一般產品根據運營的需求，準備好開發需求文檔、功能原型圖、邏輯流程圖等后，都會再次和運營進行確認是否與運營需求一致。
這時候就不要再做好好先生，而一定要做個“找茬王”，仔細的關注這里面的每一個細節，從專業的角度 、用戶的角度、后臺操作的角度等等方方面面來確定規劃與需求是否一致，在這個環節里面，多點細心、多點耐心是運營必須要有的態度。
產品接需求了，同時產品也給予了反饋，接下來要做的就是圓滿的完成整個需求項目。所以，不明確的地方，一定要仔細詢問；不清晰的地方，一定要理順；有不妥當的地方，一定要溝通更好的解決方案，盡量將細節做到極致。
說到細節，我想說一些題外話，產品經理的素養可能讓他們也會從用戶的角度去設計功能按鈕，但是最了解用戶的畢竟是運營，所以請一定要和產品一樣培養一顆以用戶為中心的素養，有時候，從用戶角度考慮一些頁面停留時間、返回頁面、按鈕設計、跳轉設計等等，都能夠增加用戶對平臺的好感度，有效的提升轉化率。
8、跟蹤常態化，隨時了解進度
需求確認，產品將需求提至技術開發以后，是不是就萬事大吉，只要坐等在需求截止時間產品的反饋了？我的個人建議是千萬不要這樣。
需求進入開發階段，產品會定期跟蹤，而運營也最好實現跟蹤的常態化，清楚在開發過程中遇到的問題，清楚開發的進度，清楚各個技術難點等等。
這樣的好處，一是可以在內部溝通時有相應的反饋；二是如果運營項目有其他新的需求時，能夠保證心中可以對緊急度、可執行性等有更好的評估；三是經常跟蹤需求的完成情況后，運營會越來越熟悉各類型的功能開發大致的開發時間、測試時間等等，有助于以后提需求時，給產品和開發預留更加精準的完成時間。
以上8點，總結起來就是多從自身找原因，多為目標想方法，多學多做多思考。希望我們都能夠做一個有原則但絕不輕易撕逼的運營。
作者：奔跑的大橘子（簡書ID：奔跑的大橘子）：華中科技大學碩士，畢業6年，先后在4A廣告公司、OTA、管理咨詢公司從事運營相關工作。
本文由 @奔跑的大橘子 原創發布于人人都是產品經理。未經許可，禁止轉載。
“一般產品根據運營的需求，準備好開發需求文檔、功能原型圖、邏輯流程圖”
??產品運營一般除了功能原型圖，其他都輸出完了…產品運營和產品的工作內容你覺得會不會有相當重合的地方？
感謝作者，文章寫的接地氣，學習了。
我遇到的情況，運營和產品最大的撕逼點總后歸納總是出現在時間上，運營未給產品和開發留下足夠的時間，最常見的場景是，我就只需要這一點小功能，隨便加加班就能出來了，我趕著要，那么對產品來說最大的悲劇就是，太多時間花在確定需求，設計上，開發測試就來不及，拿到需求直接粗暴設計，漏洞率增加除外，還有可能出現重大需求偏離，加了班，出不好活，你讓產品以后怎么干活
是的，運營如果不能夠多站在產品的角度考慮問題的話，最后出現問題還是要大家一起承擔的。而且運營前期把需求盡早明確清楚還蠻重要的。