【工作回憶隨筆 5】遊戲營運專員
失敗或成功時立即歸零，抹去挫折與傲慢
前言
在前東家接了 OM 後約半年多，開始覺得少了一點什麼，當然事務與成員的掌握幅度變大很好、能照著自己認為正確的方向優化專案流程也好、也扛過各種重要節點並從中學習到許多眉角與責任壓力，不過由於像上篇所敘述的，雖然代工廠能夠控制如底層 Code、資料、Assets 等深層元素，但原罪即是七、八成規劃與原始資料總需仰賴總部跟發行商提供與決策，且為了如質如期提供優良體驗給玩家的代價即是工廠流水線的分工作業形式，大家為的終究是不要出錯而非讓產品更好，久而久之除了管理職外便會逐漸喪失自主思考與判斷能力，這與台灣普遍代理商決定規劃的型態其實相去甚遠，因此萌生出想跨出舒適圈並增廣見聞多加磨練（找罪受）的想法，也在前同事好心牽線下順利投遞履歷於另一間知名外商。
應徵過程
新東家的面試步驟相比少了一關，其他則大同小異，流程為課題→人資→部門主管→CEO（可能高階職位才會有總監層級），差別在於若有其他專案想接洽，在課題與部門主管那邊可能會重複數次（煎熬也是倍增），而人資關則只需一次，前後共嘗試了兩個專案，一個為當時未上市的研發項目；另一個則是跟原本所在蠻像的大成功老品項，兩個專案在課題與面試過程上也相去甚遠，前者課題為針對營收資源與商城活動進行與調整，這次記取教訓在除了舉列遊戲內容與解法外，更多了業界常在意的邏輯原因與人類萬惡根源 - KPI；後者則較屬執行面上的硬技能，需要運用 Excel 過濾出某檔虛擬活動中付費玩家、大獎玩家及各自的付費金額與加總，看似簡單的數學題在習慣用 SQL / GUI Tool 而久沒使用複雜公式，外加資料量龐大之下還真有點棘手。
費盡千辛萬苦與來回的電話溝通總算進入到面試環節，差不多的人資部分就不重複贅述，第一個專案為三對一，一句話形容只能說極度重視邏輯思考，問題相當生活化、多樣且不侷限於遊戲本身，比方說遊戲 KPI 為何下滑、遊戲內的營運活動或市調問卷具體要如何設計、給予特定條件的遊戲並分析數據下滑原因且提出建議等個案環節、甚至還問到電影上線時公司須考量到的點有哪些，屬於大名鼎鼎的顧問式考題，需要根據假設→數據→分析→驗證等流程來說明論述，電得思考跳躍的我滋滋作響，結果也不盡人意，不禁另人思考這三年的工作經歷是否一點用處也沒有……；反之後者氛圍與問題則輕鬆許多，形式為二對一（PM 又剛好又是大學長，再度體會到校名的重要性），大部分都是分享以往的工作經驗或與該份 JD 有關，譬如近期最有印象的活動操作、遇到緊急問題時的對應方式與態度等等，相談甚歡的結果許是錄取，也總算卸下心中大石，畢竟在面對工作壓力繁重的同時，仍須準備課題與面試，實在痛苦萬分。
實際上工
組織概況與職責
報到當時正處疫情時期，所幸感激小主管仍特地來公司協助，否則遠端新人實在可悲，不僅溝通困難，對於成員也一概不熟，甚至連文件都難以找尋或開通權限。該職位其實以 JD 來說屬於全區域網頁活動企劃但掛的是遊戲營運專員，主要負責規劃遊戲內外嵌的網頁營收活動等一條龍作業，當然還是需對遊戲內容、資源、概念與背後運作邏輯有所理解，不過這其實對我來說衝擊非常之大，原因有四點：
- 一是如同之前猜想的一樣，普遍代理商的營運業務是以 KPI 類別混功能性劃分，如拉人玩不無聊的、賺錢的、將前二者規劃放進遊戲內的，代表其目的是追求企業指標的最大化而非品質。
- 二是以往的分工並非一人獨力負責某項活動從 0 到 1 的流程，呈如上所述會有人規劃、有人協助溝通、有人寫規則公告、有人配置、有人測試、有人管全部活動何時與怎麼釋出、有人處理緊急 Bug、有人事後分析，當然二種方式各有利弊，但由後者轉為前者必然仍有著較高的學習成本。
- 三是原廠與分部溝通，俗話說的好，錢跟時間能解決的都是小事，前面二點頂多加個班就能搞定，但凡事涉及到人的都得絞盡腦汁，由於之前配有窗口角色協助公司大小事務運行（所謂地下 PM），但現在這點改由每位成員自行擔任，代表除了原本執行面的事務要火燒屁股外，外部人員的需求也會接踵而至，且源頭發起者通常都是原廠，外加分部也會對各種決策執行有所反應，因此如何權衡好各單位間的優先順序、利害關係與問題的應對處理也變得至關重要且窒礙難行。
- 最後則是粗淺如我，之前體驗時完全沒特別注意，沒想到營運策略還可以利用外嵌的方式將遊戲玩成這樣五花八門（到底產品主體是遊戲還是活動……lol）
網頁活動開發
具體步驟依序可為以下落落一長串：
- 啟動規劃
由於開發過程曠日費時，絕不是臨時想做就能執行，因此約二到三個月前，決定活動目的、資源的投放方式後，就要開始有初步構想並與原廠展開討論，發想方式不外乎可以是靈光乍現、參考競品或是其他產業有遊戲化概念的活動。 - 草案提出（Wireframe）
該職位最重要的一環，為了讓原廠、設計與開發能夠有足夠資訊進行需求與工時評估，此階段就必須撰寫並勾勒出完整的機能架構邏輯、流程圖、畫面呈現與預想配置表的「工單」，具體到像是介面上各區塊或彈窗的呈現、前後端串接須注意事項與可行性、活動流程的說明解釋 、Edge Case……等等，最重要的一點是有非常多在構思時你覺得理所當然要這樣做原因與現象等細節，都要當做規格來呈現並描述出來，而非讓設計或開發幫你思考。 - 開會宣講機能邏輯
讓合作夥伴都能理解該次活動內容並解惑其問題。 - 確認開發排期
同時方便安排設計提供呈現的時間，但有時會沒被排上，工作想做還沒得做，想不到吧！ - 細案提出（Mockup）
設計完成並提供實際除了正式配置外的美術介面呈現，來供前後端作為實作參考依據。 - 開會確認最終細節
以免前後途中有所認知差異或需求更動可以調整。 - 開發實作
過程中開發也會不定期詢問許多當初沒想過的細節，比方說流程、可行性、玩家體驗、介面呈現、Infra面等各式各樣的問題。 - 測試
開發 QA 會提供非常詳盡的測項供自身、前後端與營運進行檢驗。 - 決定獎勵內容與期望值
這步驟對於營運來說應該算是第二重要，由於大部分的活動不可能只有一個獎勵發送給玩家，必定會有許多遊戲內作為二、三級代幣或各式各樣的週邊資源與內容物，而這些品項又各自有其價值，就像決定麥當勞大麥克裡面的餡料配菜一樣，既要考慮其賣給消費者的價格是符合價值的，又要滿足成本控管（放在遊戲內就是避免通貨膨脹），來讓專案得以賺錢（放心沒有騙人）；同時此刻也會需要同步機制介紹與上述內容給各上線分部，並解決他們的疑慮。 - 正式配置
將資料、Assets、規則、影片、宣傳圖都調整成可以上線的狀態。 - 上線監控
這階段就只能自行覆驗、觀察論壇跟祈禱神明保佑了。 - （Bug 對應）
最不想發生的情況莫過如此，不過若真的出現影響玩家體驗的錯誤時，仍需皮繃緊來即時應對並處理好後續措施，詳情大同小異因此可參考上篇即可。 - 數據彙整
活動下線後需要將後台數據備份，並上傳至雲端資料庫，以供未來查詢之用，雖然講起來簡單但實際落地卻會遇到許多想不到的阻礙，一是負責協助者與機房散落世界各地分部，二是我們內部完全看不到實際運作過程，因此途中容易發生各種千奇百怪的技術或人為問題，而需要憑著經驗、思考邏輯來猜測，或找到對的人來進行疑難排解。 - 分析與報告
這也是與前二份磨練有著重大差異的所在，從面試過程也可看出這邊非常重視對於數據的判讀、邏輯推導 並根據上述兩者的觀察給出建議或提案，因此除了新人一開始要寫的新舊活動日報外，網頁活動週報也需燃燒大腦思考與幹些髒活，得要先從各大平台與資料庫中汲取出所需要的資訊，譬如節點或 DAU 等上級指標、資源背景（使用率之類）、活動規劃與配置細節、付費率、ARPPU、社群討論……等等，部分也需利用較為複雜的 SQL 來撈取，接著再根據TA、機制、策略、指標、數據、資源等不同面向與架構來完成分析與建議撰寫，以作為下次提案時的參考。
網頁轉 In-Game 活動
由於相較遊戲內體驗比較起來，網頁仍會有些許斷層、介面呈現與轉換率流失問題，因此在上線效益良好後會額外開發轉為 In-Game 機能方式結合，並將網頁改為嘗試或應急的方式運用，整體流程與網頁開發形式相去不遠，不過分工方式會因組織合作與分部的職責不同而有所改變，首先如上所述我們通常只能決定規劃面而無法碰觸到實際設定，再來需結合遊戲內的更新與開發流程（類似上篇的分支管理），使其更為複雜且拉長並提前時程，而接回我們能測試與調整時已是非常後段了，因此不論在實作或溝通上都需花費額外的溝通、時間與學習成本來進行。
全區資源規劃與活動對接
除了上述兩項業務外，仍有許多非大型獨立活動的遊戲內品項需要被規劃與投放，而這段跟網頁活動部分一樣，在二到三個月前就得開始與原廠討論，並需要事前確認各資源被放進遊戲的熱更或版更時程，接著則可決定何時上線及怎麼投放，確認定版之後便可同步詳細資訊與手順給各分部落地。
結語
其實由管理職轉為執行面成員的過程當中，不論是心態或實作本身都仍有其陣痛期存在，像是少說多聽多做、業務性質改變、對於成果的更重視與反思優化、內心懷疑決策合理性、流程 / 分工 / 溝通問題卻無力解決、既有人脈完全消失……等等，至今仍有許多習慣難以改變，但也謹記於心，總的來說依舊從這段旅程中拓展了視野並見識了強中自有強中手，也勉勵自己學無止境，既然選擇了就是自己的而別抱怨，繼續努力拋下過去在這條路上前行。
若你在錯過月亮時低頭後了悔，那麼也將錯過群星。
留言0
查看全部