好文分享：「奔跑吧！台北」專案管理經驗分享

berylgobby

文、詹致遠



原文網址




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

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

沒玩過嗎？遊戲在此～ 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」，已取得作者授權同意，原文為：奔跑吧！台北：網頁遊戲專案管理經驗分享​



官方網站：https://www.lccnet.com.tw
痞客邦Blog：http://lccnetvip.pixnet.net/blog
FB粉絲團：https://www.facebook.com/lccnetzone
菜鳥救星：https://www.facebook.com/greensn0w