「GO START」－ 從《UX in the Jungle》談人人適用的專案管理心法（下）

本文轉載自作者於2019年首次發表在Medium平台的文章。

========================================

《UX in the Jungle》遊戲中讓玩家血壓飆高的遊戲進度月曆

上一篇分享了讓我第一次挑戰就成功設計出有趣桌遊教具的「GO START」專案管理心法當中的 G、O、S，這篇繼續來分享 T、A、R、T 的部分。請容我再次強調，這是人人都適用的專案管理心法，上下兩篇一起看完後，你就會發現要掌握專案管理的要點沒有想像中那麼困難。

T for Timeline

「GO START」裡有兩個 T。 第一個 T 代表的是 Timeline （時間軸）。

專案的執行常常需要投入許多人力、物力與財力。然而，在這眾多資源之中，最關鍵的資源就是時間，因為「千金難買寸光陰」。除了時間以外，多數資源都有機會在專案贊助人的同意下，透過投入更多的資金而取得。但是，錯過的時間卻是如何也無法再挽回了！所以在專案起始時，絕對要先把關鍵的時間點（如：產出交付項目的「死線（Deadline）」）註記在專案管理的時間軸上，並在之後用比其他資源更高規格的方式進行管理。

在跨組織或跨單位的複雜專案協作中，時間的管控尤其重要。因為 Team A 的特定產出，可能就是 Team B（甚至也是 Team C 、 Team D 等其他多個小組）完成任務所需要參考或引用的資源。某個團隊無法按時交付而引發的漣漪效應，其對專案所造成的影響，可能遠遠超乎要求某個團隊熬夜趕上進度的加班成本。

在《UX in the Jungle》中，除了「九月底」這個遊戲結束的時間點以外，還有另一個關鍵的時間點值得玩家參考並進行時間的管理 — 兩疊「產品設計卡（Design Card）」都抽完並重新洗牌的時間點！在遊戲機制的設計之下，兩疊抽牌堆重新洗牌前，時間絕對不會推進到第七個月。因此，有經驗的玩家會依據抽牌堆的高度（剩餘張數的多寡）來調整團隊的策略與計畫。

想在《UX in the Jungle》遊戲中穩定求勝需要做計畫，想在實務中順利完成專案更需要制訂有彈性的計畫！而做好計畫的第一要務就是拉出時間軸並掌握專案中的關鍵時間限制。

好的，看完（上）篇並在文章最後拍手圖案點擊 10下以上的朋友就可以看得見以下這篇文章了……(大誤)

A for Activities, R for Resources

「GO START」裡的 A 代表 Activities（活動）；R則代表 Resources（資源）。

「活動」指的是 — 為了達成專案目標而所必須完成的各項任務活動。簡單地說，就是專案的工作。「資源」則是執行專案活動時所必須消耗或利用的物料、工具或人力。確認專案目標並展開專案活動後，最好依照各活動的相依性排定先後順序、建立「要徑（Critical Path）」並掌握「關鍵鏈（Critical Chain）」，之後才好評估專案所需的時間及成本，並依專案的限制調整計畫、按表操課。其中，「要徑」指的是完成專案所需最短時間裡的最長路徑；「關鍵鏈」指的則是考量專案可用資源後所找出的實際可行要徑。要徑中的任務若有延遲，便代表完成專案所需的時間也將有所延遲。因為多數專案的可用資源通常有限，所以依據「關鍵鏈」所規劃出的專案時程肯定都會比「要徑」要長。關鍵鏈是一種要徑，關鍵鏈上的活動若有所延誤，專案時程當然也就會跟著延誤。

另外，活動的展開及時間、成本的估算，最好依照其預計進行時間距離當下的遠近而有粗細的差異，如此才能避免團隊耗費過多的時間進行準確性很低且意義不大的計畫。多數採用「敏捷（Agile）」方法的團隊，通常只展開當下「迭代（Iteration）」裡需要進行的工作。未計畫於當下迭代進行的任務會統一記錄在一個「代辦清單（Backlog）」中持續追蹤，待清單中的項目確定會被排進迭代後才會分解、展開細部的工作。

在《UX in the Jungle》中，我簡化了產品的開發流程，讓沒有相關工作經驗的玩家也能理解產品開發流程裡的主要活動。玩家發行一款產品的要徑是：與產品經裡及專案經理合作，並依序交付「釐清的使用者情境」、「互動設計」、「視覺設計」等 3 張卡片；接著再與工程師們完成產品模組的程式開發 — 依任意順序收集 3 顆「開發標記」；最後在 CEO 的認可下，提交「產品品質背書」卡片並發行產品。整個要徑在同隊的每位玩家都持有必要的卡片，且與利害關係人合作都順利的理想情況下，將會耗費玩家團隊一共 7 個行動點數才能完成。

但如同真實專案中會遭遇的狀況一樣 — 玩家在《UX in the Jungle》中會遭遇到人力／資源不足，或是與利害關係人溝通不良以至於團隊生產力低落等不同的挑戰。唯有將資源的分配與管理的風險也考量進產品開發計畫中的團隊，才能察覺專案時程（要徑或關鍵鏈）的可能變化，並及早與利害關係人協商、合作，進而讓團隊的效能與效率最大化。

作者於 2019《UX in the Jungle》叢林爭霸全國大賽中授課的實況

T for Test

專案在訂出目的及明確的目標後，如果又依策略、時間及資源的限制展開了各項活動並排定計畫，其實就大可正式開工了。但我的「GO START」心法裡還有第二個 T ，它代表的是 Test（檢驗），這是我覺得也需要在專案起始時就考量、且必須在專案執行期間持續關注的成功要素之一。

「檢驗」指的是用來驗證專案成果是否滿足利害關係人對專案目的期望的方法及條件。簡單地說，就是「專案的驗收標準」。不同於專案中各項交付項目的驗收標準，專案管理與執行的本身應該也要有自己的驗收標準。有時候，專案裡只要各項目標都達成了、交付項目都驗收了，專案就可以算是成功了。但如果專案中的多項目標中只達成主要的一項時，也能算成功嗎？如果主要的目標未達成，但利害關係人都很滿意的話，專案可以算是成功嗎？想想看，你是否曾聽說有交付項目都通過驗收、但利害關係人卻不開心的「成功專案」？

為了符合資源的限制、儘早探索市場需求，或縮短驗證技術可行性的時間，許多大型的「計畫（Program）」往往會被拆分為多個較小型的專案以分頭或依序的方式進行。單一專案中交付的產品或服務，即便合乎需求規格及品質要求，在達成專案目的的程度上不見得會被所有利害關係人所接受。有經驗的專案經理會在專案起始時就考慮到這些風險，並主動與專案贊助人及利害關係人確認檢驗專案成功與否的方法與條件。早一點瞭解老闆（們）的期待，讓專案結果不要有太多的意外，我們的專案才有更大的機會成功、圓滿。

在《UX in the Jungle》中，專案成功與否的「檢驗」條件會依據授課講師的引導手法及目的而有所不同 — 可以是遊戲規則書上的殘酷版本「在九月底時獲得比競爭對手更多的利潤」才算成功，也可以是我授課時常用的版本「在九月底前發行產品並有獲利」就算成功。雖然比賽中只有獲利較高的一隊才算獲勝，但在《UX in the Jungle》的故事當中，九月底能維持獲利的公司都會存活下來。所有能夠克服遊戲中擬真的重重挑戰、在時間壓力下開發出產品並獲利的團隊，若能有系統地持續改善執行專案的流程，誰能說他們不可能後來居上、在九月之後反敗為勝並獲得最後的成功呢？

玩過《UX in the Jungle》的朋友都覺得這是一款相當擬真又有趣的教育遊戲。希望大家看了我分享的「GO START」專案管理心法後，下次玩《UX in the Jungle》時也能在專案管理上有更多不同的體驗。

歡迎轉傳本文或追蹤本帳號以閱讀我分享更多關於產品服務創新、敏捷專案管理或用戶體驗設計的心得或文章。謝謝！