換工作三個月了!!回顧一下

SHEN
Mar 6, 2022

--

不知不覺在新工作待了三個月了,我想應該算是有點心得可以分享XD 大概提一下新舊工作在各方面有什麼不一樣呢? 後續會提到有沒有那裡不適應? 學到了什麼新東西? 失去了什麼東西? 之後想要繼續往哪裡發展?

前半部分比較偏向個人想法,可能會比較沒營養XD 沒興趣的可以直接看後半,有特別講一下以前當程式人員時希望看到怎樣的企畫書,除了可以對應現在寫的企畫書,先自己噴自己一下Q_O 也可以作為大家討論的起點。

嗯,對,剛好有個機會轉成企劃了!! 感謝夥伴們給的機會Q_Q

哪裡不一樣?

兩份工作在調性上還有團隊管理成員互動上都有些許不同之處。

團隊組成:

之前待的是大公司,但若切成專案內的人數,差不多都是8~12人的團隊,但新公司的企劃比例相比以往較多(企劃大概是1:10 (舊)vs. 1:2 (新)xD);嘛,畢竟目前的專案產品還沒上線嗎?

開發模式:Scrum

兩邊都是跑Scrum,但還是略有不同。

以往跑的方式,

  • 規劃工項:會由主企、主軟、負責人從產品藍圖拆分出月藍圖,並每個月更新一次,更新後開月藍圖會議(全員),同步一次重點工項,目的是確保船上的船員想法一致,才會更用力划槳,以及讓排程總是符合市場現況。
從大藍圖提取出當月的重點項目
  • Sprint定義:每兩周定一次排程,並且估計時數,並設立階段目標作為檢核點,確保可行性。加入估計時數算是提前曝險,有時程問題可以及早發現。(以前真的常發生沒有先分析功能,不知道功能時間的情況下,又接了很多其他插件,導致功能跟不上版本上線的慘況)
把當月目標塞進接下來的兩周,保持兩周的視野清晰;再遠的變數太多,提早規劃也是等著被改。
  • 全員同步比較花時間,但是會有共同認知,比較不會出現問成員現在產品正在開發什麼功能,答不出來的狀況。

現在:

  • 規劃:類似前公司的做法,但比較不會有正式拉大家來檢視跟討論產品方向,去更動月藍圖,比較偏向同步結果。
  • Sprint : 每兩周一個Sprint,Sprint的安排應該是拆成兩個會議,大頭會議跟各組(企畫、程式)的成員會議,對於其他組的狀況會比較不清楚。
  • 節省時間,大家專注在自己的分內工作,對產品完成效率比較高,但成員對全局熟悉度比較低。

目前覺得在新團隊裡面的方式,可以有比較多的時間做自己分內的事情,對於正在熟悉的我還算不錯xD 而且負責人也會定期同步產品策略,有興趣的人是可以得到相關的資訊的,而大部分沒興趣的人即使主動讓他知道,也只是稍微有助於參與整個專案,有助於討論但CP值可能就不太夠。

除了開發模式,還有一點很不一樣,就是開發的心態。

開發心態:所以我說你這個功能能換金嗎?

兩邊的產品調性、正處在的生命週期不同,也影響了開發人員的思維。

  • 前公司的營收導向

由於已上線產品,部門時常都會更新營收數據給開發團隊,讓成員們對自己的開發有感覺。可以看出這麼做的影響,除了讓你的開發有感(哦,這個功能有幫助到團隊!!玩家喜歡ˊ ˇˋ ),但也容易讓整個團隊重心會放在短中期的目標(畢竟有年度、季度、月度營收、玩家消耗的壓力)。大家思考新功能的時候,會以"營收"、"留存"、”玩家資源消耗率” 此類的營運規格為導向去思考。

當然我想也有一部分是產品類型(博弈),以及當時企劃能量比較不足,而大部分人擅長的是銷售,所以變成這樣的風氣。

  • 現況的玩法微調期

對應到目前待的專案的狀態仍在開發中,有比較頻繁的體驗版本內容,對於遊戲體驗做討論,如何讓核心玩法更強,周遭系統的建立。一切團隊討論的方向集中在玩法怎樣更好玩、畫面顯示更明確、對新手更友善、長期方向的建立。

現在的討論很有一種同好們在讓一個產品越來越好,玩法更臻完善,體驗更好,我想這就是合作工作讓人愉快的事吧XD 而能夠在開發遊戲上做到這件事超讚的XD(以往比較常在討論軟體開發方式)

企劃跟程式的腦袋不太一樣?

還有一點很不一樣的,就是企劃職的工作方式與思路跟在程式職很不一樣。

  • 主要負責辨識開創。開創新規格,並且與現存競品做比較,很多需要釐清需求跟理解遊戲本體的功課要做。
  • 相較之下,以往寫程式通常會思考這功能的目標是什麼,合不合理,只需要做”比對”的動作,而不需要 “發想” 從無到有;儘管做企劃時也要比對專案需求、實作方式、競品作法,但費力的程度差很多XD 而且當腦中的現存想法沒有好實作方式時,會完全卡住阿QQ
  • 寫程式實做只要對規格去思考實作的架構,而在軟體工程上已經有無數好的架構可以參考,相較之下企劃的工作好像就沒這麼方便了?(當然一部分也是程式架構模仿是學習,企劃照搬是抄襲吧?xD)

一些Mermer : 自認自己算是比較沒創造力的類型XD 從小對於繪畫、音樂等等就很不在行,寫作文也是論說文比較強ww 後續的教育也是軟體類的研究,很習慣做分析這件事情。

所以現在做起功能也會依賴碩士時的那套 分析世界上現存的相似架構→釐清功能原因→比對現有需求→基於現有架構改良。要無中生有真的難xD 雖然我覺得創作這件事情就像做料理,腦中要有對於食材的品味,才能在想做出特定味道時,信手拈來以及調整出美味佳餚。所以要做的事情一樣,除了精進現有產品類型的理解,後續也要持續品味跟累積對其他類遊戲機制的了解,總有一天會用到的吧(?)

還有一點想提xD這次的經驗才讓我感受到,工作環境對於成員互動乃至於情感培養上會有很大的差異:

成員互動

前公司因為大家被綁在一起的時間很長(吃飯去公司餐廳、加班算是常態),很自然地會比較多互動機會,而公司也提倡多交流,所以文化加上環境使然,成員間的交流很多,熟得也很快。現階段的工作正常上下班,午休也是在自己的位置上吃,成員間的互動落在日常的閒聊、合作,稍微比較少。

培養感情相處的模式,不外乎是那些彼此有共通興趣(一起玩)、共通合作的機會(交流技術之類的)出現時,會變得越來越熟,越熟識就更有機會觸發羈絆技能(咦?),解鎖額外討論;團隊信任度高內聚力強,越能讓人說出心裡話以及對產品的真實想法。反過來說,氛圍不好的時候,往往對產品的想法就會被隱藏起來,很多點子、被發現的問題就在不知不覺間被埋藏了。

澄清一下不是覺得加班本身很讚XD 只是在闡述增加相處時間,某些程度上確實讓成員間的互動有可能發生,現在的工作也只是需要更多的時間跟額外的創造機會,才能達到類似的團隊內聚力吧。

哪裡不適應

  • 說實在地剛開始最不習慣的是下午一次性的要持續工作五個半小時且比較晚xD 所以剛開始下班前就餓了(?) 也會下午比較早疲勞,要調整一下作息。
  • 還有企劃工作上,會開始用一些以往比較不常用的工具,之後再開一篇整理常用工具分享吧XD。

學到了什麼新東西

  • 用google apps script去操作表單xD

這次在處理多語言的時候,嚐試把一些很繁瑣的轉送翻單的過程一鍵化,初次嘗試雖然碰到不少坑,但能消化掉一些機械時間挺不錯的xD

  • 了解企劃寫規格書裡必要的內容
  • 使用表單去規劃一個系統實作配置的經驗:

以前大概想過會把技能、設定等等列成表單做紀錄用,但從來沒有實際看過跟程式結合的狀況(以往大部分都是寫在程式裡,極少另外用表單)。

  • 遊戲內資源配置的思考方式:

怎麼去定義這個系統可以給多少資源這件事。

之後想往哪裡發展

  • 更熟悉當下產品的genre know how,並且持續惡補企劃應該具備的廣泛知識,畢竟這是基礎XD在想要往什麼方向特化時會用得到;
  • 雖然還很遠xD參考Gamker的職業介紹之後,希望可以做到類似設計總監的工作xD對於遊戲設計的機制足夠了解,進而能夠在遇到敘事需求的時候,大致了解哪一種Genre或是遊戲機制,可以體現出敘事。大概是認為遊戲跟小說、電影、漫畫一樣,都是表達的手法;而遊戲又可以同時具備小說、電影、漫畫的呈現(文字、音樂、圖像視覺),某種程度上應該可以表達得更好XD(但要會的的東西也太多)
  • 敘事編劇: 把劇情用遊戲的技術力表示。(編劇,是上帝視角)(敘事,影響遊戲體驗與氣質)必須對遊戲、開發方向了解!以及一點敘事的能力
  • 設計總監: 和創意總監配合,考慮是否能實現,如何實現。可能需要管理每個設計師,理解創意總監想法,傳達給別人

接下來是最後一個Part

當程式人員時希望看到怎樣的企劃

這部分偏主觀XD我也沒有找程式人員討論過,有點可惜QQ總之以下就以我個人的經驗作分享。

回想以前做過的功能:商店批量選擇介面、背包系統、3D技能特效、怪物表演演出串接、Rank系統、道具蒐集活動系統…在實作的時候,第一怕的是規格被砍掉…心情會很複雜lol.. 第二怕的是實作到後期,才出現需求,而這個需求會根本性地影響開發(原本沒有說要做擴充,突然說要,會很影響開發時程)第三是難以解讀的規格書,要耗費很大的時間成本。

被砍的規格

期許自己做企劃的時候,至少要確認這個規格的存在必要,而不是做出一個自己也不知道要幹嘛的規格給程式、美術(聽起來很荒謬,但很多需求被提出來的當下大家都會認同,但實裝前,才發現根本有問題),最後因為需求不符遊戲被砍掉xD 被砍掉不是問題,因為需求會改變,所以一開始就要確認需求存在是必要的再去做,企劃也是最能阻止這狀況發生的吧。

當然很多東西要實裝才能有體驗,有體驗才能真正辨別是否有用,這種狀況是無法避免的。可以改善的是,以往開發經驗會出現那種人來瘋的功能,去仿造其他競品;但實際與本體調性不合,最後效益很差。

我褲子都在試穿了你才跟我說要加拉鏈(?)

這種,一開始的規格就要考量是否會擴充,因為在實作上的難度跟估時上會差蠻多的XD 也要盡量地減少程式實作時才發現沒考慮到的情境,產生額外來回甚至動架構的成本。所以會把需要的盡量都先考慮到,目前統整地方向如下:

  1. 正常觸發新功能流程
  2. 舊功能配套流程
  3. 數值確認
  4. 特殊狀況相關(0值、初始值、邊界值等等,也可以參考UI的六個狀態)
  5. 例外狀況相關(網路、幀數異常)。

難以解讀的規格書:

以下先不討論前後邏輯落差,文字編排等等的撰寫細節或是問題,單就以程式人員實作的邏輯,去猜想怎樣的規格書是好的。

以前在實作程式面的時候,最需要聚精會神的是列出所有需求、UI,並且構築每個UI的流程,並確認創那些腳本來負責UI呈現、系統資訊傳遞;要能夠輕鬆做到這點,就要讓 文字→條列需求→分門別類→ 資料流、邏輯流程→ 定出腳本,這個流程順暢。

而我想企劃能夠幫忙做的,應該就是把功能聚類、邏輯流程繪製好(發想期就會做的事情),並跟闡述與解釋性的文字獨立在不同區,方便查閱,簡化程式人員從分散的文字聚合成架構的時間。再更了解遊戲運作的話,頂多到資料流程也幫程式想好,知道哪個系統掌握著哪些資料,接著就交給程式們選擇想採納的設計方法了。

總結

現在回頭看,很難想像我現在會在這裡,感謝周遭的朋友與機會,當然還有持續地一點一滴想改變的想法與行動xD 只是沒想到會在這種時候匯聚在一起就是。

希望接下來的日子,可以更穩定點XD 克服規劃總是比實作的多這件事lol 有聽聞之前同事們會互相下班督促,覺得厲害xD最近自己因為上班本身就有從事設計相關的發想,反而不像以前有種上班不能做這件事,所以下班會格外想去做的慾望。

之後再來整理跟分享學到的東西的細節XD 把那些支離破碎的回憶統整起來,化為自己的力量,最後做分享還蠻不錯的。

對,我要去把支離破碎的法環復原,做成大盧恩化為我的力量去了(???) 下次見~

--

--

SHEN

一位遊戲從業者,寫了幾年程式轉行企劃中!! 一個偶爾整理跟記錄自己的想法的地方。