[一年回顧] 我的企劃學院
前言
Wow，不知不覺成為企劃人員的時間過了一年，一旦進入埋頭苦幹的狀態，時間流逝就變得特別快。
在前公司擔任遊戲前端程式人員時，也有過這種階段，可能是全力開發某個功能，可能是遇到瓶頸因此全力尋找解法，這種狀態就像是跑步的全速衝刺、排球的速攻一樣，有很強的爆發力，但眼前的視野會被限縮，此外也缺乏反思，會導致看不到缺失，導致進步的緩慢，往後遇到類似的問題，很有可能再犯，或是忘記當初的技巧，這就是為什麼我會想要重整一段時間的復盤狀況，還有會有寫日記的習慣xD。
做這件事情也是對自己的一個承諾，在起跑點比別人慢的時候，只能更努力了。
那麼這一年，我學到、得到了什麼、遇到的挫折，跟我想像的有那裡落差? 未來呢?
希望這篇文撰寫完畢後，可以整理好這陣子觀察的小結，同時也給對於企劃新人生活陌生的人一個參考。
一、學到了什麼
以下是這一年來的第一次及工作常做的事，給對於企劃生活不清楚的人做個參考！
1. 表單配置、創造的細節：
企劃人員透過表單跟程式人員溝通，關卡、技能實作、表演動畫的參數，都可以存在表單中。其中常見的能力需求是
* Excel 公式處理：減少手動填表錯誤、加速填表等等，越熟悉可以讓整個運作效率高很多!有更多時間可以在設計上。
* 資訊的最簡構成方式：很像程式人員在建構功能時，會思考怎麼拆分類別，哪些屬性(Property/欄位)要放在同一個類別(Class/表單)中，讓人看到表單名就可以跟欄位資訊完全對上（看了欄位就知道這表單在幹嘛的），也減少相同功能卻分布在多個表單的狀況。
2. 設計關卡、系統、介面的流程：
這一年來設計了一些介面、非同步對戰關卡的擴充，基本上發想的過程遵循了同一套規則。(算是目前的範本分享)
上述的範本算是前中期時建立起的思考流程，不知道其他人員是怎麼製作的?也期待其他人的回饋。
3. 玩法調校：
在周遭這麼多好玩遊戲的情況下，還是要重複遊玩/品味自己的遊戲，真的是很困難xD 人對於新奇事物的慾望總是比較高。但這卻是必要的。
不沉下心來，針對某個歷程作體驗，是很難得出玩家實際的挫敗感、不便的原因是什麼，可以怎麼減少與優化。
比較實際的作法也許會需要分工，說實在的，遊戲在調校期的時候，經常會有很多改動(某個關卡的規則調整、戰鬥機制、或是新手階段的調整)，而改動所影響的歷程可能很長，要一個人在時間內將所有有影響到的歷程都體驗過很困難，但如果是讓一個人體驗新人階段，一個人體驗七日~十四日階段的玩家，也許細碎化並分配後是有機會更全面的體驗的。
4. 資訊傳達的重要：
最早的時候，完全不熟悉給予美術的需求需要到多細，怎麼樣的範圍才可以表達我想要的，同時又能讓美術人員發揮專業，做出超出我想像的畫面的成果？
最早的時候給到太細，美術人員表示他們會設計細項、色調，形狀；調整了版本後給得太少，沒有足夠細節，沒辦法下設計的決策，後來統整的資訊如下：
- 畫面的目的(why): 為什麼要做這個功能，有了這個資訊，以下2,3,4有缺失時，美術人員才可以協助補上跟發現問題。
- 因此而生的視覺優先序(how)：基於1.定義出優先序，可以讓美術知道、檢視設計出的畫面是否偏離目的。
- 視覺拓譜關係(how)：有了拓譜關係，美術可以快速配色、配圖，得出示意畫面，而不用基於2.去設計。
- 顏色、特效細項功能(what)：這部分則是基於個人經驗，企劃自己的建議方向，算是讓美術人員沒有靈感時的參考方向（好的可以採用，壞的當作反指標避開ｘＤ）
目前只在一個團隊中合作過，但我認為這些標準應該會因應團隊合作的方式不同而有需要微調的方向，所以還是跟合作對象討論一下，哪些資訊可以協助他/她製作。
二、企劃生活:
這次有幸跟企畫團隊成員們一起合作，有近距離觀察業界前輩的機會(??)以下記錄一些很有印象的點。
身體力行的"多玩遊戲"與討論
就像廚師要多吃不同料理，企劃也要多玩遊戲，基本上已經是個常識了。但這次在午休時間實際看到前輩遊玩不同的Console/Mobile 遊戲，跟團隊一起討論玩法，才有了實感xD
儘管不是很有系統的分析，但這些點點滴滴交流，除了構成默契外，也是與產品對照、反思的腦力激盪的機會。
營造出討論的風氣無形間是讓整個團隊進步的方式呢。
接受意見
傾聽別人的想法還不算太難，但如果是針對你的挑戰或質疑呢?
以往做程式時，這種經驗還比較少一些，比較多發生在code review(也就是很少做的事xD)的時候，但有幸前公司的合作人員大都人很好(大概只有10%的時候會遇到出言不遜的狀況XD)，都能學到不少東西。
但在企劃這裡，基本上時時刻刻都會要面對(短時間接收太多很耗心力QQ)。
最狹隘的定義，美術的專業是視覺傳達(皮)、程式的專業是實際建構可實作的邏輯(骨肉)，但在這些之外，大家都是玩家，對玩法有想法、創意的遊戲設計師，有這個認知的情況下，產品的設計就會經過更多人的檢驗，對產品來說更健康，但對企劃來說壓力也更大XD。
看著更有經驗的前輩們，遇到程式、美術人員與自身相左的提案、建議或是批評時，還是可以沉住氣，給出適當的回應，果然很厲害啊。
基本上，目前遇到設計上的爭議很多，小的從:道具飛入的速度曲線要怎麼做? 哪種"感覺"比較好?表演的華麗程度…大的從整個遊戲UI的配置想要調整優先序，更換主視覺要素都有。
主要決策方式會是以以下兩個條件做選擇
1. 是否符合客群為出發點的體驗的需求(這點我在對客群經驗不足時都是找主企劃討論求救lol)
2. 考慮製程成本。
當然也有很多時候是多種都可行且差異小的情況，這時候通常會先以企劃的提案為主實作，測試階段時再做體驗觀察，確認要用哪一種(差異小的情況，更改成本也比較低)。畢竟在體驗還沒產生時，討論都不一定是準確的。
三、團隊合作方面
這一塊幾乎停滯，也沒去開發Asana, click up的新用途。(Asana的timeline不錯，一人付費即可用；click up 則是需要每人付費才有Gantt圖)
目前的運作方式，同之前的分享有提過，由組長拉組員的時程，並且大部分的改動也是由組長處理，也就是管理層在調整時程時很方便(不需要等待組員更新)，但是長期下來比較容易會漏東西(漏東西難免，但成員的自我管理沒有相關的SOP配套會更容易漏，或是需要額外確認的時間)
所以管理層級的人會花很多時間做工項整理，優點是成員不需要費心，可以最大化效率在工作上。
缺點是，當成員的不太會自我管理，長期下來，當人員多、工項多之後，管理層級的人會負荷的管理成本會越來越大。此外，成員自己對於工作效率等等也會比較沒感覺。
什麼時候適合用哪種?先試著從不同面向去分析看看：
小團隊：
人數少，基本上不太需要什麼管理技巧，兩種我覺得都可以；只是求快的話，交給負責人管就好，不需要有教學成本，一肩扛起管理成本也沒關係。
大團隊:
1. 因應人數，更需要儀表板總覽、每個人自我更新；想辦法把時間成本投資在總覽、評估、調整，而不是在幫大家update儀表板的資訊(比如工項的完成百分比、時程是否需要變更，都需要成員自行更新)。
這樣想一想，自我管理基本上避免不了，尤其是遊戲開發團隊，常常管理者也需要兼任開發，管理者的時間也很寶貴。
但實行上困難不少，要讓成員習慣新工具、流程，往往會有陣痛期；但過渡後，對於管理者來說可以更輕鬆，成員們也會學習到新的工具以及自我管理的方式。
中型團隊:
介於大小之間…基本上就是管理者吃下成本之後，會覺得有點累，但還不至於出大問題的程度(我們現在的樣子)。
無論要選用哪個方式，重點還是要透過實際運作，並持續觀察並迭代做法，減低每個人交流、管理的成本，才能達到最好的平衡狀態。
四、程式方面
這個部分雖然當初希望可以研究專案的系統，但實際上沒什麼太多長進，光時企劃專業的部分就自顧不暇了lol。
但還是有接觸到了一些內容：
1. Google app script
透過程式將重複性的操作一鍵化，包含:
- 多語言表中需翻譯的導出文件，並在翻譯方翻譯完畢後，一鍵導回(包含色碼與特殊符號處理)
- 關卡配置：配置關卡時，發現只要將id規則訂好(真的很重要)，大部分不同的關卡，只是因應不同配置做id轉換而已，便可以將想要的關卡屬性輸入，一鍵生成關卡配置(以前要擴增欄位、貼上資料、更改id…，當一次需要新增七八個關卡的時候會很累)。
做為新人，覺得可以節省前輩們的時間實在是太好了，算是對整個團隊最有產值的地方(??) 希望讓大家有更多時間把規格用得更完整!!
2. sql lite + FineDB: 透過FineDB去撰寫Sql語法，從tiDB的資料庫中，將玩家資料選取、篩選出來，並導入FineDB的儀表板，得到留存、新手教學等等的數據儀表板。
這個就是意外接到的工作了，算是以前碩士有資料分析的經驗，額外承接到的項目，算是有個自己透過工具製造儀表板的經驗，也是不錯。
五、挫折
規格很難一次到位（漏掉的需求、變更的方向）
時常在企劃案撰寫完，進入發包會議階段與美術/程式人員討論規格時，甚至是實做中才發現，少考慮到一些例外狀況，比較嚴重的還有成員對於規格方向有意見，可能需要做大改動的。
實際參與幾個案子的討論後，發現這幾乎是難以避免的，原因可能如下：
原因1. 對於目標客群的理解落差：
比如我比較缺乏休閒型玩家 社群分享的理解，在製作玩家資訊頁面，使用了皇室戰爭的模板做為架構基底，就被質疑過資訊過多。
最初的版本想法比較簡單，帳號資訊頁的定位跟市場上遊戲相同，讓玩家可以查看歷程與紀錄。但經過發包案討論後，認為休閒玩家喜歡精簡一點的，並且這頁"宣傳"、"截圖分享"，因此最後參考常見的心理測驗的形式，將玩家的歷程由系統直接賦予玩家類型，並透過排名的方式，營造玩家的優越感與獨特感，並刺激分享動力。
原因2. 發包前未與實作成員交流、討論
在撰寫規格書時，因為沒有跟實作人員交流過，所以可行性可能會有所偏差，出現在會議時"這個暫時做不到"之類的狀況。在規劃時期，有不確定可行性的地方，就稍微請教一下程式人員吧，先簡單確認過，會比在會議中逆轉裁判起來更輕鬆XD
原因3. 需求出現變化:
也是有隨著時間、版本過去，對玩家越了解之後，原始需求產生變化的可能。雖然對於當初設定需求的自己很不甘心，但還是得面對現實，因為這樣做才是對遊戲最好的!
六、落差?
沒有閒下來的時候，你要靠自己學習
雖然在入職前就知道了，但實際體驗後，感受更強烈。因為其實沒有正式的”教學階段”，企劃的基礎大部分都是做中學、看著學，操作性的部分比較多，思維上的內容，大部分得靠自己補強。
尤其是忙起來，趕規格給美術、程式，或是發版本周的無盡測試地獄，都十分消耗時間跟精力xD!
作業感的日常
最早對於企劃的工作想像，常常認為是要去發想"新"的UI、系統，所以會時常接觸新東西，但其實還是有不少重複性的工作。比如關卡設計完畢、每個系統的多語言設計(成就系統的就很多XD)，都有填表作業；尤其是技能實作的時候，還要煩惱該以什麼邏輯串接起來。此外，由於之前的團隊沒有專職的QA人員，企劃也要負責QA自身的功能。
因此也常會有一整天都在表單裡面做事的情況XD
相對無趣的主題
另一個想像－－既然企劃很多工作是在發想新事物，應該不太會無聊才對，但實際上還是會有無趣的時候。
還記得入職一小段時間後，有被主管詢問過，後續比較想要執行哪一方面的設計?對於當時的我來說，經驗很少，因此認為不太需要挑，每一種對我來說都是需要練習、實踐過，而且幾乎都是要經過分析需求到產出落地方案的流程，但過了一段時間後，果然對我來說，設計UI、交互類型的，相對比較沒有成就感、枯燥一些。而設計新的玩法、關卡，或是調校舊玩法，則比較有動力且有興趣，也許這是個通則，但至少我在這次的經驗裡自身確認了這個感受XD。
七、喜歡這樣的生活、工作嗎?
這個問題也算是回應一年前離開程式崗位的自己吧。
我喜歡現在這種團隊參與度高、時常發想並接受質疑與挑戰的生活嗎?
儘管每次企劃被變更還是會感慨自身經驗不足，被質疑時也會覺得自己怎麼當初漏考慮了而懊惱，但同時也會有因為觀察到問題，並與團隊討論後，逐步優化後，遊戲變好玩的喜悅。
先說結論：當前階段是滿意的。
在這裡體驗了很多以往不會有的經驗，也認識更多遊戲業界的同仁，企劃的基礎也在這裡磨練到，即使有難受跟迷惘的時候，但周遭有很強的前輩可以請教，因此討論與工作上都很不錯。
我想基礎比較熟悉後，會開始缺乏一點挑戰感，期待自己的實力逐漸成長，可以更獨當一面，承接更高風險與核心的系統。
八、下一個目標是哪裡？上次的問題與目標。
經過了一年的學習，只能說開始進入狀況，一直在講的數值設計也只停留在修改體驗平衡的階段，還沒開始實際從0設計，接下來就從數值設計、玩法發想、自我管理、決斷力等等的基礎功加強，持續下個練習的機會。
同時也再次盡量地摸索自己究竟想做到什麼(設計總監? 做為負責人有個團隊? 又或者是持續地開發遊戲?)。
九、寫在最後
新的一年，從去伏見稻禾大社的荒木神社中的小吉籤開始：
一年下來，工作經驗讓我寫案、製表、傳達、製程思考上得到質上的進展，儘管設計的思維也許進步得比預期得少(要靠自己累積)，但這些都是以往我沒有的寶貴經驗，雖然最早我的目光都放在玩法辨識/創造上，認為這才是遊戲、企劃最重要的核心，但遊戲如果只有核心，是動不起來的，還需要骨骼與肌肉來讓核心帶動整個身體，基本功很重要XD。
再次感謝團隊跟前輩們給的機會，下次分享見!
ps. 寫完之後，還是覺得自己的文章架構有點亂…
