【工作回憶隨筆 3】遊戲營運企劃

不是在通靈，就是在成為通靈王的路上

前言

應徵過程

不過現在回想起來該份分析報告整體寫得差強人意，應該可以更多著墨在提出個人觀察與建議上等獨到的見解，而非只僅僅陳述很多介紹事實或沒有邏輯脈絡所推導出的提案與結論。

• 首先人資關與其他公司大同小異，不外乎常規性的自介、個人特質、優缺點、有挑戰性的經歷、遇到難解情境時的應對……等等，有些問題會突然以英文進行（好險有所準備），感覺上是故意扮黑臉。
• 接著過了數分鐘後換部門主管輪番上陣，是二位人都非常好的 Project Leader，整體進行方式比較像聊天，會引導面試者回答到他們所偏好的方向，譬如遇到困難時可以找工程師協助處理而非埋頭自幹，也解釋這個職位並非填坑（雖然我是持懷疑態度……笑），並稍微講述了下產品的現況與定位，不過具體細節有點失憶，但大多不是太困難的問題，主要仍是想看面試者的態度、想法與做事風格。
• 這天最後只進行到營運總監，也剛好是同學校不同系的學長，風格也與上一關類似，不過較有挑戰性，層級大多拉高到策略面的思維，最有印象的一題是如果今天既有產品要切入新國家市場你會思考哪些面向。
• 又過了個年才面到 CEO，原因是他人剛好不在台灣才又拖了許久，二次北上就為了短短半小時，由於非台灣人也不會中文，因此整體由英文進行，非常健談，基本上都是他在講，窮緊張了……lol，主要看著我的遊玩清單提問些遊戲時長、IP（還提到他很喜歡灌籃高手！？），及旗下產品的一些建議等等，也稍微提到許多跟公司治理上的考量，決策上許多點都會影響到股東跟其他利害關係人。

實際上工

• 一是版更，會需等每次總部確認 Code Freeze 後，開始處理後續在地化與其他流程事宜，包含工程師端的代碼與功能調整、美術 Assets 處理、企劃測試資料製作、QA 迴歸測試、企劃撰寫版本規格書 及維運銜接。
• 二是維運，待上述版更流程都告一段落後，版更負責人、美術及工程師會將準備好的該版本 Branch 合入維運用 Branch，並完成維運前後端環境的升級，之後就會是我所負責的資料置入（有些被對面荼毒久了的公司會叫「配置」）部分了。

• Project Leader 會根據總部既有排程或商材規劃一張國際版大排程表。
• 接著 Campaign 負責人協同產出企劃書，內容包含了節點主題、施策目的、活動具體注意事項、涵蓋範疇(登入獎勵、角色、轉蛋、商品折扣、任務、獎勵兌換......等等子分類)、資料處理細節(id、關聯表單、參數含意)、美術 Assets 及 Banner 相關內容。
• 再來 Operation Manager 亦會開始根據企劃書與對照總部 Database 製作該次版更或 Hotfix 的部署項目規格書（主要皆為資料與 Assets 方面所用到的 id 與注意事項為主）。而後所有除了工程師與客服外的團隊成員（企劃、美術、LQA）都會根據這份排程、各企劃書與部署資料規格書進行後續落地作業。
• 此外，資料、Assets、公告則各有一位負責人處理職責內大小事務。

資料置入

終於回到本業身上，這部分又可分為許多細項來說明，一開始聽起來很抽象，而根本上的概念即是將好幾百張（你沒看錯，一個時間久的大遊戲就是會有這麼多）CSV 資料表中一格格有其代表含意的數值填好，透過 GUI Tool（當然夠厲害也是能用終端機……）Push 至 GitHub 上的 Repository，經過 CircleCI 的 Data Validation 檢查，並透過工程師的特殊魔法「部署 Deploy」將其轉置成 Code 進 Server / Client Database 並讓程式可以讀懂並順利運行，因此資料企劃需要有一定程度的 Git 操作邏輯與 Branch 管理能力（請洽為你自己學 Git），否則在不同排期的版更或 Hotfix、及各方需求頻繁更動之下，一直在 Excel 或 Google Drive 上單線操作不論人或遊戲必定都會錯亂而造成資料有誤。而根據入門程度通常會由時間設定→翻譯置入 →既有資料搬遷 →全新資料製作的順序依次實作。

那原始資料從哪來呢？不外乎兩者：

• 總部給，大約一半以上的機能表單的資料來源都由此類方式，這也是身為代工廠的原罪，而其中又分為到已釋出的總部正式資料庫自行撈取，及真的完全等他們給（實際執行跟測試絕對雞飛狗跳，不過後來也有找到辦法解決……笑），前者由於企劃書或規格書上通常只會有角色或關卡本身的上層 id，並不會有其他相關下層細節，比如一個角色或關卡可能會需要包含數十張表單的資料；而後者雖理想上只要根據總部下的 Tag 照表單跟對應位置複製貼上即可，但忙中有錯，難保確定每次資料源都正確無誤，因此無論如何都必須仔細研究並熟知各機能表單間的串連邏輯，以避免 Bug 產生，小則影響體驗，大則遊戲崩潰 : )。
• 自己做，這也是國際版有其價值之處，雖然可能有時受制於各方面考量，譬如體制、合約、玩家習慣，而不是所有公司或產品都有這個空間能自行操作設定面的權限，但這邊部分的規劃與機能是得以國際版名義與目的來設定的，因此可更符合市場偏好或根據期望來調整施策，不過有利必有弊，因此類作業也無法仰賴既有資料或總部外部的比對參照，對於負責人員來說就得更加了解每個數值所代表的含意，而不單單僅是知道表單跟欄位就能製作出符合預期的結果，所以就必須更加付出心力去翻找總部規格書、詢問資深企劃或工程師、並透過實際測試來體現實機結果。

導致這也有了副標題「通靈」的由來，當熟到一定程度後，看著奇怪的數值或 id 大概就能感覺到哪邊怪怪的怪怪的，從而避免後續一連串災難的發生。

提案相關

雖然上面有提到大部分的規劃方向主要都來自總部的版本，但也有提到國際版仍有部分的操作空間，因此在些許節點或補洞之際仍有機能或維運規劃上的提案機會與需求，譬如登入獎勵、轉蛋、折扣、任務、商店禮包、獎勵兌換，而這部分會先通過內部審核後提交給議價力較大的發行商進行評審，再決定是由國際版獨有還是總部並行開發；另一方面企劃本身也有除了專案外的事務需要分享，像是新遊戲創意提案、遊戲評測分享、專案業務或流程介紹等等，所以也算是有一定空間可以發揮一般外表認為遊戲企劃在做的事……汗。

資料撈取與分析

此外，總不能光做不檢討反思，因此 Bug 的改善措施、與節點或活動的事後分析也很重要，才得以檢測當前的流程是否有問題、及規劃或執行面是否值得，由於不是每間公司規模或體制都有資料分析師或資料工程師的專業人員，因此資料的查詢與撈取也是營運企劃技能樹的一環，而「SQL」便成為菜雞資料企劃的噩夢……，不過這僅僅也只是分析流程中的一小部分，層級拉高後看又可分為分析目標（需求）、假設、數據撈取、分析處理、驗證、建議與優化等步驟，坊間已有許多大神資源可以學習，就不在此多贅述，這邊也提供幾個實際牛刀小試的例子作為參考：

• 不同期登入獎勵領取狀況。
• 不同期任務完成情況。
• 不同期一級貨幣折扣力度表現。
• 不同檔轉蛋設計與表現。
• 不同檔禮包設計與表現。
• 不同獎勵兌換情況。

結語

那些殺不死我的資料，必然使我更強大！