2018.08.13策劃課堂之策劃工作流程與文檔規範

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

今天這節課是「閃耀策劃實習」的培訓課程，講課老師是戰神工作室的伯倫希爾老師。

策劃在日常工作中，大部分的時間都用在寫策劃案上，今天這節課，簡單來說就是教我們如何去寫策劃案。

策劃在整個遊戲的研發分工上，屬於入門門檻較低的職位，不像程序與美術，有相關的技能要求，因此，策劃的專業性更多的就體現在對標準的遵循上。

寫好策劃案，其實就是遵循好公司制定的策劃案撰寫標準，一份好的策劃案，不僅能夠提高項目組整體的工作效率，還能增加各個職位員工之間的信任度，意義非常大。

閑話少說，進入正題，今天這節課，包括四部分的內容，「策劃案中的常見問題」-->「策劃工作流」-->"策劃案的內容"-->「策劃案撰寫的小原則」。

①策劃案中的常見問題

一、文檔不規範

每個人書寫的習慣不同，如果不按照一套統一的規範標準，其他項目組的成員查看、理解每位策劃寫的策劃案就會非常不方便，甚至為產生一些理解上的誤差。

二、經常口頭變更內容，卻不在策劃案中實時更新

策劃有了新的需求，第一時間可能會圖方便，不重新修改策劃案，直接找到程序、美術，口頭向他們提出新的需求。

這樣看似效率挺高，但實際上，他人不可能完全記得策劃口述的新需求，而且程序、美術的工作任務都是按照策劃案的內容進行分配，因此，口述的需求，常常會被遺忘。

這就需要策劃要實時更新策劃案，口述只能是一個輔助手段。

三、設計沒有參考原型

策劃寫策劃案的過程，是主觀想像非常多的一個過程，因此，可能很難準確地還原出上級交代的需求，這時候，找到合適的參考原型，就是一個很好的解決方案。

依據參考原型進行策劃案撰寫，不算是抄襲，這樣做有助於避免策劃的一些主觀想像，同時可以使策劃的思維定位更加準確。

創新是一個長期積累的過程，需要一定的契機，而策劃案的撰寫，更需要的是腳踏實的結果，因此，能在原型的幫助下完成，並不可恥。

四、規則不清晰

策劃案中對每一條遊戲規則的描述都要清晰，以減輕他人的理解成本，提高工作效率。

不清晰的規則描述，可能導致他人的理解不一致，比較負責的程序、美術，可能還會過來確認一下這條規則是什麼意思，不負責的程序、美術，可能就會自己腦補這條規則是怎樣的，甚至乾脆拋棄掉這條規則。

五、不重視UI操作流和表達反饋，甚至漏掉UI頁面

有些策劃對於遊戲界面等比較偏向於美術設計的內容，會比較含糊地去描述，實際上可能自己也不太清楚遊戲的界面要怎麼去設計，這點就會導致美術對於需求的完成度很低，還可能 產生 翻 一系列的撕逼情況。

因此對於界面這部分很基礎的內容，策劃也一定要想清楚，並準確、細緻地表達在策劃案中。

六、數據表的欄位參數沒有說明，後續維護不方便

策劃撰寫的策劃案中，會出現 一些 比較 個性化的名詞，但大多數的策劃可能並不會去給這些新奇的名詞寫注釋，這就導致了，這份策劃案交由 另一位策劃負責後續維護後，這位接手的策劃，可能會不理解這份策劃案中的部分名詞。

策劃在整個項目研發中，可能不會持續的負責某 一個模塊，可能後續會把原模塊交由另一位 策劃 負責，這時候，只有注釋清晰的策劃案，才能做到策劃與策劃之間的無縫銜接。

這就像寫代碼也不能忘掉注釋一樣 ，其實就算是同一個策劃，間隔幾個月回頭看自己寫的策劃案，如果沒有注釋的提示，可能也會出現自己都看不懂自己寫的東西的狀況。

七、關鍵測試內容缺失，導致模塊跟進驗收質量不穩定

QA測試在進行遊戲測試的過程中 ，雖說每一個遊戲界面、每一個功能模塊都會點進去測試，但在一些細節 上，他們可能會 遺漏 。

同時，項目組中兩位數的測試人員，可能並不能完全檢測中遊戲中的所有紕漏，但成千上萬的玩家，卻能輕易地找出遊戲的BUG。

BUG永遠是測不完的，因此，就需要策劃 對一些關鍵性的節點做好 強調 ，讓測試人員專門注意一下這些點，避免關鍵性的錯誤沒有被修正。

八、沒有定義用戶體驗的數據採集量化分析項，導致後續優化方向過於主觀

定義用戶體驗的數據採集量化分析項，這是一個比較 困難的點，新人策劃基本上無法獨立完成這一部分內容的撰寫。

這一點主要 是制定一些可以被明確量化的指標，通過 指標來衡量一個模塊的好壞，從而指導模塊後續的優化更新。

九、不考慮運營同事對模塊內容的理解

策劃與運營的工作有很大的差別，運營人員在遊戲研發中，不隸屬於項目組，因此，策劃與運營的交流往往不在同一個頻道上，而策劃案就是幫助策劃與運營平行溝通的媒介。

因此，策劃案的撰寫也要考慮到運營人員能否理解一個設計背後的設計思路，避免運營人員設計出一些有損遊戲品質或環境的運營活動。

以上九點，就是策劃撰寫策劃案的過程中，容易 出現的問題，這部分的內容，與後續第三部分的內容相互聯繫。

②策劃工作流

策劃工作的核心是策劃案撰寫，但策劃撰寫策劃案，實際上並不需要花費太多的時間，這涉及到策劃工作流的問題。

一個新的模塊功能的設計，往往需要製作人或者主策划去發起需求，也就是「功能確認」的過程，製作人或主策會對下面的策劃解釋描述新模塊的設計思路，但策劃不可能單靠製作人或主策一次描述就能清楚整個模塊要怎麼去設計。

因此，策劃需要反覆向上級確認，在開始動手前，就理順各種設計細節。

緊接著，策劃要去找到合適的參考原型，也就是「找到原型」的過程，同時，找到參考原型後，要再次向上級確認，這裡A、B、C三個參考原型，哪一個更符合我們的設計需求？

做好這一步，策劃才能真正做到心裡有譜，從而正式開始撰寫策劃案初稿。

策劃案初稿撰寫的核心就是表達出我打算怎麼設計這個需求，也就是「開工思路」的過程，初稿寫完後，要交由上級驗收，並反覆修正至合適、無差錯，也就是「審核確認」的過程。

到這一步為止，策劃實際上花費的時間應該占整個策劃案撰寫耗時的60％，這個「前戲」部分花費的時間越長，最終產出的遊戲模塊的質量也會越高。

初稿審核通過後，策劃就需要去撰寫完整的策劃案，也就是「輸出完整文檔」的過程，這一步同樣需要上級的進一步檢查驗收，並且修改完善。

策劃案完全OK了，需要開個宣講會，也就是「文檔宣講」的過程，項目組內外所有職位的員工，都需要參加，包括前後端程序、美術、UI、QA、運營各個職位的員工。當然，製作人和主策劃也要參與到宣講會。

開宣講會的目的在於協調好各個職位的分工，並對實際開工後可能會遇到的問題做提前預警，開工之前，對於一些技術上難以實現，或者投入成本過高的需求，還是可以重新設計的，但開工後，就很難回爐重做了。

策劃在宣講會後的工作，就是跟進，也就是「跟進驗收」的過程，這需要策劃實時跟進項目組內其他職位員工的工作，尤其是一些關鍵節點的工作。

以上，是策劃在一個模塊設計中大體上的工作流程，可能對於一個策劃來說，設計反倒是其次，最主要的還是協調與跟進，承上啟下地對整個模塊負責。

③策劃案的內容

一份優秀的策劃案，需要具備十方面的內容，下面，我會對每一方面的內容做具體地描述。

一、版本信息

這是基礎中的基礎，版本信息可能包括策劃案文檔的創建日期、創建人、後續修改日期、修改人、修改內容等等。

不同的公司可能在這點上的要求不同，但整體上還是大同小異。

二、對標參考

這部分的內容，可能包括整理出對標遊戲所有的UI界面和操作流程，對標遊戲主要的規則，對標遊戲主要的視覺表達和操作反饋，對標遊戲的基本數值體驗。

這四點內容，只是做好對標參考的前提，最關鍵的一點是，提煉出最終的參考指導結論，明確需要遵守的核心規則，以及可複製、需調整、待優化的內容。

在這部分內容的撰寫中，可以遵循三條小建議。

第一，沒有最終參考結論的對標參考都是在爽流氓。

第二，在解決相同問題時，建議使用現成的參考原型的解決方案，成功原型至少經過了市場與玩家的驗證。

第三，如果堅持在參考原型的基礎上做加法，不要改動核心規則，請在表達和反饋上做文章。（更詳細的內容可以參考專欄里路徑思維這篇文章）

三、開工思路

這部分的內容，包括五點分支。

基本概述，需要解釋清楚這是什麼東西，吸引玩家的是那些點，同時，注意語言的精鍊，用越少的文字表達，代表你對你設計的模塊理解得越深。

設計目的，這是開工思路的核心，需要解釋清楚，這個模塊的設計，解決了哪一類玩家的什麼問題。

核心體驗，需要解釋清楚，這個模塊的設計，給玩家帶來了怎樣的感受，是難度上的挑戰，還是概率隨機上的刺激等等。

核心屬性，也就是玩家圍繞什麼在玩，這是玩家在這個模塊中的交互關鍵點。

玩法結構腦圖，通過腦圖的形式，可以事無巨細、毫無遺漏地梳理好整個模塊設計的內容。

對於開工思路這部分內容的小建議，是在製作人或主策劃的指導驗收下完成，同時要減少個人的主觀想法。

四、UI布局和操作流

這部分的內容，包括兩點分支。

明確每一個界面的基本布局和內容展示，這點可以依據開工思路中制定的腦圖去執行，主要需要明確的是關鍵信息的展示方式和展示內容的主次關係。

頁面與頁面的操作流程和打開方式，最好能建立起箭頭相互對應的關係。

對於這部分內容的小建議，是不要丟了界面，即使是一些小提示界面，或者是一些彈窗界面。

五、邏輯規則

這部分的內容，包括三點分支。

所有點擊功能的規則以及程序邏輯判定圖，程序邏輯判定圖是通過流程圖的形式展示規則的運轉邏輯。

所有非點擊功能的規則以及程序邏輯判定圖。

潛規則，這是一些不想讓玩家知道的規則。

對於這部分內容的小建議，是照著UI布局和操作流來檢查是否有遺漏，UI界面是按模塊整合的，因此，照著UI界面就能明確是否遺漏了哪一個模塊，哪一個功能的規則。

六、數據表結構

這部分的內容，包括三點分支。

需要配置的數據有哪些以及每個數據欄位的意義。

數據的存放方式，是單表存放還是多表存放，兩者各有優劣，前者閱讀起來更加清晰，一目了然，後者適用於大型模塊分門別類地整理，同時，容錯率高，單個表出了差錯，並不會對整個模塊的設計有太大影響。

後續內容的數據可擴充性，需要留好坑，為後續的模塊更新埋下伏筆。

對於這部分內容的小建議，是在製作人或主策的指導下完成，必要時可以尋求程序的幫助，這部分的內容難度比較高，同時維護起來可能需要和程序打更多的交道。

七、美術需求

這部分的內容，包括三點分支。

圖標、原畫（人物、場景）、動畫（動作、特效）的完整需求列表。

參考圖片的需求描述，圖片的具體參考點要清晰準確地描述，甚至是「這張參考人物圖的鼻子很合適」這樣細微的需求都需要明確表達。

主要視覺表達和操作反饋的要點，包括動態與靜態上的一些需求要點。

對於這部分內容的小建議，是在找好參考圖的基礎上，主動和美術或UI同事進行溝通，同時積極聽取他們的意見。

八、測試要點

這部分的內容，包括三點分支。

關鍵的功能檢測點有哪些，依據UI布局展示的功能點和數據表來設置。

容易引發玩家進行牟利的風險點有哪些，這是一些規則或數值上的漏洞，而且往往很致命。比如《陰陽師》去年年初的刷材料漏洞。

潛規則是否正確有效地運轉。

對於這部分內容的小建議，是明確QA永遠不會幫你測試這些內容，他們往往只測試可見的操作流，而忽略細枝末節。

九、數據分析

這部分的內容，包括兩點分支。

需要採集玩家在該模塊中的哪些數據。

如何量化玩家在該模塊的體驗。

這部分的內容是非常複雜的，同時比較玄學，考驗的是策劃的量化思維，需要經驗老道的策劃才能完美地完成這部分的內容。

對於這部分內容的小建議，是一條設計思路和一個設計目的。

設計思路：如果對於該模塊，玩家反映很好或很糟糕，那會表現出哪些數據特徵，從這個角度去思考並設計數據分析。

設計目的：數據分析的設計目的在於驗證模塊設計的目的是否達到，驗證玩家體驗是否達到設計預期。

對於這一塊的內容，老師特地舉了一個例子，公司新上線的一款SLG，內部的KPI目標是玩家首日付費率達到10％，於是，策劃和運營共同設計了一系列首日付費活動。

但遊戲實際上線後的玩家首日付費率只有6％。

運營拿到這一數據，立馬找到策劃，要求策劃加大首日禮包的折扣力度，原本打六折，現在降到打三折。

可折扣力度加大後，玩家首日付費率的數據並沒有太大的改善，只是提高到了百分之六點幾。

老師意識到不對後，找到運營，要求運營整理出所有的付費的玩家是在進入遊戲多長時間後付費的數據。

結果，老師發現了一個很有意思的現象，玩家首日付費率只有6％，但次日付費率高到60％，這是一個很恐怖的數據，從中，老師也得出一個關鍵信息，折扣力度對玩家首日付費的影響不大。

那問題出在哪？

玩家會在首日付費，首先能想到的影響因素是折扣力度，如果折扣力度足夠大，那即使玩家實際上還沒搞懂遊戲要怎麼玩，資源要怎麼用才划算，玩家也有可能在首日就付費，當然，這些沒玩懂就付費的玩家，不是家裡有礦，就是這款遊戲的核心玩家，對這款遊戲關注已久，認可度很高。

另一個影響因素是玩家懂不懂玩，清不清楚要怎麼去規劃遊戲內的資源，如果搞不清這點，大部分玩家是不願意掏冤枉錢的。遊戲的首日付費率極低，但次日付費率極高，就證明大部分玩家實際上在第二天才玩懂這款遊戲，這絕對是遊戲新手引導以及其它設計內容上的紕漏。

因此，基於數據分析，策劃組對遊戲內容做了修改，遊戲的首日付費率得到顯著的提高。

十、運營相關。

這部分的內容，包括三點分支。

模塊對外宣傳的重點。

模塊如何做運營活動。

模塊在做運營活動時的鼓勵項和禁忌項，比如一個七夕節的折扣禮包購買活動，就需要策劃向運營強調，哪些遊戲資源是絕對不能通過禮包形式直接賣出去的，那些遊戲資源是可以直接賣出去的，甚至是一定要賣出去的。

對於這部分內容的小建議，是在製作人和主策劃的指導下完成，同時一定要和運營同事及時地溝通，大多數情況下，運營的宣傳公告都是先行於遊戲模塊上線的，如果策劃沒向運營解釋好宣傳內容，那就可能出現宣傳與實際不符的惡劣狀況。

以上，就是一份遊戲的遊戲策劃案需要具備的十點內容，部分高難度的內容，是需要策劃在製作人或主策劃的指導下完成的，同時，大部分的內容，都需要策劃與其他職位的同事緊密溝通。

在具體撰寫上，策劃案的十點內容，需要分點隔開，有明確的分割線以助於閱讀，在宣講會上，點與點之間，也要留出足夠的時間，讓其他的同事進行提問與討論。

④策劃案撰寫的小原則

這部分的內容涉及到四點原則。

一、盡量減少難以在UI上展示的規則

UI上都難以展示的規則，加大了玩家的理解成本，同時，項目組內部對於這些規則也會產生理解上的困難，從而導致工作效率降低。

二、不要在一個模塊里實現多個設計目的和玩家的核心體驗

這是重中之重，切記不要一上來就做加法。

成功是具有一定的偶然性的，一些遊戲的某個模塊可能真的做到實現了多個設計目的，滿足了多種玩家體驗，但這個成功遊戲的模塊，初始的需求肯定不會有這麼多，而是後續一步一步更新添加上去的。比如，FF14里的每日隨機玩法。

三、尋找優秀的參考原型，進行對標設計，減少/不要主觀想像

明確對標設計不是抄襲，也不會扼殺你的創造力，相反，有助於你進行思維定位，從而幫助自己更加明確設計需求。

四、減少一個模塊與其他模塊的關聯性，一個模塊越獨立，越可控

模塊的設計是圍繞設計目的進行的，遊戲里會有核心循環模塊，這些模塊是緊密相連的，聯繫越緊密，遊戲會越好玩，玩家的體驗越連貫完整。

但有一些模塊，就是獨立的功能模塊，這些模塊的設計，就要做到減少與其他模塊的關聯，保證該模塊不容易影響到其他模塊，同時也不容易受到其他模塊的影響。

以上，就是這節課的全部內容，個人還是很喜歡上伯倫希爾老師的課的，他講課的思路和風格我很喜歡…