本文轉載自作者於2020年首次發表在Medium平台的文章。
========================================
趨勢科技自 2019 年第三季開始大力推動 DevOps 的企業文化轉型活動，浩浩蕩蕩成立了人數高達 60多人的跨部門工作小組 — STOC (Stand Tall On the Cloud)。然而，經過一連串的 DevOps讀書會及心得分享活動後，眼看相關活動在當年年底的 DevCultureOps Day 文化日活動來到了高潮，卻因為之後的武漢肺炎疫情升溫而有偃旗息鼓之勢。很多人都在問：「轉型是讀完書就結束了嗎？」、「公司還有要推 DevOps 嗎？」、「STOC 還在嗎？」
我在二月底受邀加入了重整並縮編後的轉型工作小組，發現原來小組中不乏有熱情的同事；然而計畫推動轉型的形式與做法卻各有不同，以致在活動的辦理方式上難以產生共識。有的人主張應多邀請有經驗的人士來分享，透過講座及課程讓大家知道 DevOps 實際可行的做法；有人則是主張要辦像「駭客松（Hackathon）」 或是 Design Sprints 等活動，讓公司同仁能實際動手體驗；有人主張應從研發部門內部做起，有人則主張應號召全球不同部門一起推動轉型。
在初步瞭解狀況後，我規劃了一套以遊戲化的方式整合相關活動的計畫，希望彙整各方的作法並讓公司的轉型工作能夠有系統地被推動。不過，雖然公司先前為了鼓勵員工學習人工智慧技術，曾以遊戲化的方式舉辦德州撲克及自駕車比賽，但導入 DevOps 並推動公司的文化轉型似乎又是完全不同類型的挑戰，不少工作小組裡的成員對應用遊戲化的適當性及其對員工能產生的驅動力均表示懷疑。
幸好在幾位具有熱忱的同事幫助下，我們不斷地向各方溝通、補充細節，最後總算爭取到了主管及工作小組全員的「不不同意」，並在四月初啟動了專案、開放全公司同仁報名。這個文化轉型的任務就在我們號稱是「銀河系今年（2020年）最盛大的活動」下，以遊戲化的方式展開了！我們稱這個計畫叫做「星際奇航（Star Trek） 2020」。
稱作「星際奇航（Star Trek）」的遊戲化專案當然不能缺少太空船！
遊戲化設計是近年在用戶體驗中相當熱門的話題，然而以分析「遊戲」設計及其機制的文章很多，分享「非遊戲（領域）」裡實際運用遊戲化的文章卻不多見。這邊簡單跟大家分享我們運用遊戲化來推動公司導入 DevOps 的方式，希望對大家有些幫助。
一、確認業務目標（Define Business Goal）
應用設計方法多是為了解決特定的問題或達成特定的目標，應用遊戲化設計方法也不例外。但進行遊戲化的第一步不是著手設計，而是瞭解並確認遊戲化所欲達成的業務目標。先確認「為何（WHY）要遊戲化」，之後若因時間、資源限制或是利害關係人意見不同時而在專案中必須做必要的取捨時，才能有所依據。
在先前分享的短文中，我曾介紹「GO START」的專案管理心法，這個心法在遊戲化設計的專案裡也很適用。在專案的初期，有時很難具體地列出明確的專案目的（Objectives）或交付項目（Deliverables），但要寫出一段可以獲得利害關係人認可的專案目標通常不會是太難的事。
遊戲化的成功與否不在於讓人主動投入活動的程度，而在於其是否協助業主達成業務目標。如果業主尚未對遊戲化設計有明確、具體的想法，用白紙黑字協助其將業務目標寫下來，對之後要展開工作內容或是確認不同工作項目的優先順序都會很有幫助。
我們公司成立跨部門小組要做的是推動 DevOps 的企業文化轉型，而不是辦理教育訓練活動，更不是辦遊戲競賽。如果公司同仁的日常工作中最終沒有採用 DevOps的價值及方法，那活動辦得再有趣、讓人再投入都不能算是成功。「讓公司同仁能將 DevOps 的價值與方法應用於日常工作中」就是我們的業務目標。
二、確認目標用戶（Define Target Users）
確認業務目標後，接著便是要確認遊戲化專案的目標用戶。目標用戶即是我們希望透過遊戲化而改變其行為或態度的人。搞清楚「誰（WHO）是目標用戶」，才能適切地設計相關的遊戲化機制。
有經驗的設計師肯定知道：以「所有人」為對象設計產品的難度很高，順了姑意多半就會逆了嫂意。若要產品能同時滿足不同類型用戶的需求，通常就是做出姑、嫂「都」不滿意但可以接受的平庸產品。若開發過程中還有時程、人力或技術的限制，最後往往都不是個令人歡喜的結局。
以我們的專案來說，文化轉型勢必需要「公司全體同仁」一同參與，但我們在活動中仍做了用戶的區隔 — 以產品研發部門的同仁做為主要的目標用戶，非研發部門的同仁則定位為次要的目標用戶。因為我們公司是以產品及工程技術為核心的企業，研發團隊若能在我們的計畫中擔任表率，勢必能像火車頭一樣拉動其他部門轉型。
三、確認期待的行動（Define Desired Actions）
確認目標用戶後，便是與利害關係人確認他們在這個遊戲化專案中預期目標用戶採取的行動。就像許多專案一樣，遊戲化專案初期的業務目標可能很籠統。透過事先與利害關係人確認預期目標用戶採取的行動，可以有效降低遊戲化設計的風險。
以我所參與的星際奇航計畫來說，業務目標是：「讓公司同仁能將 DevOps 的價值與方法應用於日常工作中」。但「DevOps的價值與方法」是什麼？「應用於日常工作」又如何才算數呢？我認為透過使用者在產品或服務的體驗歷程，可以幫助我們思考並訂出預期目標用戶採取的行動。
使用者體驗歷程的四個階段
通常使用者體驗的歷程可以分為四個階段：
- 認識階段（Know It）：從使用者第一次聽到你的產品或服務，到使用者下載試用產品或是主動到產品或服務網站上查詢相關資訊（別忘了網站也是產品或服務體驗的一部分！）；
- 試用階段（Try It）：從使用者下載、試用產品（或是主動查詢官網資訊），到使用者理解產品、服務的大致運作方式；
- 使用階段（Use It）：從使用者理解產品、服務的大致運作方式，到使用者自覺探索完產品或服務的全貌；
- 代言階段（Advocate It）：從使用者自覺探索完產品或服務的全貌並認同產品或服務的價值，到使用者認為產品或服務的價值已消失或被取代。
設計良好的體驗設計可以讓使用者願意從一個階段邁向另一個階段，並在其間投入更多的時間與資源（如：付費購買或花時間體驗服務）；反之，不良的體驗設計則會讓使用者在中途便結束其旅程，不會前進至次一個階段。遊戲化專案裡的期待成果也可以用這四個階段分別發想、規劃。
在「認識階段」，我們希望我們的目標使用者在聽到「星際奇航」的專案介紹之後，會因為遊戲及競賽的關係而產生好奇心，主動至網站上瀏覽相關資訊，甚至組隊報名參加比賽；在「試用階段」，我們希望隊伍完成報名後，會花時間瀏覽公司為了這次轉型而特別編制的 DevOps 工程指引（DevOps Engineering Guideline）。在「使用階段」，我們希望 DevOps 成熟度較高的隊伍能透過活動多多分享實際應用在工作上的 DevOps 工程案例（Engineering Practices）。而對 DevOps 成熟度較為落後的隊伍來說，我們則希望他們能透過活動瞭解其他隊伍的成功案例，並移植適合的案例於自己的專案之中。最後，在「代言階段」，我們希望透過此次專案收集到公司內各種 DevOps 工程案例的最佳實踐（Best Practices）能被不同的團隊所採用，這樣目前略顯單薄的工程指引才有機會因為納入各種最佳實踐而成為公司各團隊進行 DevOps 轉型的聖經、寶典。
業界談到 DevOps ，很多人都會提到 CALMS 的架構，包括：Culture（文化）、Automation（自動化）、Lean（精實/敏捷）、Metrics（量測指標）、Sharing（分享）。我們公司在推動 DevOps 時於文化上希望做到：Customer Success（客戶成功）、Data-Driven Decision Making（以資料為本的決策）及 Growth Mindset（成長心態），但是工程技術上則是開放各產品團隊依其個別的架構限制及組織成熟度而可自行決定採用不同工程實務的優先順序。透過遊戲化，我們希望各團隊最終能夠將上述的 DevOps 文化三原則應用於工作中，並分享各團隊實際應用的 DevOps 相關工程實務。
確認我們希望目標用戶採取的行動後，專案利害關係人對遊戲化的目標就可以有一致的理解，之後於設計階段發想遊戲化機制時也能更有所依據，不會讓遊戲化（Gamification）變成遊戲（Game）。
四、確認成功標準及指標（Define Success Criteria & Metrics）
在進入遊戲化的設計階段之前，除了上述的「業務目標」（WHY）、「目標用戶」（WHO）及「期望行動」（WHAT）等三個元素以外，還需要確認專案的成功標準及衡量方式。簡單地說，就是將期望目標用戶所採取的行動轉具體量化的指標（Metrics）。
在「星際奇航（Star Trek） 2020」這個專案中，我們與主管在初期設定的成功標準如下：
- 全公司有超過 30 個以上的產品開發團隊組隊參加比賽，並完成 50% 以上的活動任務；
- 有 15 隊以上完成 80% 以上的活動任務，並獲得於公司內部 2020 DevOps Expo （DevOps 博覽會）的演講資格；
有了量化、明確的成功標準，之後無論是與利害關係人確認不同工作的優先順序，或是著手設計遊戲化活動便能有所依據。
我們於 2020 年 4 月底公佈「星際奇航（Star Trek） 2020」的遊戲化競賽活動約莫兩週之後，截至 2020年5月15日下班前為止，公司已有 90 隊合計近 1,000 人報名參加活動，遠遠超過當初保守預期的人數！不過，活動這才要開始而已。如何透過遊戲化讓這 1,000 名參賽者成為公司 DevOps 轉型的火車頭？我在後續的短文中，將另外分享我們在遊戲化設計階段的方法。
歡迎轉傳本文或追蹤本帳號以閱讀我分享更多關於產品服務創新、敏捷專案管理或用戶體驗設計的心得或文章。謝謝！
