【工作回憶隨筆 5】遊戲營運專員

失敗或成功時立即歸零，抹去挫折與傲慢

前言

應徵過程

實際上工

組織概況與職責

報到當時正處疫情時期，所幸感激小主管仍特地來公司協助，否則遠端新人實在可悲，不僅溝通困難，對於成員也一概不熟，甚至連文件都難以找尋或開通權限。該職位其實以 JD 來說屬於全區域網頁活動企劃但掛的是遊戲營運專員，主要負責規劃遊戲內外嵌的網頁營收活動等一條龍作業，當然還是需對遊戲內容、資源、概念與背後運作邏輯有所理解，不過這其實對我來說衝擊非常之大，原因有四點：

• 一是如同之前猜想的一樣，普遍代理商的營運業務是以 KPI 類別混功能性劃分，如拉人玩不無聊的、賺錢的、將前二者規劃放進遊戲內的，代表其目的是追求企業指標的最大化而非品質。
• 二是以往的分工並非一人獨力負責某項活動從 0 到 1 的流程，呈如上所述會有人規劃、有人協助溝通、有人寫規則公告、有人配置、有人測試、有人管全部活動何時與怎麼釋出、有人處理緊急 Bug、有人事後分析，當然二種方式各有利弊，但由後者轉為前者必然仍有著較高的學習成本。
• 三是原廠與分部溝通，俗話說的好，錢跟時間能解決的都是小事，前面二點頂多加個班就能搞定，但凡事涉及到人的都得絞盡腦汁，由於之前配有窗口角色協助公司大小事務運行（所謂地下 PM），但現在這點改由每位成員自行擔任，代表除了原本執行面的事務要火燒屁股外，外部人員的需求也會接踵而至，且源頭發起者通常都是原廠，外加分部也會對各種決策執行有所反應，因此如何權衡好各單位間的優先順序、利害關係與問題的應對處理也變得至關重要且窒礙難行。
• 最後則是粗淺如我，之前體驗時完全沒特別注意，沒想到營運策略還可以利用外嵌的方式將遊戲玩成這樣五花八門（到底產品主體是遊戲還是活動……lol）

網頁活動開發

具體步驟依序可為以下落落一長串：

• 啟動規劃 由於開發過程曠日費時，絕不是臨時想做就能執行，因此約二到三個月前，決定活動目的、資源的投放方式後，就要開始有初步構想並與原廠展開討論，發想方式不外乎可以是靈光乍現、參考競品或是其他產業有遊戲化概念的活動。
• 草案提出（Wireframe） 該職位最重要的一環，為了讓原廠、設計與開發能夠有足夠資訊進行需求與工時評估，此階段就必須撰寫並勾勒出完整的機能架構邏輯、流程圖、畫面呈現與預想配置表的「工單」，具體到像是介面上各區塊或彈窗的呈現、前後端串接須注意事項與可行性、活動流程的說明解釋 、Edge Case……等等，最重要的一點是有非常多在構思時你覺得理所當然要這樣做原因與現象等細節，都要當做規格來呈現並描述出來，而非讓設計或開發幫你思考。
• 開會宣講機能邏輯 讓合作夥伴都能理解該次活動內容並解惑其問題。
• 確認開發排期 同時方便安排設計提供呈現的時間，但有時會沒被排上，工作想做還沒得做，想不到吧！
• 細案提出（Mockup） 設計完成並提供實際除了正式配置外的美術介面呈現，來供前後端作為實作參考依據。
• 開會確認最終細節 以免前後途中有所認知差異或需求更動可以調整。
• 開發實作 過程中開發也會不定期詢問許多當初沒想過的細節，比方說流程、可行性、玩家體驗、介面呈現、Infra面等各式各樣的問題。
• 測試 開發 QA 會提供非常詳盡的測項供自身、前後端與營運進行檢驗。
• 決定獎勵內容與期望值 這步驟對於營運來說應該算是第二重要，由於大部分的活動不可能只有一個獎勵發送給玩家，必定會有許多遊戲內作為二、三級代幣或各式各樣的週邊資源與內容物，而這些品項又各自有其價值，就像決定麥當勞大麥克裡面的餡料配菜一樣，既要考慮其賣給消費者的價格是符合價值的，又要滿足成本控管（放在遊戲內就是避免通貨膨脹），來讓專案得以賺錢（放心沒有騙人）；同時此刻也會需要同步機制介紹與上述內容給各上線分部，並解決他們的疑慮。
• 正式配置 將資料、Assets、規則、影片、宣傳圖都調整成可以上線的狀態。
• 上線監控 這階段就只能自行覆驗、觀察論壇跟祈禱神明保佑了。
• （Bug 對應） 最不想發生的情況莫過如此，不過若真的出現影響玩家體驗的錯誤時，仍需皮繃緊來即時應對並處理好後續措施，詳情大同小異因此可參考上篇即可。
• 數據彙整 活動下線後需要將後台數據備份，並上傳至雲端資料庫，以供未來查詢之用，雖然講起來簡單但實際落地卻會遇到許多想不到的阻礙，一是負責協助者與機房散落世界各地分部，二是我們內部完全看不到實際運作過程，因此途中容易發生各種千奇百怪的技術或人為問題，而需要憑著經驗、思考邏輯來猜測，或找到對的人來進行疑難排解。
• 分析與報告 這也是與前二份磨練有著重大差異的所在，從面試過程也可看出這邊非常重視對於數據的判讀、邏輯推導 並根據上述兩者的觀察給出建議或提案，因此除了新人一開始要寫的新舊活動日報外，網頁活動週報也需燃燒大腦思考與幹些髒活，得要先從各大平台與資料庫中汲取出所需要的資訊，譬如節點或 DAU 等上級指標、資源背景（使用率之類）、活動規劃與配置細節、付費率、ARPPU、社群討論……等等，部分也需利用較為複雜的 SQL 來撈取，接著再根據TA、機制、策略、指標、數據、資源等不同面向與架構來完成分析與建議撰寫，以作為下次提案時的參考。

網頁轉 In-Game 活動

由於相較遊戲內體驗比較起來，網頁仍會有些許斷層、介面呈現與轉換率流失問題，因此在上線效益良好後會額外開發轉為 In-Game 機能方式結合，並將網頁改為嘗試或應急的方式運用，整體流程與網頁開發形式相去不遠，不過分工方式會因組織合作與分部的職責不同而有所改變，首先如上所述我們通常只能決定規劃面而無法碰觸到實際設定，再來需結合遊戲內的更新與開發流程（類似上篇的分支管理），使其更為複雜且拉長並提前時程，而接回我們能測試與調整時已是非常後段了，因此不論在實作或溝通上都需花費額外的溝通、時間與學習成本來進行。

全區資源規劃與活動對接

除了上述兩項業務外，仍有許多非大型獨立活動的遊戲內品項需要被規劃與投放，而這段跟網頁活動部分一樣，在二到三個月前就得開始與原廠討論，並需要事前確認各資源被放進遊戲的熱更或版更時程，接著則可決定何時上線及怎麼投放，確認定版之後便可同步詳細資訊與手順給各分部落地。

結語

若你在錯過月亮時低頭後了悔，那麼也將錯過群星。