系統策劃，不能只當實現需求的“工具人”

系統策劃，是國內遊戲公司最為常見的策劃崗位之一。同時，這又是一個經常被數值、美術、程式、UI吐槽的崗位：工作只挖坑，不填坑；寫的策劃文件看不懂，需求也說不明白；製作人、主策說什麼就是什麼，像個“工具人”......

所以，系統策劃的核心價值究竟在哪？一份合格的策劃文件應該是什麼樣的？近日，由騰訊遊戲學院製作的《論道》欄目便邀請到了騰訊互娛光子工作室群《和平精英》專案組的系統主策劃Jesse老師，和他聊了聊系統策劃的工作方法論。


你可以通過下方與Jesse老師的對話視訊，或者後面的採訪文字摘錄，瞭解這次的分享內容：


系統策劃的主要工作是什麼

Q：請問您怎麼定義系統策劃？很多人說不清楚系統策劃具體是做什麼的。

Jesse：回答這個問題之前，先得搞清楚遊戲的系統是什麼。

在我看來，在遊戲裡，除了具體玩法（如《和平精英》的經典模式）以外的所有內容，都能稱為系統，比如任務系統、數值系統、強化系統等。如果策劃這段時間的核心工作偏向於系統設計，就可以稱他/她為系統策劃。

Q：玩法和系統要怎麼區分？

Jesse：玩法最直觀的特點是能提供體驗、產生反饋。如果用現實世界類比，遊戲的核心玩法相當於一座城市的特色景點，比如遊樂場；系統就好比是道路、停車場、環衛設施等公共設施。

如果景點特別好玩，玩家就算路上堵車、停車位不好找，可能排排隊就忍了；如果景點不好玩，就算道路再通暢、周邊環境再好，玩家可能也不會去。

但這並不意味著系統沒用。系統就像一個放大器：如果兩個景點吸引力差不多，哪邊的道路更通暢、更好停車，玩家就會更傾向於選擇哪邊。同時，足夠好的景點也需要配套足夠好的交通、停車場等等，才能讓更多的人都能無障礙地到達。

Q：那具體一點來看，系統策劃的主要工作是什麼？

Jesse：系統策劃最主要的工作，就是根據當前階段的版本目標，分析所需的系統功能，決策這些系統需要達到什麼程度，把它設計出來、落實，並持續維護。

Q：「決策系統需要達到什麼程度」是什麼意思？

Jesse：假如一款多人對戰遊戲的組隊系統，在研發的不同階段分別要做多深？在原型階段可能只需要保證玩家能正常組隊、退出，而後面鋪量的時候，組隊系統就要做得比較完善了，比如增加邀請、踢人等功能。


Q：在此過程中，系統策劃和製作人、主策劃要怎麼溝通？

Jesse：首先你要了解制作人或主策劃對系統的設計定位和目標，核心體驗大概是什麼樣的；其次，你還要問清楚他們期望玩家在系統中獲得什麼樣的體驗。

Q：具體要怎麼溝通？

Jesse：比如你打算設計一個裝備強化系統，至少要問主策劃這些問題：

這個裝備強化系統針對哪些使用者群體？設計這個裝備強化系統的目的是提高活躍還是收入？你對於玩家投入到強化系統的時間、精力成本，預期是什麼樣的？以及這個裝備強化系統的輻射面——就是這個系統和其他系統、玩法的關聯性。完全自產自銷的系統，輻射面就是0。

Q：那玩家獲得的體驗和好處要怎麼設計？

Jesse：這涉及到體驗迴圈。裝備強化系統通常有這些設計思路：第一種強化失敗之後，裝備直接報廢；第二種設定保底機制；第三種是隻升不減，通過概率控制，現在很多手遊都這麼做；第四種讓玩家提升裝備格子的等級，而不是裝備，這種方式目前應用也很多。不同設計方式產生的玩家體驗不同。

此外，你還得考慮這個系統在遊戲中的目標定位。

Q：怎麼理解？

Jesse：不同系統之間存在耦合關係。舉個例子，在設計聊天系統時，你要了解玩家群體的特徵，哪些人會聊天？在什麼場景下聊天？聊天時用什麼工具？喜歡發什麼符號、表情？最重要的是，核心玩法對聊天的訴求是什麼樣的？這樣你才能按需設計它。

比如國戰SLG可能傾向於通過聊天系統幫助軍團統一目標和策略，分享進展；而傳統RPG特別注重社交生態，我們要把聊天系統的形式做得更有趣，方便玩家持續對話。

另外要時刻提醒自己，這個系統應該具備的作用是什麼，現在的設計是否足夠有效。不能想當然地說「我覺得做個點贊功能挺好」，而是要思考，點贊對於解決問題是否真的有幫助？要不要做進一步的閉環設計？

Q：溝通完之後，系統策劃接下來會重點做哪些工作？

Jesse：接下來根據目標拆解功能點，梳理框架，把設計難點都解決掉，必要時藉助資料和調研來論證設計。

Q：能舉個例子嗎？

Jesse：比如負責人告訴我，他要一個玩家體驗比較好的強化系統。那什麼叫做好的使用者體驗？要不要做保底？要不要做階段性提升？要不要做裝備替換？這些在前期都要考慮好。

如果實在想不清楚，你可以去觀察同型別的優秀產品怎麼做玩家體驗，然後結合使用者調研，確定設計方案，然後再去整理細節，包括UI互動樣式、美術效果、伺服器、客戶端要實現的功能等等。

這還沒完，你還要整理系統的風險點，提前規劃好資料埋點和分析方案。


Q：風險點？

Jesse：系統上線之後，萬一出現錯誤，你有沒有規避措施？

舉個最極端的例子，假如裝備強化系統上線後，突然發現有個程式漏洞，你能不能立刻把系統關掉？或者能不能在保證主體邏輯正常運營的情況下，關掉有問題的模組？這都需要你提前評估風險點。

Q：這些風險點要怎麼找？

Jesse：你可以考慮極端情況，設計通用的應急措施，比如這個功能有四個模組，我可以為這四個模組各做一個開關，出現問題立刻關閉相應的模組，再進行後續的處理應對。在此過程中，最重要的是要有整理風險點的意識。

Q：那如果系統順利上線了，系統策劃接下來的工作重點是什麼？

Jesse：資料分析。比如系統上線後，玩家參與率不達標，或者沒有達到預期目的，都得通過資料回頭找問題。同時，你可能會根據遊戲的功能、玩法變化，對系統做出一些調整。


怎麼寫文件並推動其落地？

Q：接下來想聊聊策劃文件，你覺得什麼樣的文件算合格？

Jesse：按照我的標準，一份合格的文件必須要把玩家體驗、系統規則、互動規則都說清楚，尤其是異常狀況處理方案。只關注功能本身，不考慮邊界條件的文件肯定不合格。

Q：什麼是邊界條件？

Jesse：以好友系統為例，如果使用者用連點器每秒點100下「新增好友」按鈕，很可能就會出問題對吧？你可能得讓這個按鈕有1-2秒的CD。再比如玩家新增好友時往往會順帶傳送一句留言，有些遊戲會允許玩家自定義留言內容，如果有玩家利用留言辱罵他人怎麼辦？這都屬於邊界條件和異常情況處理需要考慮到的點。

你提前考慮到的細節越多，對異常狀況處理得越全面，說明你對策劃案的思考越充分，這是合格和優秀文件之間的最大差別。然後如果能提供參考物件，並說明參考物件和實際設計的異同，有加分。

而且在我看來，合格的策劃文件一定要有變更歷史記錄，這有利於系統的後續維護。

Q：這是大的原則，細節方面呢？

Jesse：細節都大同小異。文件要寫清楚設計背景、設計目的和預期結果，不涉及功能的體驗概述，然後就是系統設計詳情以及對應的UI、美術、數值等等需求，這裡特別容易忽略引導需求。

此外，宣傳方案、容災方案都可以附加在文件裡。

Q：什麼是引導需求？

Jesse：舉個最簡單的例子，系統上線的時候要不要加個小紅點？如果系統特別複雜，要不要設計教程？

Q：明白了。那後續推動系統落地的過程中，系統策劃要注意什麼？

Jesse：要認識到你不是任務釋出者，而要抱以合作的態度讓大家理解為什麼設計這個功能？想實現什麼目標？然後大家一起合作解決問題，提出優化方案。

Q：如果方案遭到質疑，產生矛盾了該怎麼辦？

Jesse：這時一定要冷靜。你首先要考慮，矛盾產生的原因是什麼？是功能設計本身有問題？排期趕不上？工具不支援？還是成本太高？換位思考，尋找最優解。

第二，你要對自己的訴求要有清晰的認識，哪些系統設計可以妥協，妥協到什麼程度？哪些不能妥協？有沒有替代方案？不要一根筋懟下去。

第三，你需要適當瞭解其他崗位的基礎知識，特別是跟美術和UI互動溝通時，不要說「我覺得這樣不好看」，因為這是在質疑對方的職業技能。如果你懂一些專業術語，能用行話說出你的意見，他們其實都願意和你交流下去。

Q：系統的最終效果和時間節點要怎麼把握？

Jesse：每個專案組都會有相應的工作流程，你按照流程制定好時間計劃，保持頻繁的溝通和驗收。這沒有什麼技巧，不要偷懶，到點就按時驗收。


系統策劃如何避免成為“工具人”？

Q：最後聊聊職業發展相關的話題。你們一般會怎麼招系統策劃？

Jesse：不同面試官注重的點可能不一樣，邏輯思維能力、表達能力、遊戲經歷大家應該都會看，也會重點關注候選人的專案經歷，以及他/她在專案中的沉澱和總結，這些總結一定要是由他/她思考並親自設計的內容，而不只是參與過的專案。

此外，我會關注面試者應對挑戰時的反應。比如面試過程中，我突然對你的觀點提出反駁，觀察你的應對策略。策劃天天要應對各種各樣的挑戰，有的來源於老闆，有的來源於美術，有的來源於程式.....

Q：我看到有些招聘會要求，「完整參與過若干款已上線的產品」，為什麼要強調已上線？

Jesse：遊戲策劃不像程式和美術，他工作的價值往往只能通過產品的價值體現。而只有經過市場驗證的產品才能證明，你設計出來的系統真實的效果如何。

Q：很多公司招資深系統策劃時，會要求他對某個品類的系統有深入瞭解，怎樣才算深入瞭解？

Jesse：這沒有特定的標準，從我個人角度看，深入瞭解分為幾個方面：

第一，你要了解產品背景，每個系統的誕生都脫離不了它的背景。你去反拆系統設計的時候，不能只關注這個系統的亮點在哪，你要知道它基於什麼情況上線，才能理解這個系統為什麼會做成現在這樣。

第二，你要知道為什麼系統會做成這樣，它在做的過程中可能考慮了哪些環節，最終產生的作用是怎麼樣的？這個系統對遊戲產生了什麼影響？

第三，你要尋找這個系統的相關係統和相關玩法，梳理它們是怎麼互相影響的。

第四，你還要判斷，這個系統有沒有優化空間？假如你是負責人，要進一步優化這個系統，應該怎麼做？

綜合來說，一定要理解系統的設計背景、設計過程、結果和相關性，這才能叫深入。

Q：系統策劃工作的時候一般會用到哪些工具軟體？

Jesse：通常Office就夠了。然後如果專案用UE4、U3D或者Cocos等工具，策劃至少要具備相關引擎的應用能力，然後還會用一些專案管理工具，每個專案組都不太一樣。


Q：您覺得一個合格的系統策劃的標準是什麼？

Jesse：首先得具有策劃的通用設計能力。在此基礎上，一個合格的系統策劃必須要知道，如何驗證自己設計的東西是好是壞。

他/她要學會有始有終，而終就落在有沒有能力驗證自己設計的系統是否符合預期。如果只會做起始，不會做終結，就無法真正成長，在我這就不算合格。

Q：我們上一期《論道》欄目和一位數值出身的主策聊過類似的話題，你覺得系統策劃的數值能力有多重要？

Jesse：一個合格的系統策劃一定要有數值解讀能力，但可能對數值設計或規劃能力要求沒有那麼高。

Q：一般製作人、主策劃會對專案做整體把控，那系統策劃如何避免成為一個......

Jesse：文件“工具人”是吧？成為工具人確實不好受。

我覺得，想要避免成為工具人，你得重視資料，把資料埋點、分析計劃用起來，幫製作人和主策劃發現問題，提出解決方案，哪怕一些思路也好，千萬千萬不能當啞巴。如果可以的話，你甚至要嘗試提出遊戲後續發展過程中要重點解決的問題，或發展方向。

Q：更主動地觀察和分析資料變化的原因？

Jesse：對。遊戲的問題一定會體現在系統資料上。以好友系統為例，假設社交生態出了問題，好友新增率和通過率一般會降低。

如果好友通過率下降了，假設我要相應優化系統，我得先知道玩家喜歡通過哪些途徑加好友，這是從量的角度分析。

有沒有可能再進一步，從質的角度去分析？比如玩家通過哪些途徑新增的好友，後續互動率更高？PvP、休閒玩法、遊戲大廳還是世界頻道？想解決問題，得整理、分析資料背後的資訊，提出解決思路和方法。

如果你想快速成長，思考過程中一定要把眼界拔高，著眼在專案層面看問題，只顧著寫文件、追進度是不行的。

Q：有什麼具體的方法嗎？

Jesse：比如你給自己定一個日常目標，每天必看哪些資料，這樣你一定能最先關注到資料的異常。然後每隔一陣子，你要留出一點思考的時間，不要讓自己太忙。天天埋頭苦幹，很難抬頭看更巨集觀的東西。

Q：最後一個問題，系統策劃是不是必須要玩遍市面上所有的熱門遊戲？

Jesse：同品類的遊戲最好都要深入瞭解。再就是借用一個比較時髦的詞，系統策劃要注意「打新」。

Q：怎麼理解「打新」？

Jesse：去玩新的遊戲。因為新的玩法體驗或對已有體驗的改善、優化經常會誕生在新產品中。這些新遊戲的設計可能不一定正確，但它有可能給你帶來啟發，這就夠了。


來源：騰訊遊戲學院
地址：https://mp.weixin.qq.com/s/hwiSqpx_EqlNrSJ0xPjraQ