Scrum，但每週只用一小時・細節篇

前一篇《Scrum，但每週只用一小時》勾勒了如何讓傳統 Scrum 有效率 2–8 倍，這一篇想要拉近鏡頭，帶你看得更仔細，也讓你更有脈絡，更能應用在自己的專案中。

上次介紹了以議程取代會議、連結成員而不進行站會、使用每週里程碑等與傳統 Scrum 最關鍵的不同，這次則會將焦點轉移至 Review、Planning、Retrospective 等議程下最重要的方法群。

這些方法或許看起來樸素，但都是經驗上針對特定問題的最簡方法，也因為簡單，可以大幅度降低專案的管理成本，使整體更有效率。那麼，我們就開始吧！

Let’s zooom in! Photo by Alex Perez.

覆核的關鍵是「取得共識」

有人會把覆核（Review）的重點放在質感、追蹤進度、逐項勾稽規格——這些不是不重要，而是遠比不上最重要的：取得共識。

快、狠但不用準

連實體營造都會因為時程而偷工了，更何況是內建高度不確定性的軟體開發。在現實專案中，沒有完美，只有妥協，例如設計師發現使用者也不知道自己要什麼（遑論完美滿足需求）、工程師開工兩週發現既存系統有大雷（更何況完美滿足時程），因此及早討論、降低不確定性是很重要的。

以專案負責人來說，粗擬目標就該向主管確認，草寫分工就該向團隊確認，也應該引導成員儘早提出任何東西與團隊討論。

以產品設計師或軟體工程師來說，只要能凝聚共識，用截圖拼湊有什麼不可以？拿開發者工具魔改有什麼不好？白板畫得醜又如何？沒有設計稿、沒有程式碼是完全可以被接受，甚至是被歡迎的。

我曾經與一位工程師合作，在缺乏設計師的情況下，他用開發者工具拼湊了以假亂真的示意圖，差點以為已經做完了。也因為內部使用者高度理解這份「示意圖」，在會議上也取得了品質優良的回饋。

軟體開發就像瞎子摸象，儘早一起摸出這頭大象，才能避免設計師一改再改、工程師砍掉重練的虛耗狀況。

具體來說，除了以上提到的，我還常用以下的工具：

1. 清單：無論是條列點子、條列目標、條列現況（As-Is）、條列預期能被解決的問題（To-Be）、條列要修改的地方（Gap）、條列任何能凝聚共識的項目，清單是被低估的強大工具。
2. 流程圖（flow chart）：硬核程式宅的我，也曾經執著程式才是根本、瞧不起流程圖，直到我見識到了流程圖可以消弭多少歧異、創造多少共識，我現在非常喜歡看到流程圖。
3. 時序圖（sequence diagram）：自己發現時序圖是特別好用的圖種，因為其框架要求你描述事物的互動，常常能將複雜的事情解釋清楚。因為自己寫程式，偏好以文字製圖，可以參考最近受到 GitHub 支援的 Mermaid 或自己前陣子在用的 DotUML。

有些圖種有「標準」，請忘了標準，團隊能夠形成共識才是最重要的事情。例如在繪製時序圖時，我常畫出不合標準的圖；因為符合標準不見得好理解，考慮到理解性，標準是絕對可以放一邊的。實務上我甚至會避開像是 Class Diagram 與 ER Diagram 這些不好現場理解的圖種。

無論用什麼圖種、工具，請記得最重要的事是取得共識。

到了最後階段還是要再次確認

有個專案實在讓我印象深刻，是我認為前期已充分討論、又想搶快，跳過了內部使用者覆核（Internal User Review）的程序，想說趕快上線、有回饋我也可以很快改。

結果卻導致同事不理解上線細節，除了預期落差，也讓他們面對使用者提問時變得相當緩慢，造成不可挽回的內外部關係流失。

在那之後，我寧可晚一兩週，也會安排釋出候選版（Release Candidate）的覆核，取得最後的共識再行上線。

有效監控你的專案

在做工程、做產品時，我們會利用五花八門的監控工具，以了解系統、產品使用狀況是否正常。在做專案時，專案負責人也可以這樣做，把專案連上「監控工具」，在問題還小時就介入治療，避免病入膏肓。

一如既往，我喜歡簡單有效的方法，我會將事項分類進「On Track」「At Risk」「Off Track」三個狀態，用綠、黃、紅螢光畫記（traffic-lighted status）或標籤標記，來感受實際是否與預期脫鉤，來掌握整體專案狀況，並針對問題事項進行處理。以下是我會使用的操作型定義：

• On Track：如期完成。
• At Risk：主動告知（如例會前）無法如期完成。
• Off Track：被動告知（如例會上詢問後）無法如期完成。

這些「事項」可能是待辦清單上的事項或前篇介紹的 Weekly Milestones。

At Risk、Off Track 連續出現時，代表該事項需要幫忙，可以私下了解，幫助拆解事項，或連結有經驗的成員予以協助。Off Track 連續出現時，除了幫忙以外，也意味著需要鼓勵成員主動回報狀態。

「沒有一個專案沒有意外。」這是專案負責人需要有的心態，怕的不是意外，怕的是意外在眼皮子底下發酵，最終拖垮整個專案。

監控除了依賴專案負責人，也依賴著每位成員，專案負責人需要讓成員知道：主動告知狀況才是在幫助團隊。一個人打不過，那就大家一起上，這才是團隊存在的意義。

記錄意外以釐清根因

處理意外與避免再次發生是兩個不同時間尺度的工作，在當下我通常也會簡記意外內容供日後研究，例如「3/22：因為外部廠商延宕而需要延後。」意外處理到一個段落後，再回頭研究如何從根本避免，以外部廠商為例，不同的廠商有不同的守信程度，有記錄我們就可以依記錄調整預期。

以一週一事調整步伐

慢跑之於短跑重視體力分配，專案之於慢跑的時間跨度又更長了，因此讓團隊維持節奏非常重要。我偏好的節奏是每週至少完成一件事，並在計畫議程（Planning）調整步伐。

要怎麼樣才能調整專案上的「步伐」呢？例如「做完 Awesome 功能」在例會上發現僅完成評估，還需要實作與上線，可以直接拆成三項「評估 Awesome 功能」「實作 Awesome 功能」「上線 Awesome 功能」，並爽快地將「評估」打勾，並和事項負責人確認其他兩項的可覆核日期。

若每週至少能完成一件事，還有 3 件事，那麼至少還需要 3 週，與成員培養了這個默契後，對於時程也會更有把握。

「每次例會都有前進感。」我的專案成員常這樣回饋。確實，當每次例會都有事項被完成時，雖然距離終點可能還有好一段路，但大家都會對於能夠抵達終點更樂觀。

在待辦清單放上日期

Need to plan
• 支援巢狀清單
• 支援表格
• 支援刪除線

≤ 3/22
• 研究中文內文 H1 是斜體的問題

≤ 3/29
• 修復中文內文 H1 是斜體的問題

Backlog
• 支援語法顏色（Syntax Highlight）
• 發布文章時跳出彩虹小馬

我美好想像中的 Medium 待辦清——呃，我會用的待辦清單形式。專案管理軟體種類繁多，用紙筆管專案也不是不行，這裡想表達的不是具體的樣子，而是抽象的形式。

在歷經嘗試後，我發現事項必須與絕對時間（≤ 3/29 而非 ≤ 2 weeks）連結，對內溝通才會具體，負責人也才能有具體的理解，並據此估計時程、對外溝通。

在覆核議程（Review）時就是逐一檢視特定日期下的事項。在計畫議程（Planning）時就是將事項從待計畫區（Need to plan）移到合適的日期區塊或積壓區塊（Backlog），並與成員確認未來規劃合理。專案負責人可以視情況將積壓區的事項移回待計畫區，也就是安排在下次討論。

我也會刻意維持事項們是一條直線，這樣對團隊、對自己來說才是好理解的。如果把焦點轉移至事項們的依賴關係，則會形成一張圖（Graph），就像社群網路那樣；雖然圖確實能呈現依賴關係，但我更推薦你把焦點放在絕對時間上，才是多數情況最需要關心的重點——如果你熟悉傳統的專案管理理論，就是把焦點放在關鍵路徑（Critical Path）上。

同時為了減少專案管理成本，我會優先使用更簡單的 Weekly Milestones，不行時才使用待辦清單。

回顧不是檢討也不是覆核

回顧議程（Retrospective）經常與其他議程種類混淆，首先，回顧不是檢討（Criticism）。

「檢討」常有聚焦在做不好的事並思考如何改進的意味，但人們合作是非常需要正能量的，回顧議程的一大重點就是為團隊帶來正能量，讓大家有繼續走下去的動力。

其次，回顧不是覆核（Review）。

覆核議程是聚焦在「事」，回顧議程是聚焦在「人」，覆核時我們分享對產出的想法，回顧時我們分享對於協作的想法。產出不好時常是源自於協作不順，協作不順很常只是缺乏潤滑，回顧議程就是我們能施加於協作上的潤滑劑。

可以從純感謝開始

在前篇中我們介紹過用 Thanks-Good-Better-Ideas 來規劃回顧議程，回顧議程是為了讓協作更好，當團隊默契還不好時，硬是安排分享可以更好的事（Better）反而容易擦槍走火。因此在沒有把握時，大可只安排分享感謝的事（Thanks），其他可以例會外一對一詢問。

「也謝謝你說出來。」華人不太擅長面對感謝，其實感謝別人的感謝會是一個相當圓融的方式，也確實感謝能夠給你正能量，面對感謝時就讓我們以感謝回禮吧！

換個主持人

「沒有一個專案沒有意外。」前面講得灑脫，但專案負責人常常是專案中最苦的人，在深淵中的專案負責人不一定能將回顧議程主持得好，自己都沒有正能量了，哪來的正能量分給別人。

其實有了經驗之後，就不會覺得主持回顧議程很困難，但急不得，有需要時喬一個更有正能量的人來主持會是好主意，幫助回顧議程發揮效果。

詢問可能可以更好之處

「好奇這樣的會議筆記（meeting notes）對大家有沒有幫助？」這是我在探索會議、專案技巧時常用的方式，不確定時就問一聲，無論是確定有幫助，或是收到回饋，都是很棒的結果。

提要兩次回顧間發生的事

定期安排回顧議程很重要，間隔多久則可以視團隊狀況決定，通常三週以上就很難記得中間發生了什麼事，這時候推薦提一下期間中發生的大事，讓回顧更有效果。

帶人也適用？

前一篇提到相同的框架我也拿來帶人——

專案負責人帶事、專案負責人要盡力讓專案成功；主管帶人、主管要盡力讓直屬成員（direct reports）成功。只是專案例會成了固定 1–1，在 1–1 中與直屬成員互動，設定合適的週、季目標、確認達成狀況、調整協作細節讓雙方都舒服，不就跟帶專案的 Planning、Review、Retrospective 一樣嗎？

對，一樣。

大方向是一樣的，不過在細節方面，人確實有獨特的複雜性，領導與教練（Leadership & Coaching）是另一門不容小覷的專業，有機會再另闢文章和大家分享。

為了帶好自己的專案，一路走來用了好多方法、也看過好多方法，在解決問題的前提下，方法果然還是越簡單越好。這篇介紹了經過多年淬鍊，仍留在我的專案管理工具箱中的方法，期待有給你一些啟發，也期待能真正幫助到你的專案！

延伸閱讀

1. Scrum，但每週只用一小時－Mosky：精彩上集，不回顧一下嗎？
2. 那些加倍會議效率的小秘訣－Mosky：如何帶好每一場專案會議？
3. 給回饋好難？你需要那條「路」－Mosky：如何引入像 Mini-Scrum 這樣的新方法？
4. 三個步驟確保 150% 的生產力－Mosky：身為專案負責人，如何讓成員更投入在專案中？
5. Mosky’s Extended-SDLC — Dropbox Paper：個人公開筆記，是我安排每週里程碑時很常參考的框架，避免漏事。
6. Mosky’s Mini-Scrum — Dropbox Paper：個人公開筆記，有精簡但完整的 Mini-Scrum 方法記載。