nav分隔線 nav分隔線

聯成電腦設計好文分享:「奔跑吧!台北」網頁遊戲專案管理經驗分享​

icon_fb icon_twitter icon_google
聯成電腦設計好文分享:「奔跑吧!台北」網頁遊戲專案管理經驗分享​

文、詹致遠

 

 

最近把「北市府三週年政績報告」這個大魔王解決了,這塊讓我睡不好的大石頭總算放下。

 

這次專案分成三大項目:社群遊戲、政績網站、動畫,我在遊戲與網站都參了一腳,過程辛苦卻也收穫滿滿。

 

沒玩過嗎?遊戲在此~ https://game.glory.taipei/

 

奔跑吧!台北,玩過了嗎?

 

 

這次不怎麼下去寫 Code,管理的工作倒是做了不少,特別是遊戲部分讓我獲益良多!所以就花點時間整理這次管理心得,做個紀錄,說不定能讓新手 PM 少繞一些路。

 

先簡單介紹自己,我在簡訊設計擔任 RD Leader,主要做 Web 前後端開發與系統維運,有時會客串其他職位例如 PM。

 

這篇文章將告訴你這些事:

• 專案開始前:以過去的經驗建立管理基礎

• 專案進行中:導入敏捷開發來凝聚團隊

• 專案上線後:專案成果以及血淚心得分享

 


 

專案開始前:記取經驗,做好準備

 

公司在 2017/02 對外發表了「全能古蹟燒毀王」,是一款社會議題倡議的網頁遊戲,藉由遊戲化說明文資法與古蹟保存的困境,是一個不錯的嘗試。

2017 最狂社群遊戲 — 【全能古蹟燒毀王】

 

 

因為有燒毀的經驗,這次開發順暢了許多,依照上次經驗,我們注意到遊戲這樣複雜的作品,在溝通、測試這兩件事會花上很多時間,所以在專案開始前,我們先做了這些事:

 

1. 找對工具進行協作

 

先依照需求拆解出任務,只要需要兩個人以上協作完成的任務,就先確認:

• 由誰負責

• 由誰驗收

• 要交接給誰

• 用什麼形式交接

 

把任務想像是一顆一顆球,只要傳球得當就得分。

 

為了要確認「用什麼形式交接」,我們事前做了許多研究、尋找適合工具:

• 企劃使用 Invision 製作 Storyboard & Prototype

Invision 畫面

 

► 還記得G小編曾經介紹過:InVision簡化團隊工作的好幫手

 

 

• 美術使用 Aesprite 來製圖給動態美術

像素插畫軟體 Aseprite

 

 

• 動態使用了 Piskel App 製圖以及與工程串接

像素動態製作軟體 Piskel (圖源

 

 

這些工具成為我們的得力助手,讓遊戲開發事半功倍。

 

2. 改善團隊工作環境

 

「奔跑」期程正好碰上了公司人事成長期,辦公室空間短缺。從「燒毀」的經驗我們知道,遊戲專案需要大量的溝通與討論,我們租用了一間獨立的商辦,供團隊主要成員使用,同時舒緩原辦公室空間壓力,讓空氣更清新。

 

我們發現空間的重要性:獨立的工作環境讓更多討論發生,屬於團隊的白板使得靈感迅速成為方案。同時增加了團隊效率與成果質量。

 

3. 協作需求列為規格

 

開發遊戲最麻煩的地方在於,需要操作特定步驟才能看到想看到的畫面,這件事讓遊戲在調整期花費不少時間,同時在關卡難易度、遊戲節奏、對話用字等細節上也需要大量溝通。

 

因此,我們規劃了跳關功能,讓工程人員在架構程式時提早規劃。使得團隊成員可以跳過冗長的劇情,減少無謂的等待時間。

 

同時我們也製作了遊戲開發後台,供企劃人員設定關卡難易度,也供美術人員替換圖檔,即時看到成果,不假他人之手,使得創意能夠解放。

開發版本有場景跳關介面喔

 

 

4. 核心團隊與利害關係人

 

溝通是一件麻煩卻又重要的事情,溝通效率非常重要。

 

從「燒毀」經驗中,我們發現到,當專案相關成員越少時,開發的速度越快,專案成長得最快時,專案只有美術與工程兩人在專案內。

 

但做得快時,其他問題又產生了,當時常常因為行銷、企劃的需求而反覆修改,造成重工浪費資源。

 

因此這邊導入了利害關係人(Stakeholder)的概念。

 

此專案團隊有 11 人之多,但主要成員只有 6 人,我稱之為核心團隊,組成是企劃 1 人、美術 2 人、工程 2 人、管理 1 人,主導專案開發,負責達成專案需求。

 

而其他 5 人中,有 2 人是音效與工程協力,以提供產能為主。

 

另外 3 人是窗口、行銷、企劃原案,我稱這 3 人為利害關係人,這些人不負責專案開發,但需要定期與核心團隊開會,確認客戶需求、行銷需求、企劃策略是否達到,也提供修正建議供團隊參考。

「奔跑」團隊分布示意

 

 

這樣的團隊分工,使大部分的討論得以密集、快速進行,同時也讓各方需求不至於偏離太多。

 

註:我的管理工作只做到專案中期,中期以後太忙了由同事接手。

隱藏的團隊頁面,你發現了嗎?

 


 

專案進行中:面對混亂,導入敏捷精神

 

做了以上準備後,原以為專案就能順利進行,實際上我們發現,儘管核心成員都坐在同一間辦公室,卻常常不知道彼此進度到哪,與利益關係人開會時也需要花很多時間說明,因應這樣的狀況,我導入了敏捷開發的一些方法。

 

我會這樣形容敏捷開發:

 

與其成為強大卻遲鈍的恐龍,不如做輕巧而靈敏的松鼠。

 

儘早發現問題、持續調整、不埋頭苦幹、盡量不做重工……敏捷開發是十分龐大的知識體系,無法三言兩語道盡其內涵,不如來看一下敏捷開發的精神起源 – 敏捷軟體開發宣言。

敏捷宣言 http://agilemanifesto.org/iso/zhcht/manifesto.html

 

 

在「奔跑」我用了這些方法:

 

1. 便利貼管理:看板方法

看板辦法由豐田汽車發明,是一種輕巧的管理工具,在軟體業被廣泛使用,了解其中精神後可適用在許多專案類型。我認為他最厲害的是學習曲線極低,個人學習方式是讀這本「看板實戰:用一張便利貼訓練出100分高效率工作團隊」,只要閱讀前兩章就可以立刻開始使用,閱讀時間約為三小時。

 

看板辦法有幾個特色:

1. 隨時可以開始

2. 由團隊成員來制定流程

3. 直覺又通用

4. 迅速釐清團隊問題

 

看板辦法的建立有一套 SOP:需一位看板教練引導工作團隊制定流程,再將手邊的工作寫成一張一張便條紙,貼上屬於自己的位置,看板就大功告成。

 

接下來,當成員完成某個任務,就將任務便條紙,移動到下個流程,直到所有便條紙都放到「完成」的流程時,專案就告一段落。

某個時期的卡片牆

 

 

乍聽之下沒什麼特別的,但看板卻有神奇的魔力:

• 讓傳統由上而下的派工模式,變成團隊成員間的協作

• 每個人的工作負擔量能被看見

• 團隊成員可以清楚知道自己該先做什麼,好讓工作能順利接力

• 避免任務塞車,也不會青黃不接。

十分推薦看板辦法給還是新手 PM 的你!

 

2. 站立會議

另一個是有關團隊默契與工作節奏感的建立,沈浸在手頭上的工作時,很容易進入另一個世界,不知道外面發生什麼事,這時候訂出一個時間來凝聚團隊共識就變得很重要了。

 

站立會議開會原則很簡單:

• 每日固定時間召開

• 必須在 15 分鐘內結束

• 建議要站著,因為會讓人想盡快散會而增加效率

• 每個人輪流報告:1.昨天做了什麼 2.今天要做什麼 3.遇到什麼困難

• 不要討論事情

 

「奔跑」團隊不喜歡早上被打擾,所以將時間訂在下午兩點。

 

藉由這個會議,大家感到地球還在轉動,也可能知道專案正面臨開天窗危機,總之有個時間讓團隊保持資訊流通是好事。

 


 

專案上線後:心得分享

 

「奔跑吧!台北」最後順利上線了,上線 24 小時內就達到 30 萬人遊玩佳績,同時上線人數曾有 8000 人之多。比起「燒毀」成果更加優秀,且時程更短、成本更低、遊戲性更高!

 

這次專案結束後,身為團隊成員有些心得想分享:

 

1. 良好的管理是團隊最大的福利

每個人都有自我實現的需求,但一個人力量有限,無法獨立完成大專案。

一個管理良善的團隊,可以幫助個人成就更大的理想,我認為這是很難能可貴的福利。

 

2. 不當救世主,多開口討論

語言的奇妙之處,有時只要你適當的表達困難,開口的瞬間,問題就解決了。

 

就我個人經驗,專案成員間往往羞於表達困難,因為跟人溝通往往是很挫折的事。因此,我們常常選擇當救世主,捨己為人地熬夜工作解決問題。這些人如果成功了就是救世主,失敗了就成了雷包。

 

不妨別把自己想得太重,成功失敗都交給團隊,遇到的困難就說出口,團隊的智慧就能找出答案,或是你會發現你的問題根本不是問題。

舉例來說:我在開發紀錄分數功能時,在防作弊上遇到一些困難,與團隊討論的結果,竄改分數的經濟效應不大,所以我們決定,在後台增加分數管理的功能,讓團隊得以隱藏有問題的紀錄;事前僅做單純後端加解密,分數簡單驗證一下即可。

 

就這樣從別的角度解決問題了!

 

3. 一期一會,這樣的組合一生只有一次

每個專案都獨一無二,這是肯定的。

 

之前想過,這次專案如果對象不是北市府、不是柯文哲,是否能產生這麼多流量、這麼多話題、這樣的成功?

 

但其實這個問題意義不大,因為人是流動的,不但來來去去,就算是同個人,在每個時間點上心境也不同、能力也會有所長進。客戶也是流動的,會因為當下的地位、形象、能量而背負著不同包袱,需求也不同。

 

認清這一點後,在專案管理時也要認知到,在不同情境下、不同成員,工具與方法都該有所調整。

 

舉例來說,我們的站立會議一開始是要面對面的,所有人在辦公室一起召開。後來美術 Zuzu 提出她在家畫畫效率較高,有時希望遠端工作,討論之後,站立會議調整為使用 Slack(通訊軟體)召開,同樣達到了站立會議的效果。

 

如果身為 PM,卻無視團隊調性,試圖刻舟求劍地複製過去的成功,我認為這是十分不智的。

 

4. 管理的價值要用心體會

軟體界常將 PM(專案經理)視作專案的絆腳石,有人戲稱 PM = Problem Maker。

 

比較「燒毀」與「奔跑」兩專案:

• 前者需要 5 個月執行期,後者僅使用 2.5 個月。

• 前者遊玩方式有 2 種(節奏遊戲、對話),後者增加到 6 種(奔跑、4種加分關卡、對話)

 

我無法將這些進步全然歸功於管理,一個專案的成功有很多要素,團隊人數與經驗影響很大、內容好不好發揮也是。

 

我認為好的管理人員,是專案成功的催化劑,減少討論的痛苦、讓專案進行得更順暢歡樂、防止氣血不順、延長組員壽命。

 

管理人員與開發人員必須站在同陣線,而非上對下的管理關係,各司其職來達到專案目標。

 

PM 的價值不一定是肉眼看得到的,需要你我用心感受。

 


 

尾聲

 

總結一下幾個重點:

• 事前研究很重要,找對工具跟方法才能事半功倍

• 用看板方法將工作流程可視化

• 站立會議效果不錯

• 遇到困難別埋頭苦幹當救世主,試著開口討論

• 管理有價,需要用心體會

 

我做管理職的經驗並不長,還有許多需要學習的地方,希望這篇文能夠幫到跟一開始一樣不知所措的你!

 

文章轉載自「Medium」,已取得作者授權同意,原文為:奔跑吧!台北:網頁遊戲專案管理經驗分享​

 

 

 

 

痞客邦Blog:http://lccnetvip.pixnet.net/blog
FB粉絲團:https://www.facebook.com/lccnetzone
菜鳥救星:https://www.facebook.com/greensn0w

本網站使用相關網站技術以確保使用者獲得最佳體驗,通過使用我們的網站,您確認並同意本網站的隱私權政策。欲了解詳情,請參閱 隱私權政策