風控做不好，遊戲毀於一旦

如果有人問我，什麼是一個遊戲運營最基本，最重要，但是又最難做好的部分，那我的答案一定是【風險控制】。眾所周知，在大多數情況下，遊戲運營是很難提升一個專案的上限的；相反，遊戲運營在很多時候都是一個專案的軟肋。我們很少看到一個遊戲因為運營得優秀而成功，但可以看到有很多遊戲因為運營沒做好而爆炸，成為同行和玩家的笑柄。


我知道很多玩家一出問題可能就在罵“狗策劃”，但是我還是想為策劃正名一下，很多遊戲事故其實都應該是遊戲運營背鍋。而面對遊戲事故，處理遊戲事故，甚至是預防遊戲事故，本身就應該是運營的重要工作。

但可能現在行業內的風氣是，運營的工作重心都放在了專案資料和市場上了。並不是說關注資料、活動、市場的運營就不對，我只是想說那些都是一個運營的上限，而真正一個運營的下限其實是風控運營。

我所見過的大多數遊戲運營，也包括我自己在內，都是缺少風控思維的。都是揹負著流水壓力，在繁重的、雜亂的工作中，做一些我認為的【高危操作】。當專案使用者體量小，或者是運氣好的時候，這些高危操作的問題可能暴露不出。一旦運營在沒有風控運營的能力時，接手了一個重大專案，那麼這個專案也會因為這個運營個人而承擔極大的風險。


運營的第一原則應該是風控

如果不想運營成為一個專案的軟肋，那麼運營應該在處理任何對玩家有影響的事情的時候，都保持風險意識。

專案的每個問題，都會因為使用者體量的放大而指數放大的，有可能運營在做小專案的時候，遇到小問題，沒有關注，敷衍解決，一路走過來，直到接手大專案，在原本就遇到過的小問題上栽個大跟頭。同樣的運營事故，放日活3K的遊戲裡，可能都沒有玩家感知到，放日活300W的遊戲裡，可能直接導致整個專案涼涼。

產品調整風險

產品調整的目的是為了讓遊戲與玩家、市場、以及現階段的運營策略更貼合，但是產品調整的放出，本身也是會帶來運營風險的。其中包括了：角色/系統的重做或改版，遊戲數值的調整，商業化的調整，這裡簡單舉例。


為了更好的描述產品調整具體會帶來多大的麻煩，下面我會用我自己的真實經歷說明

案例

在大多數遊戲中，都有一個戰鬥力系統，把玩家當前的實力資料化，提供一個具象的實力參考標準


有時這個戰力數值還會與PVP玩法關聯，這些PVP玩法也通常是後端通過定時器自動傳送結算獎勵的


這裡要先簡單說明一下，統計玩家戰力的設計思路：通常是，當玩家進行升級、換高階裝備這種行為的時候，後端會執行一次重新算戰鬥力的方法，如果算出的戰鬥力大於資料庫裡玩家的【最大戰力】，那麼這個新算出的結果就會被更新記錄到資料庫中。


你一定注意到了，這個程式的整套邏輯，都是基於【最大戰力】這個關鍵數值，而這個數值又是一個通過計算獲得的結果，不是遊戲內的自然數值。

然而，隨著遊戲的版本迭代，最初的戰力演算法已經不再適合於當前的遊戲版本了。也就是說，按照老版本的戰力演算法，已經無法正確描述新版本的玩家實力了，這個系統成了擺設不說，還有可能對玩家產生誤導。同時關聯的PVP玩法，也會因為戰力不準，引發大量的玩家投訴。

這個時候，系統或者數值策劃會出一個【重算戰力】的方案，讓後端去改寫戰力演算法，從而使戰鬥力描述能夠更符合當前的版本。

你可能會產生疑問了，這裡哪裡有風險點，改戰力演算法就改戰力演算法咯，哪裡有運營需要關注的地方?

首先，大多數開發是不瞭解業務的，也是沒有玩家思維的，很多時候策劃案過了，他們按照要求去寫就完事了，是不會意識到戰力調整對遊戲的影響的。

而此時，如果策劃與運營都只看到了：戰力演算法不合適了需要調整，這一個表面問題。而沒有去考慮新的演算法是會導致玩家的戰力整體【上升】，還是整體【下降】的問題，再結合我上面介紹的，只有當重算的戰力大於資料庫裡記錄的數值時，玩家的最大戰力才會更新，那麼更新後的場景我們可以設想一下：

• 策劃寫的新演算法會導致所有玩家的戰鬥力整體上升，更新後，戰力計算更準確了，玩家、策劃、運營、開發皆大歡喜
• 策劃寫的新演算法會導致所有玩家的戰鬥力整體下降，運營、策劃都沒想到要先讓開發停服，用新演算法，重算所有玩家戰力，並寫庫後再對外。更新後，所有玩家升級、買裝備都不提升戰力，pvp玩法沒進度，最後玩家炸了，社群炸了，客服炸了，一路炸到策劃和運營這來，最後又是緊急停服，開發趕緊寫指令碼，一個個給玩家重算戰力補救
• 策劃寫的新演算法會導致部分玩家的戰鬥力下降，部分玩家的戰鬥力提升。開服後，部分玩家升級買裝備有戰力提升，pvp有進度，甚至已經領了獎勵。而部分玩家死活沒進度，戰力也不動。
  

我曾經遇到的就是第三種情況，可以說是最壞的一種，並且那部分沒有進度的，恰好是遊戲中最核心的那一批大R，最後由於距離更新的時間已經太久，只能玩家找過來一個個再給他修改補償。可以說如果情況3出現，已經算是重大運營事故了，如果是體量大的專案，又會是一場輿論風波。

其實這個問題要解決很簡單，只要在業務流程上規定：如果有涉及到玩家數值的調整，都一律先停服修改完所有玩家的資料後，再對外開服。這個問題看起來好像是策劃在執行的時候沒有考慮周全，實際上策劃通常是一個不用去面對運營一線的職位，有時候可能真的考慮不到，如果這個時候運營和策劃有充分溝通過了，同時運營也具備風控思維的情況下，事故本該是可以被規避的。

因此我認為，大多數運營事故在上線前是可以被運營攔下來的，專案出現運營事故，無論是不是運營引起的，運營都應當並且有責任關注問題的原因，找到規避的方法

總結

誠然，要掌握把控產品風險的能力，需要運營本身有豐富的經驗，並且對業務線上的每一環節都相當熟悉。但更重要的是，運營是否擁有對每次遇到的運營事故都追根溯源的精神，這些運營事故甚至可以不來自於自己的專案，可以是競品的，是你玩的遊戲裡的，是你從哪裡聽說某某遊戲的某某調整又炸了的……總而言之，產品風險問題，最好的解決思路就是關注。運營不關注，不排查，風險就永遠在那裡，等待一個合適的時間爆發。