2018.07.16策劃課程之策劃流程與策劃執行基礎

08-25

來自專欄實習策劃那些事22 人贊了文章

這是一節更加關注於策劃這個職位本身的課程，屬於「閃耀策劃實習」的培訓課程，講課老師是無限工作室的製作人阿松老師。

正式上課前，老師問了我們一個問題，「一個遊戲是怎麼做出來的」?

幾個同學發表了自己的意見，但老師對此都不太滿意，他更想聽到的，是大公司內「流水線」一般的遊戲製作流程，而不是我們以學生身份自己折騰、搗鼓出一個小遊戲的過程。

進入正題，這節課程分為兩大塊內容「策劃流程」和「策劃執行基礎」。

而在「策劃流程」部分，又分為了「策劃的組內分工與策劃晉陞之路」和「遊戲研發的各部門分工與遊戲研發的流程」兩塊。

①策劃的組內分工與策劃晉陞之路

對於一個剛入行的新人，做的都是大家耳熟能詳的配表工作，配的可能是各種類型的表，系統相關的表、文案相關的表。

這樣的工作可以說是沒有多大技術含量的，甚至會很枯燥，對於新人的提升幫助也不大。

但這卻可以說是一名新人策劃的必經之路，這個過程可以幫助新人策劃尋找到適合自己的職位分工，並幫助新人策劃決定自己接下來的職業專精方向及發展道路。

跨過這一步，新人級策劃接下來的工作，依舊是配表，但卻是更有針對性的配表。

依據自己的「天賦加點」，去配相關的表，點了「系統」天賦的，可能會去配一些UI表，點了「文案」天賦的，可能會去配一些任務表，或去做語言包（遊戲內的所有文字）管理。

對於新人級別的策劃，需要在一系列的配表工作中，逐步養成下述的四點特質：

嚴謹細緻：配表雖然難度不高，但卻是細緻活，需要策劃用嚴謹的態度去對待，並進行細緻的檢查工作。

邏輯清晰：這涉及到策劃做事的方法與表達的條理性，在這一階段，策劃可能在這點上並不需要有特別突出的表現，但卻要奠定好穩固的基礎。

溝通跟進到位：及時地與上頭溝通交流，保證每一項工作都能按質按量地完成。

觀察、思考、學習、總結：這是一些比較「虛」的能力，但決定了一位新人策劃的成長速度。

值得一提的是，新人策劃在點天賦時，「數值」這一天賦是封鎖的，也就是說，入門級別的策劃，基本不會有機會去配數值表。

最主要的原因，還是因為配數值表對策劃的能力要求較高，入門級別的策劃，往往不具備足夠的能力。

只有當策劃在入門後，又經過一段時間的磨練，開始接手一些執行相關的工作後，才有機會慢慢去接觸一些數值表。

又經過了一段時間的磨練，新人策劃已經能夠熟練掌握當下的工作，也算是融入了團隊，升級成為一名入門級策劃。

入門級別的策劃，同樣需要逐步養成四點特質，這四點特質，都是承接下一級別的策劃工作所必須的。

能夠根據局部目標，思考細節方法

能夠探索更合適執行的方案和方法

有不斷改進的自我驅動力

反覆改進調試驗證，是否達到目標

可以看出，這四點特質，在任何行業，都是分水嶺一般的特質，過了這道坎，在行業內，就算有了立足之地，能夠獨立地完成一系列的較為複雜的工作。

策劃晉陞的第三個等級，姑且稱之為能獨立工作級別，這個級別的策劃，基本上都具有一年往上的工作經驗。

而到了這一步，策劃職位的內部分工就更加明確了，系統策劃、數值策劃、文案策劃，各司其職。

到了這一步，會有一個特殊的現象，部分系統策劃，會「降級」去做數值執行（入門級），修鍊一段時間後再晉陞為數值策劃。

這與國內對數值策劃的要求有關，大公司的數值策劃招聘（校招生），一般都要求是數學相關專業的應屆生，或者說，以玩家身份在玩遊戲時，就非常關注遊戲內的各種數值，對數值非常的敏感，會去倒推遊戲內的各項數值計算公式。

畢竟，數值策劃在數理邏輯能力要求上是策劃內最高的，而一個牛逼的數值策劃，是不愁混不到飯吃的。

校招入職沒專職成數值策劃，卻又想從事這一方向，那就只能走「系統」轉「數值」的曲線救國路線，但通過這種方式轉型的數值策劃，數量還是非常多的。

能獨立完成工作級別的策劃，已經是一個團隊內的骨幹成員了，基礎的軟實力都是具備的，這時候，更需要關注一些硬實力上的技能。

知道根據當前遊戲的風格和品類，各模塊應該做成什麼樣子，以及知道為什麼要做到這個樣子

知道各模塊的評價標準

保證自己設計的模塊在遊戲內的還原度

這三點硬實力方面的技能，又是策劃升級路上的一道坎，這道坎決定著策劃能否從一位「高級打手」晉陞為一位「小頭目」。

這裡所說的小頭目，就是所謂的主策划了。

到了主策劃級別，能否繼續往上走，就需要看點運氣了，但談運氣，同樣是在具備了一定的能力基礎之上的。

對某一模塊有成熟的方法論

知道整個遊戲行業內對此模塊的高中低水準的衡量標準、實現方法以及利弊

能夠帶領一個功能小組協同完成某一部分的工作

這三點，便是主策劃最基本的，但也不是每一位主策劃都能統統具備的能力，一是要求對專業能力足夠深入精通，二是具備一定的團隊管理以及組織協調能力。

主策劃之上，便是製作人，製作人也大體也有兩個發展方向，一是更偏重項目管理的方向，國內大部分的製作人都是此方向，二是更加深入地進入到研發一線，成為更偏重項目研發的製作人

對於製作人的特質要求，聽起來可能更加玄乎，但每個行業的頂端工作者所必備的能力，可能都是類似於此的統籌全局的能力

能夠把控整個遊戲的設計方向和品質

能夠把控整個策劃團隊的建設

能夠指導各個具體模塊的工作

能夠救火，能夠協調各部門的工作

新手級-->入門級-->獨立工作級-->主策劃-->製作人，大體上就是國內策劃的晉陞之路，既需要專業能力的沉澱，有需要具備一定的運氣。

②遊戲研發的各部門分工。

一款遊戲的研發，這裡指的是稍微大型點的遊戲言，整個團隊在內部大體上會被分為項目組與平台組。

項目組的構成最簡單，策劃與程序。

而平台組，則涵蓋了QA（質量保證）、UI（狹義上的理解是把系統策劃設計的遊戲界面畫出來）、美術三大類職業。

QA就是所謂的遊戲測試。

UI則包括從最簡單的Icon製作、到更為複雜的特效製作、到最複雜的UI界面的製作。

部分公司還有專門的UE用戶體驗專員，這個職位更多的是去取代系統策劃的部分工作，親自去設計一些更符合用戶需求和喜好的遊戲界面。

美術部門在整個研發團隊里往往是最龐大，整個團隊100人，美術成員很可能就佔了一半以上，因此，為了節省開支，大部分的美術成員往往是同時負責多個遊戲項目的工作。

美術部門的分工，包括原畫、建模、動作、特效，這四步工作，是不斷遞進的過程，是有先後順序的。

值得一提的是，遊戲運營與運維並不納入遊戲研發的團隊體系，但這些成員，對於遊戲是否成功也起到非常重要的作用。

舉個例子，遊戲的研發人員的工作，是讓玩家對自己研發的遊戲一見鍾情，而運營與運維的工作，是在玩家喜歡上遊戲後，不斷地磨合玩家與遊戲的關係，讓玩家能玩得更久。

至於遊戲運營與遊戲運維的差別在於，運營屬於產品崗位，更多的是做「宣傳」工作，負責遊戲上線、版本更新、各種活動的宣傳、公告。

而運維屬於技術崗，主要負責伺服器的部署、伺服器的更新，簡單來說，就是保證遊戲的伺服器不崩潰。

可能還有人會問，音效呢？就算音效無法納入項目組，至少也得在平台組吧

但實際情況是，目前國內的遊戲研發，基本上在音效這一塊上都是外包的，因為在音效、音樂這一塊上，涉及到的版權問題較少。

為了節約時間與金錢成本，很多時候，UI的Icon製作以及美術的建模工作，也是經常外包出去的，因為這部分的需求是很明確的，即使是外包出去也能很好地把控外包的質量與進度。

上述內容便是較為大型的遊戲研發過程中的團隊構成，總而言之，在大公司，尤其是國外的3A大廠，公司內的每一位成員都像是一顆螺絲釘，大部分情況下只需要負責好自己的工作，整個團隊就像機器一樣，井然有序的高效運行。

只有在一些小型的團隊，受限於資源，才會出現一名成員身兼多職的現象，當然，這麼說，不代表這種團隊分工運作的形式不好。

④遊戲研發的流程

一款大型遊戲，從來不是一蹴而就的，而是分模塊、分功能完成的，這也更符合大公司內分工明確的特點。

因此，談到遊戲研發的流程，往往不是指整個遊戲的研發流程，而是指特定一個模塊的研發流程，當然，每一個模塊的流程，大體上是一致的。

在國內，最基本一套流程是「策劃--UI--美術--程序--QA--運營--運維」。

但是，這套流程卻是非常理想化的，實際上基本都不按這個流程進行。

現實情況很可能是，策劃寫好策劃案，跳過了UI和美術，直接找到程序，請求他們先開始寫點功能邏輯。

這時候，程序往往會拒絕，美術資源都還沒到位呢，我怎麼搞？

而策劃則會好說歹說地勸服程序員開工。

等但到美術完工了，程序功能寫得也差不多了，結果一看，不行啊，美術給的資源用現有的技術水平實現不了和實現起來成本很高。

這時候要怎麼辦？重做唄。

這就白白浪費了不少功夫以及遊戲研發最寶貴的時間。

再加上，策劃寫的策劃案往往也是需要重新改需求的，所以等到美術、程序重新完工了，可能策劃的需求又改了，這下美術、程序基本上又白乾了。

結果就導致，到了研發組提交遊戲的時間了，測試卻拿不到驗收測試的版本，而運營做好了各種宣傳，按原計劃發布了開服公告，結果遊戲卻鴿了，只能向玩家發致歉聲明，並給玩家發各種補償。

上述這種情況是經常發生的，這與國內目前的大環境有關，即使是最頂級的兩家公司，也會出現這種問題，想想我們平時玩手游，領過多少補償就知道。

但一位「有良心的，有專業素質的」策劃，在一個模塊的研發過程中，一定要將這種情況控制在三次以內。

上述的流程，是更為宏觀、整體的一套流程，下面講到的，是與策劃更為相關的流程，我會大概地描繪策劃在整個研發流程中，在各個階段會做什麼。

需要注意的是，這段描繪，同樣是基於一個模塊研發，而不是基於整個遊戲的研發。

項目最開始，往往是製作人依據市場狀況與團隊狀況做出新的規劃，然後將自己的關鍵意圖傳達給主策劃，主策劃接收了製作人的意圖後，會將其拆解為具體的遊戲功能，然後開始分配工作任務到各方向的策劃身上。

這時候，具體去展開工作的策劃，會先和主策做深入的溝通，確認好任務的目標、設計要點以及注意事項。

在此基礎之上，各方向的策劃會繼續討論，以此形成初步的思路框架，並記錄在案。

完成這一步後，各方向的策劃需要找主策驗收初稿，不合格便重來。

合格了，就會開個大會，各方向策劃、主策劃、製作人，以及其它部門的成員，都會參加，以此收集各方的意見。

大會主要針對「程序上是否能實現目前提出的需求，實現難度有多大」，「美術上的工作量、花費的開銷有多大」等問題進行討論。更多的是考慮實現策劃需求的技術成本、時間成本、金錢成本。

如果在大會上程序與美術提出了很多問題，那麼策劃可能就要根據程序與美術的意見對需求做相出應的更改。

如果程序與美術覺得還OK，則進入下一步，策劃將需求完整地整理成文檔，並再次交由主策劃驗收。

主策劃驗收不通過，則重寫文檔，通過了，則將需求文檔上傳至SVN（或其他管理平台）。

各部門依據需求文檔，正式開工，而策劃人員，則必須保持每天對接其他職位人員，做好項目跟進。

同時，如果開工過程中有什麼新的需求，也需要及時在主策的指導下對文檔進行修正更改，並將新的文檔重新上傳至SVN。

最後，遊戲完成，交由策劃人員確認，初步確認無誤後，再轉交給主策劃與製作人驗收，再次確認無誤後，提交給QA部門，運營和運維同時做好上線前的準備工作。

以上這部分內容，便是與策劃更為相關的工作流程，可以看出，策劃的工作不單單是在做設計，更多地時間可能是用在與各部門的協調溝通上，而能獨立完成工作級別的策劃，是整個流程中的主力軍。

④策劃執行基礎

在當前國內大背景下，作為策劃，更重要的不是創造力，而是執行力，執行與跟進這兩個詞詞，貫穿了策劃的整個職業生涯。

執行力的定義很廣泛，老師提煉出了三點，分別是完成任務的意願、完成任務的能力、完成任務的程度。

圍繞這三點，老師具體講了策劃執行與跟進的相關知識，這一塊的知識，在老師看來，更加的形而上學，不可捉摸，需要策劃在自己的職業生涯中不斷地理解。

事實也確實如此，我在整理這一塊的內容時，在理解上依舊存在很大的阻礙，還需要不斷地修鍊。

好了，進入正題。

首先是，執行與跟進的先行準備，包括以下四點。

流程預估：涉及到哪些工作、涉及到哪些資源、涉及到哪些部門、涉及到哪些環節。

部門協調：涉及的人員和部門、工期協調、人員協調、信息協調、預期、風格。

工期預估：根據工程的大小預估工時、熟悉各工種工作所需的時間。

問題預估：關鍵環節、預防手段、處理手段、善後手段。

先行準備之後，進入正式的跟進環節，包括以下五點。

發起：文檔提交、需求提交、宣講會、開工溝通、RTX群與郵件交流。

製作執行：製作配合、品質要求、串聯上下游、解決製作問題、日常跟進、提前check、節點check。

驗收：主幹功能跑通、初步Bug尋找、細節優化、文檔還原度比對（在這一點上，盡量不要進行設計調整）

提測：提交測試版本、提交測試需求文件、跟進測試過程與結果、跟進Bug回歸、跟進測試報告。

上線前/上線後：封版測試、白名單測試（在通過上架申請之後，需要進入到白名單環境測試。白名單是上線前的最後一次測試，屬於正式的測試環境）、上線跟進、總結復盤（這點對個人的提升極大）

接下來，老師講了個笑話，分享了新人策劃經常被問到的，回答後連死都不知道怎麼死的一個問題的標準答案。

這個問題是「某某某啊，XX功能跟進得怎麼樣了？」

大部分策劃的回答可能是，「不知道、我去了解一下」，「在畫UI了」，「OK了」等等。

這三個回答雖然是越來越好，但第三個回答依舊是不合格的答案，「OK了」，到底是指哪方面OK了，顯得很模糊，讓人摸不著頭腦。

老師提供了一個他認為的標準答案。

"昨天開始畫UI，我剛才給了一版反饋，今晚會提交給程序，預期周四下午提交給我驗收。已經提前和QA打好招呼了，周五開始測試。應該可以上下周二的外發版本。上線之後我會再跟進一下。」

這個答案好在哪？可不是好在它夠長...

首先，這個回答包含了對團隊已經完成的任務的總結（昨天開始畫UI）

同時，也明確指出個人完成了什麼工作（給了一版反饋）

緊接著還對接下來的工作做了計劃(今晚會提交給程序，預期周四下午提交給我驗收。已經提前和QA打好招呼了，周五開始測試)

並給出了保證（應該可以上下周二的外發版本）

最後，也表達了自己盡職盡責的態度（上線之後我會再跟進一下）

這個回答，基本把上頭BOSS想了解的信息都涵蓋了，因此，不談回答的內容是否足夠好，但這個回答的框架、格式，無疑是很正確的。

最後，老師分享了一些他認為很雞湯的內容，他提到了在他看來，身為策劃，所需要的一些品質、能力與技巧。

策劃所需要的品質包括：主動、細緻、嚴謹、樂觀、堅韌

策劃所需要的能力包括：協作能力、表達能力、統籌能力

策劃所需要的技巧包括：

投其所好（不同崗位的人有不同的思維方式，程序更有條理，更加理想，美術更重審美，更加感性）

別聊工作（工作外的時間，尤其是吃飯時間，少聊工作）

多說「我們」（保持一種團隊感和凝聚力）

耐心傾聽（你的同事沒有一個人是SB，他們的想法，或多或少都是正確的，也是值得傾聽的）

不要反駁（先虛心接受，不打斷，不質疑、再做進一步的討論）

多說「對的」（給予他人尊重，他人也才會尊重你）

結果鼓勵（商業胡吹，相互鼓勵）

端茶送水（好好對待自己的同事）

奶茶要勤（找人幫忙時，空手前往是很不禮貌的，老師提到他剛入行時，每個月要花上大幾百塊的奶茶錢...）

這些所謂的品質、能力、技巧，更多的是一些專業能力外的軟實力，不好去做直接的衡量，但卻與策劃的職業生涯息息相關，雖然雞湯，但老師希望我們能夠多加體會。

把前面提到的一大堆品質、能力、技巧總結起來，其實只有三點。

一是責任心，為人積極主動，做事負責到底上。

二是尊重，尊重自己、尊重夥伴、尊重他人勞動。

三是進取心，自我超越、自我更新，以始為終。

至此，正課內容結束。

從最開始的策劃內部分工與策劃晉陞之路，遊戲研發的分工與研發流程，到最後的策劃執行與跟進，整堂課下來還是乾貨滿滿的。

還想提的是，把個人總結修改成文章，比我想像中要困難很多...

最後，附帶幾個正課結束後，問答環節的比較有意義的QA吧。

①上面講到的策劃工作流程，更多的是基於功能模塊，那對於核心玩法的設計流程是怎樣的呢？

核心玩法，其實依舊是一個具體模塊下的某一部分，比如說一個ARPG遊戲，在戰鬥的核心玩法設計上，會更關注於戰鬥的打擊感，那麼策劃要怎麼去做好打擊感設計呢？

最重要的是對影響遊戲打擊感的因素做拆解。

影響打擊感的因素可能有兩大類，一類是攻擊後對怪物造成的僵直或擊退效果，一類是打擊過程中伴隨的傷害飄字和同步的音效。

確認了這兩大因素後，就可以圍繞這兩點去做單一功能的設計。

②現在手游很流行氪金的翅膀系統，這是因為玩家都很喜歡遊戲內的翅膀嗎？

這要看遊戲的受眾群，或者說，遊戲的目標玩家是哪一類型的玩家。

喜歡翅膀的玩家，可能更多的是社交型玩家，因為翅膀滿足了他們炫耀、顯擺的心理追求

或者說，更玄乎的，遊戲內的翅膀，滿足了部分玩家在現實生活中飛翔的夢想。

基於這些原因，玩家才會喜歡遊戲內的翅膀，只要玩家買賬，肯出錢氪金，不管他嘴上怎麼說，那他就是喜歡遊戲內的翅膀。

③遊戲策划上班時，更多的是坐在工位上工作，還是到處走動？

因人而異。

有些勤奮的策劃，白天上班時間一直在開會，開完會就到處地走動，去跟進需求，晚上回家了，才獨自加班寫案子。

大部分的策劃，白天寫案子，有會就開，需要跟進才去跟進。

老策劃，不寫案子，不跟進，只開會，更多的是做協調工作。

當然，也與從事的具體方向有關，數值策劃更多還是坐在工位上工作，系統策劃大概是一半坐著一半走動跟進，而表現策劃（文案、關卡、戰鬥等）則走得比較多。

④遊戲在發行前，對後續的版本更新有做好計劃嗎？

只能說，隱約有點想法和框架，但沒有具體的計劃。

因為做遊戲需要投入很多的資源，光是把遊戲做出來，完整，沒Bug，還好玩，就已經很難了，所以在資源有限的情況下很難再去對遊戲發行後的版本做詳細的計劃。

同時，遊戲發行了，不代表一定能火、能賺錢，後續的版本更新，雖然是基於原先版本，但歸根結底還是要看市場的狀況與玩家的評價，才能做出下一步的具體決策。

至於遊戲的劇情，其實，文案策劃在做劇情設定的時候，一定是會充分考慮「留白」的，就是要防止各種意外情況，始終保持遊戲劇情不歪。

⑤策劃在遊戲的研發中，創意上的發揮空間大嗎？

不大，因為在遊戲行業經過多年發展以及目前市場同質化問題嚴重的情況下，做遊戲需要思考的內容不多。

更多的是製作人制定好框架，然後，基於當前的市場狀況，玩家喜好，提出差異化的需求，再交給下頭的主策、各方向策划去落地執行，各方向的策劃，更多的是去圍繞差異化做文章，但大體的方向，是事先制定好的。

⑥遊戲上線發行了，經過一段時間，卻發現原本以為OK的內容現在不OK了，需要或者會推到重做嗎？

老師認為這是一個很好的問題，因為這涉及到了目前國內很多大公司都在做的一件事情。

那就是「設計原則與設計思路的沉澱」。

比如，一年前，遊戲剛發行，當時的一個需求是，「遊戲內所有的按鈕都必須有特效」

但一年後，回過頭來看，發現這個問題不夠具體，到底是要有什麼樣的特效？

同時，太多的特效，帶來的視覺體驗並不好，這點對遊戲是存在負面影響的。

因此，當年的需求，可能更改為了「遊戲內所有的按鈕都必須有反饋」，反饋的形式可能多樣，但不外乎就幾種，落實下來就更具體了。同時，也能給玩家帶來更好的視覺體驗和更清晰的指引。

這就是一個團隊的成員，在項目研發，項目上線，不斷成長、進步的一個過程，因此，進步後的團隊成員，認為最初的設計是很SB的狀況是常常發生的，所以，就會基於原有的不足，再去做修改優化。

這是團隊成員自身迭代的一個過程，長久下去，一個團隊的成員就能明確地判斷一個遊戲為什麼好玩，基於這點，就會進而激發出能不能再做一個好玩的遊戲的雄心壯志，最終，做出好遊戲的概率就不斷地提升。

以上，文章內容很長，謝謝大家的支持。