我們中的大多數人
如果給各位策劃崗位的同行劃分一下，可以總結出三種類型的策劃。前兩種是極少數的極端情況。左側圖的策劃，PUBG，戰術競技（Battle Royale）類型的開創者，這種策劃大佬的存在基本等同於遊戲項目的靈魂，掌控遊戲世界規則的男人。右側，行業新兵，被程序和美術鄙視的對象，食物鏈底端的工具人。
而第三種，也就是作為策劃的大多數人，我們在團隊裡有一定的話語權，但更多時間還是在執行需求，有多個項目經驗，結果有好有壞，而像我們這種普通策劃，想要在團隊中獲得「地位」/認同，靠什麼？
有人說，靠項目。這個是必然的，如果一個策劃的履歷上有幾千萬用戶量級的爆款項目經驗，那他就是所有團隊眼裡行走的香饃饃。但問題在於，擁有爆款項目經歷的策劃應該也只有極少數人，所以我們還能靠什麼？
有人說，靠能力。但這也涉及到策劃崗位一個很尷尬的處境，眾所周知，遊戲研發團隊裡，除了管理型崗位，就是美術程序策劃三個支柱。美術的能力怎麼看？一幅原畫出來，畫風是否適配，功底是否到位，一目了然；程序能力怎麼樣？寫一段代碼出來，邏輯是否嚴謹，一目了然。策劃呢？靠方法論，而問題在於方法論是沒有統一的衡量標準的，因為每個人對於遊戲設計都有自己的方法論。
說到這裡，我想表達的是，能力與項目都是策劃的資本，但是如何在工作中獲得團隊成員的認同，讓人信服，歸根結底，可以用遊戲裡的詞彙來形容，那就是升級，累計聲望。接下來我也會分成四個階段，將這個看似很虛無的方法論來落地到實際工作中，策劃崗位該如何實施它，提升自己在團隊中的「地位」。
入門先鋒：方案設計
作為策劃新人，正式踏入這個崗位的第一步，來自你的導師或是上級的第一個任務，要麼是對應項目的分析報告，要麼是一份與細分崗位掛鈎的策劃案。無論是做關卡策劃，技能策劃，活動策劃，這一點相信大家都有同樣的經歷。
由於這時的你還只是個懵懂的新人，所以這第一份策劃案，通常不會要求你能給出前無古人後無來者的創意，這份策劃案最重要的就是它的完整性和可執行性。
（一）定位
要寫一個策劃案，你會碰到什麼情況呢？有的Leader可能會給你詳細地描述他的需求，有的Leader可能會拋給你一個參考的遊戲項目，讓你自行揣摩。而當一個策劃新人遇到這種短小精悍的需求時，你需要做的是定位需求。
1. 知道做什麼比怎麼做更重要：很多情況下，新人在遇到Leader對任務描述比較簡短時，或是不敢追問，或是覺得自己有很多想法可以發揮，多半都會選擇盲目地領了需求後亂寫一通，於是這種策劃案交上去，最終導致的是與Leader的想法不一致，策劃案只能面臨被否決，回爐重造的命運。
2.那麼如何定位需求呢？我個人傾向逐級拆分核心需求：剛才的例子延伸出來便是我早年曾經的項目經歷，當時在拿到這個需要「微創新」的PVP戰鬥需求後，我首先做的便是在與Leader的溝通中確認好逐級的核心需求。
要知道在2014年的時候，射擊手遊同步PVP還是一個很難實現的事情，許多射擊類型手遊採用的還是異步PVP，所以當時我與Leader進行了確認，是同步還是異步戰鬥，於是第一個核心點出來了，需求要做同步PVP戰鬥，也就是實時戰鬥。
接著，這個玩法的適用性，Leader給出的答案是，希望能夠隨時隨地戰鬥，所以第二個核心點出來了，希望能隨時匹配到玩家進行戰鬥，也就是實時匹配。
最後是關於戰鬥的體驗，這個PVP玩法中，是否允許數值的縱深，當時討論之後，確認既要表現出一定的付費體驗，又要基礎對戰平衡，所以我們需求的是相對平衡性，也就是數值天秤。
（二）預設
當我們完成了對需求的定位，將其分拆成為核心點後，我們來到了下一步，如何進行策劃案的編輯。在這一步，我所提出的問題是：你寫策劃案的思路是怎麼樣的？
1. 設想問題，理清設計細節：這裡要給策劃新人們提供一個建議，像寫作文一樣，給你的策劃案打草稿，在這裡我們所做的依舊是給這個PVP需求完善它的框架，你需要將腦海中的想法，創意都在鍵盤上敲擊出來，一個個地設問，推敲，取捨；想清楚這個玩法系統中各個節點的問題，好應對策劃案提交後面對來自其它開發人員的問題，防止一臉懵逼。
2. 推導功能，開發關鍵模塊：理清設計的細節問題後，緊接著便是結合，在進行需求定位時確定下來的核心點，推導出的功能模塊。第一個核心點，實時PVP涉及的是戰鬥方式和戰鬥關卡模塊，隨時隨地PVP的核心點所關聯的是匹配機制與AI對戰功能模塊，而與平衡性相關的則是涉及職業，裝備等的數值天秤。
（三）對口
策劃作為需求的發出方，但執行需求是團隊中的各個專業成員，所以在編輯策劃案時，我習慣多加一個步驟，與對口的成員討論方案，得到他們的反饋意見來進一步完善策劃案。而在溝通過程中，也了解了不同專業的人，他在看策劃案時的偏好與關注點不盡相同，但總結來說，便是抽象的長段文字比不上具象化的重點演示。
1. 流程-簡單明了的邏輯圖：我一開始拿給程序看的流程策劃案也是句句斟酌，十分詳盡的一份文檔，但是當程序看到這樣一份文檔時，表情是微妙的。其實也不光是程序，對於我們這種普通人而言，閱讀大段文字通常都會讓人心生牴觸，如果不得不讀，還會面臨許多因人而異的理解偏差。
所以，為了保護我方程序的腦細胞，最後那一大段文字變成了如上所示的邏輯圖。每一個節點的開始，結束，中間的判定過程都可以非常清晰地看到，所以這也使得實際流程開發的過程十分順利。
2. 玩法-清晰明確的示意圖：玩法的展示也是同樣的道理，在進行一些項目的PVP玩法開發時，有時玩法的創意部分便不是由具體指定的關卡策劃來主導，而是鼓勵每一個人的玩法創意。所以在跟開發溝通需求時，歷史再次重演，他們對著初版文檔也是一臉茫然，於是文字版策劃案重新改了表現方式，轉變為一張玩法具象圖，而這種具象化的展示讓開發很快便抓住重點，包括掩體的位置，對角線，距離等要素。這樣一來，便是有疑問，照著圖來溝通，也省了無數口水。
3. 體驗-論證法：最後再提一個比較貼近實際應用的技巧。在開始敲定核心需求的時候，之前提到了，Leader的其中一個要求是玩家能夠隨時隨地戰鬥，這就涉及到戰鬥AI的引用。而在設計過程中，除了AI的行為，反應時間等等設計，比較有意思的點發生在設定AI射擊命中率的時候。
當初我們在設定射擊命中率時，一開始給到程序的方案是採用純百分比的命中率設定，比如給AI設定五五開的命中率，但卻發現在AI的射擊命中率在實際的遊戲環境中遠遠達不到我們所設定的需求。後來我們搜尋相關的資料時，發現了魔獸世界的團隊在一次分享中所提及的判定機制-命中修正。
這個判定的邏輯是，在擁有足夠基數的情況下，AI的戰鬥次數越多，命中率越能夠貼合我們的需求；並且在純隨機的少量樣本情況下，也能夠基本滿足我們的需求。於是關於AI命中率設定，就變成了給出基礎值，然後再做修正，並在這一過程中將AI的命中率拉回一個平滑的狀態來最終滿足我們的PVP對戰需求。寫策劃案的我們，難免會各式各樣的需求中觸及自己的知識盲點，但是多跟身邊的專業人士請教，在網上搜尋資料，也許就能站在行業前輩的肩膀上來解決問題。
一份策劃案，人人都可以寫，但是你對設計方案的呈現方式，你對設計細節的把握，小到在優化過程中多一個和對接需求人同步的步驟，在策劃案中增加一個目錄供人查找等等這些技巧，都關係著這份策劃案的成敗。而對於剛入職的新人策劃，設計方案的需求過程都是提高團隊成員對你認同感的打分過程，如果你連第一關都過不去，那麼在之後的工作裡就可能會漸漸失去主導一個策劃案的機會，只能負責其中一個模塊，甚至是陷入永遠在做執行的窘境。
進階標兵 推動執行
我們繼續看一個新的例子，在上一個階段，我們完成了策劃案的編輯，Leader拍案叫好，我便拉上開發開始分需求，做玩法，對接童鞋給了答覆，沒問題，一個月搞定，我記下來，一個月後看成品。等到某天Leader走過來問了一句，進度如何了的時候，我便照搬了程序給的答覆。於是Leader眉頭一皺，我才發現事情沒那麼簡單。
這種情況不是個案，而是發生在很多策劃的身上。有一些策劃同學習慣性的把推動需求執行這一任務劃分到PM的負責範疇，認為策劃只負責最終驗收。但是，這種情況下，最終的成品可能因為策劃在執行過程中的長期缺失而變樣，所以我認為，策劃在需要在需求被執行的過程中主動地推動，跟蹤進度，而這並非意味著你需要每天去催需求進度，逼著開發把四十米的大砍刀拿出來。
（一）準備
1. 兵馬未動，糧草先行：前面我們也講過，策劃案的編輯過程中我們需要預先設想可能面對的問題，而在開始執行需求之前，你同樣需要關注這個需求的實現基礎能有一定的了解和預期。這包括你在引擎，架構，動畫，特效，動作，音頻等等方面進行惡補，作為策劃的你需要擁有足夠廣的知識面。
因為只要當你對這些方面有足夠的了解，才不會產出一個天馬行空的需求，有人會質疑這是在扼殺創意，但實際上，這是在幫助你的創意得到落地的機會。比如你提出的需求裡需要一套技術方案，那麼你需要提前了解一下這套方案能否實現，能夠實現到什麼程度，以及原因。
紙面上的策劃案不可能涵蓋所有問題，所以這是需要你跟對接需求人提前確認的點；再比如，開發周期的問題，一個足夠有創意，可行性高的策劃案，最後因為開發所需周期過長，無法趕上線節點的憾事，便是可以通過提前的溝通與了解避免的。
2. 心中有底，從容應對：開工如開戰，當你拉上程序，美術來組成一個策應組，開始做需求的那一刻，也就是整個開發小組對策划進行打分的時刻，你的策劃案，你的講述都會影響開發小組對你的認同程度。這也是為什麼我一直在強調知識面與預設問題的原因，因為當你完成對策劃案的演示過後，才是戰鬥的開始。
程序會追問你編輯條件的細節，而美術則會針對需求中花裡胡哨的表現效果提出底層架構不支持等等質疑，而如果你完全沒有防備，天真地以為這些問題都是專業向的，與策劃無關，等到開工會上被提問時才一臉懵圈地給出：這個問題先放後面/我不知道等等這類型的答覆，那麼開發小組的成員就會對形成一種心理預期，這個策劃連基本細節都沒有理清便要開始執行，未來的返工是必然的，浪費我的才華與時間，扣分。
所以，不要認為這些條件框架是在扼殺你的創意，因為如果你在美術，程序面前碰了壁，得不到他們的認同，那麼你的需求就不會得到100%的執行。再進一步講，當你的需求對於開發小組的童鞋來說是一個挑戰時，你需要有足夠的專業知識，來支持你說服他們，接下這個挑戰。
（二）興趣
1. 提煉賣點，興趣參與：工作不僅僅是工作，進入遊戲行業的人或多或少都保有遊戲的熱愛，但在經過一個個項目的需求洗鍊後，難免會出現對相似需求的厭倦。所以在推動執行的時候，作為策劃，你需要充分的調動這種開發小組的積極性，你要有足夠的忽悠技巧，提煉出這個需求的挑戰點與創意點，讓程序有興趣來主動地實現需求。
比如此前為了吸引身為暴雪重視老粉的程序大佬，化身標題黨，將一個技能編輯器的需求文檔起名為：「超越魔獸的技能編輯器，牛不，趕緊過來完成曠世功業！「，雖然拉穩了仇恨，但無疑成功吸引了程序老哥的全部注意力。當然，這裡所舉只是我較為浮誇的忽悠方式，但道理是相通的。
2. 拉攏實現 過程參與：每個團隊的情況不同，但大多數情況下，在策劃提完需求之後，程序和美術只負責實現，而最終的驗收成果只由策劃負責。這一過程中，我建議作為牽頭需求實現的策劃，應該找到恰當的時間節點，將開發小組集合到一起，在小黑屋裡一起體驗實際的demo，無論是為你的成果驗收提供新視角，還是提高團隊凝聚力，都是絕佳的方式。
（三）同步
一個技能編輯器的需求，在策劃的想像中，應該是可視化，可隨意組合搭配，且編輯效果即時可見的。而最終程序給出的編輯器成品，是英文，技能只可單個編輯，且效果需要運行Unity才可展現。也就是說，你提需求時所要達成的目的大打折扣，這個需求廢掉了。所以不要想當然，策劃在開始推動需求之前需要與對接人溝通並對未來效果有一個預期，而不是等到成品出來才發現偏差過大。
再比如美術，當你找了一堆酷炫的圖片或視頻擺到美術面前做參考圖，說這個需求要達到這種效果，而美術跟你說，好，我評估一下。這個答案新人策劃可能會理解為美術說可以，但實際上他可能已經在心裡打折了。策劃的參考圖≠美術的心理預期。
尤其是特效，由於製作流程的原因，特效的完成時間幾乎是排在開發周期偏後的時間段，而如果等到特效成品出了才發現有問題，想要搶在時間線前進行優化或者重做顯然極度困難。所以我的建議是，不僅是需求方要給出參考圖，也可以要求美術給出他的預期效果圖，不一定要花費很多時間畫一張效果圖出來，美術也可以從網絡上找出一張他認為能夠達到的效果圖或者視頻，只要雙方都有具體圖像作為依據，策劃也就能了解需求的美術表現是否能夠合格了。
在開始實施需求的階段，策劃面對的是整個開發小組的成員，而方才總結的幾個技巧，也都是為了在推進過程中，保證需求的不偏差。即使大部分研發團隊都有專門的PM來負責排工作表，規劃每日的開發進度。但是對於策劃，作為需求最終的驗收者來說，以周，甚至是以天為單位，與你的開發小組進行溝通，同步的做法，無論是對你個人，還是對團隊成員來說，都是每天一小步的上升和認同過程。
獨當一面 問題處理
策劃案寫好，需求實現完，恭喜你已經初步獲得了團隊成員的認同，但你做出來的東西，用戶是否買單，才是對你工作的最終評判。當一個玩法上線後，再完善的設計在面對大量用戶的體驗後都有遭遇滑鐵盧的可能，所以這時我們來到了第三階段，考驗的是策劃的問題處理能力。
（一）篩選
一個玩法上線，就要做好面對鋪天蓋地的吐槽。首先，來自外部用戶的反饋，因為用戶屬性不一，對玩法的看重點不同，所以沒有任何事情是完美的。其次，是來自項目組內部成員的意見，包括運營，程序，甚至是從Leader層給到他們對未來玩法的優化方向。所以如何平衡「眾口難調」的問題，讓大多數用戶能夠滿意便是關鍵。那麼，究竟要如何從海量的玩法反饋中去偽存真，快速定位問題呢？
基本上所有玩法系統上線時都會提經分需求，經分細節呈現因人而異，而拿一個PVP戰鬥系統為例，當時的經分系統主要涵蓋了如圖所示，三個角度下的細分數據。而這些玩法數據的收集，因為在遊戲上線之後，玩法的改動基本上除了一些能夠通過熱更新或者緊急修復解決的BUG修復，優化更新都需要一定的周期，所以經分系統有助於我們快速地定位問題，甚至通過數值編輯，比如匹配區間，產出獲取等調整來響應玩家的反饋，提升玩法滿意度。
（二）把握
下一步，通過將經分系統的數據與玩法上線後的一系列反饋，包括玩家調研，來自Leader，運營等等團隊成員的意見進行交叉對比，策劃便能夠對整個玩法上線後的情況有一個全盤的了解。打個比方，在一次新上線的PVP系統調研中，玩家對生化人威脅程度的投票顯示為適中，但是通過經分系統，我們卻可以看到數據反饋是生化人的威脅較大。
這種看似自相矛盾的結論其實很常見，因為調研很多時候收到的只是一小部分玩家的反饋，給出的是個人的直觀感受，而數據便是以科學的方式給你拉取出了所有玩家的平均水平，兩者缺一不可。
（三） 聯繫
所以我們需要做的是，將片面的問題聯繫到玩法整體來觀察，拿PVP玩法來說，便是看局內聯繫。上面所舉的例子中，殭屍是一個實際威脅，而玩家在面對威脅時，總共有3個要素在影響他的PVP體驗，首先對抗生化人玩家需要武器裝備，如果玩家初期沒辦法快速獲得裝備，就是前期失敗的主要原因。再來，玩家有野外的威脅，也就是當開局一段時間，天黑之後，玩家呆在戶外時，壓力值會不斷增高，對你的身體造成一些不良的反應，進而導致失敗。
所以玩家一般在壓力值的逼迫下，只能尋找房屋來避免壓力值的攀升，而夜晚還有生化潮的威脅，也就是大批生化人的圍攻，它們的襲擊目標則是以待在房屋內的玩家為主體。所以策劃在看待一個問題反饋時，不能單憑數據中顯示遊戲對局前期失敗率高，就判定遊戲難度高於預期，而是要聯繫玩法整體來看，看是生化潮刷新頻次過多，還是壓力值的攀升速度過快，又或者是裝備投入的不足。
否則，盲目地根據玩家的反饋對遊戲做改動，又或者是單憑數據便開始對玩法做加減，勢必會引起新一輪的吐槽。
在第三個階段，策劃要做的是在玩法上線後及時地跟蹤數據，進行分析反饋和推動優化，而當項目組的成員看到你在處理問題時的能力後，整個項目組對你的認同感自然拔高，覺得這個策劃的靠譜程度又一步提升。
坐看全局 提煉總結
最後，進了全局觀的樹立階段，策劃需要能對一個遊戲進行整體的提煉總結能力，也就是說，拋開你負責的項目之外，你需要緊跟行業潮流，對市面上的遊戲有一個深度的了解，而不是玩了以後一句真香就沒有下文了。
有一些人分享應用文章，或者是這種寫這種分析文章的時候，十分詳細，從槍枝武器的類型數值，地圖大小再到復活機制等等全部應用點都羅列了一遍，這些應用點重要嗎？重要，但是如果你對一個遊戲的分析只停留在這一層面，那充其量只是對這個遊戲進行了統計整理，更重要的是，透過這些設定，我們能夠看到的設計思路是什麼？
拿《Apex 英雄》為例，這些應用點背後所體現的是整體遊戲戰鬥節奏，數值體系以及地圖設計理念，而你的分析目的，是關注於它這麼做的好處/壞處分別是什麼？
例如在我對《Apex 英雄》的體驗中，我個人的體驗總結是，它的戰鬥節奏是充滿爽快感的；它通過架構豐富的對戰手段，用數值系統提升了玩家的生存空間；它的地圖設計總結來說，減少了很多的迂迴，然後加入了區域分割的概念，它的核心體驗，對戰體驗是更加爽快，對戰手段更加豐富的，開放地圖戰術競技對戰。
而抓住核心之後要再深挖分拆到模塊，回顧他們具體的設計點對核心體驗所產生的影響，將整個遊戲的點線面串聯起來，如在《Apex 英雄》中，就可以分析以下3個模塊的設計點與核心體驗的聯繫：
復活機制：巨額血量的倒地盾、自帶復活道具的設計大大減緩玩家對戰死亡的代價，使玩家更願意參與戰鬥。
功能性效果：增加豐富的對戰手段，放大對戰體驗，擴展「探查、機動、惑敵、救助、防護、陷阱、分割戰場」的體驗需求。
關卡節奏：通過高遮擋的分割獨立區域，減少遠距離攻擊， 而在建築的設計上則減少了二重房間，並通過窗戶無法翻越的設定，來減少迂迴戰略空間，控制對戰節奏。
當然，這裡所提種種也只是個人的見解，但我所想表達的是，只有通過對核心體驗以及深挖模塊的把握，才能夠從整體上形成對一個遊戲的理解與分析。而閒暇之時多進行提煉總結，或者對自己玩遊戲時的體驗進行記錄，這個過程獲得別人的認同，或者磨鍊寫作能力都是錦上添花，最重要的是你自己在過程中收穫的遊戲理解。而如果你的文章見解能夠激發討論，與行業內的策劃交流彼此的視野看法，也是美事一樁。
結語
開這門課，寫這篇文章的時候，也想過，可能許多人會覺得裡面提到的都是日常工作中的一些細節而已，但是見微知著，無論是策劃案的編輯，需求的推動執行，上線反饋的處理還是看似無關緊要的遊戲分析提煉，都決定了一個策劃的成長以及團隊成員對他的認同度。
大家都知道的事情不一定都做得好，如果你做好了，做極致了，便是你脫穎而出的機會。文章寫完，如果能對剛踏入遊戲行業的你有所幫助，便是它最大的價值了。