用「勳章」讓專案管理變得更有趣，遊戲化元素在工作中的實踐 (上) | 專家論點【朱騏】

1. 如何刺激團隊自主管理任務的動力 ?

身為一個 PM，除了規劃功能 Spec 之外，能夠嘗試或觀察不同方法來提升團隊工作效率，是一件很有趣的事情。

在軟體專案開發過程中，有許多的開發團隊都會使用如 Trello、Jira、實體黑板…等工具來管理工作進度，在前公司我們的開發團隊主要使用「Trello」來進行專案管理，特色是可以「視覺化」目前團隊負責的專案與任務。

但在專案開發過程中，我發現如果只是單純的請團隊成員在完成任務後移動卡片，容易讓團隊成員「忘記」更新、移動卡片，結果反而讓 Trello Board 無法呈現最新的開發進度資訊。

除了開發團隊外，我發現自己以及和其他朋友在使用「看板式」管理軟體的時候，都會遇到類似的問題，也就是使用之初很有動力維護看板上的卡片，但久了之後就會默默忘記…

我時常在想：

應該怎麼做，才可以讓自己、團隊成員有動力維護負責的卡片呢？

這個問題背後或許可以拆解成三個原因：

• 單純卡片的移動讓團隊覺得工作過於形式化
• 沒有想要讓卡片在時間內一次到位的「目標感」
• 沒有讓卡片儘早移動到下一個開發/執行階段的「動力」

但這個問題沒有持續太久，過去公司的 QA(Quality Assurance) 團隊使用了非常有趣的方式，大大的增加開發團隊 (RD) 維護負責卡片的動力，這個方式讓我體會到「遊戲化」實際在工作與生活中的魔力，那個方法就是 — 勳章 (Badge)。

2. 使用趣味化的勳章來代表這張卡片的完成效率

一家公司內部的 QA 工作非常重要，它們肩負開發功能的品質控管，同時也確保開發功能可以和公司既有功能兼容運行，畢竟如果上線了一個新功能就讓公司主網站爆炸的話，產品團隊可能就要加班到天明了。

QA 團隊在前陣子導入這套「勳章」制度非常有「遊戲化 (Gamification)」的味道！作法是在不同的測試環境依據測試結果，給予該卡片一個狀態勳章，例如有：

• ? 火箭：表示準時開發完畢並部署到相對應的測試環境 , 且測試一次直接 OK
• ? 讚：QA 抓到一次 bug 並請 RD 修正，RD 修復完畢後測試通過
• ? 倒讚：QA 抓到一次 bug 並請 RD 修正，RD 修復完畢後仍然有 Bug

在每個環境 QA 都會給予任務卡片一個狀態，以前公司的開發流程來說，會經歷三個階段：

Delta 環境 > Beta 環境/Sandbox 環境 > Production(正式環境)

如果能夠在三個環境都拿到「火箭」勳章的話，對於個人來說是一件非常榮譽的事情，因此 RD 們在開發過程中也盡量在發 Pull Request(PR) 前，確保自己在本機端 (local) 能夠有一定程度的測試，降低在測試環境中被 QA 測出有 Bug 的狀況。

以下是前公司實際的 Trello Board 狀況（敏感資訊已馬賽克）：

在 Beta 與 Sandbox 之所以只有一個勳章的原因是 QA 尚未測試

3. 也許，PM 團隊也可以這樣做

目前此作法僅在 QA 驗證 RD 開發功能的流程上，但是相同的概念或許也可以套用在 QA、RD、Design 團隊對於 PM 撰寫 Spec 上。

過去在討論一份 Spec 時，PM 往往會被開發團隊其他成員詢問許多的問題，包含開發細節、執行計畫、功能影響…等，在這種「一問一答」的過程中慢慢將 Spec 的內容補齊。

如果 PM 可以透過「勳章」制度了解到自己撰寫 Spec 的細心程度，除了可以增加自己每次寫 Spec 的完善性之外，也可以和開發團隊成員進行意見交流，無形之中也在收集專案成員對於功能規劃的想法，對提升整個開發團隊的向心力也會有幫助。

瀏覽 2,270 次