標題也可以是：如何接政府計畫然後做 scrum 敏捷式開發
sense.tw 想要做能夠促進線上公民討論的工具和服務，讓散亂的網路意見可以被標記統整，讓新加入討論的人或政府官員可以快速看到徵點。（實際上就是接了科技會報的計畫，要做社會與科技政策溝通平台的線上參與工具。）很多人都跟我們說這不會成功啦，已經試過了，不能天真以為科技或是工具可以解決政治、政策問題。
的確，我們團隊不太樂觀我們能夠創造超厲害的改變，而且在第一次團隊實體會議的時候，就提出「如果世界末日、沒有電力之後，我們做的事情還會留下什麼價值？」這種科幻小說式的思考。
我們覺得我們至少可以嘗試品質更好的網路意見討論的模式、網路參與的文化，或是僅僅是紀錄我們怎麼接政府專案，但用 startup 和開源社群的模式跑產品開發。（為了達到世界末日之後可以使用的目的，我應該會把部落格文章定期印出備份）
於是這篇文章跟之後的部落格系列就誕生啦！會持續記錄我們的產品開發歷程，我們怎麼思考問題，做了什麼事，希望能夠提供大家參考，或是吸引想加入協作的人給我們建議和跟我們合作。
這邊直接跳到團隊第二次實體會議，我們第一次紮實地做 Sprint Review and Planning。
這對於一個團隊散落彰化、台中、台北、新莊，有效開會、事先規劃、建立團隊默契就很重要。從 2017 年 11 月到 2018 年 1 月，只有兩次實體全員到齊，第一次是 Team building 與 Brainstorming，第二次就是這次 Sprint Review and Planning 開始上緊發條開發產品，訂定 OKR 和驗證目標了。
什麼是 Sprint Review & Planning？
雖然老闆 hychen 口口聲聲說我們在跑 scrum，但其實我們離跑 scrum 的理論書相去甚遠。讓我直接跳過複雜的理論介紹，直接進入我們 Sprint Review and Planning 在幹什麼。
基本上，就是我們雖然有政府壓的 KPI，什麼時候該做什麼事情。但是當你在開發未知領域的產品的時候，實在很難知道三個月後產品該往什麼方向走，而事先規劃你要符合的指標，於是訂定一年的 KPI 很容易只是在訂容易達到結案的數字，而不是真正在規劃團隊要做的事情。
Sprint 的概念很簡單，就是滾動式修正，我們每兩個禮拜 review 一次過去兩週的成果（不一定要兩週），做了什麼、學到什麼，然後規劃下兩個禮拜要做什麼，要用 MVP（最小可行性產品）驗證什麼樣的假設，驗證成功就繼續做，失敗了就調整再前進。
理想上 Sprint review 早上做，Sprint planning 下午再做，好的 planning 可以讓未來兩個禮拜所需要開的會與溝通降到最低，讓團隊成員專注在解決問題、提出解方。例如，我們這個 sprint 要驗證的假設是，去政府開會的專家會想要使用我們的工具在 pdf 上留言討論提供政策意見。於是工程師要讓 pdf 可以被線上留言，設計師要讓使用者有能夠用的介面，我要去找到能夠幫我測試的人或是方法。但目前為止，好像這個假設是個假需求，所以下次的 Sprint 我就會換方向驗證，例如：實際上有需求的是積極公民想要整理臉書、PTT、媒體報導中的資料。
身為開源社群，我們都是文件和流程控，所以以下記錄我們實際上怎麼做的。
Sprint Review
我們之前受限於人員時間，只能開每週開 2–3 小時的線上會議，每個人簡短報告自己過去一週做了什麼、學了什麼、下週想要做什麼、接下來有什麼對外會面。
這次我們參考了一些團隊的 Sprint Review 方法，開了一個 Google 簡報，作為大家一起編輯 review 過去兩週工作成果的方式。架構如下：
願景與目標
這樣大家才不會專注在枝微末節的事情，而忘了團隊一開始開發產品的目的。（中間也是可以隨時調整的）
OKR（目標關鍵結果）
我們每一季訂有季目標，是我們想要達到但可能達不到的目標關鍵結果。不是寫死的 KPI ，而是我們自己挑戰自己的目標。這些目標需要可以量化判斷達成率，例如：我們想要證明線上標記工具真的對線上論戰有幫助，於是我們設定在三月前要有 1000 位註冊者，至少 3 個活躍討論的主題。當然對政府交代的 KPI 也是重要 tracking 指標之一。
Incoming events
讓團隊彼此知道會去參加什麼活動，例如外部會談、使用者訪談、技術 meetup。同時也讓彼此知道休假狀況，可以互相支援工作進度。
驗證假設
上個 Sprint 的假設的驗證成果是什麼？我們學到什麼？下一步要做什麼？
- 假設一
- 測試方法
- 結果
- Lesson
上個 Sprint 工作成果分享
我們分成
- Growth：成長策略，與數據 metrics 追蹤，例如註冊成長人數。
- Features：做了什麼功能
- Research：研究得出什麼 insight
- Workflow：改善了哪些內部的工作流程
每一頁則需要填上
- Goal:
- Result:
- Lesson:
- Next Sprint:
我們自己發展出來的 Template 在這裏。
這次實際填寫的成果。
歡迎大家自由取用，並提供我們 feedback。
Sprint planning:
我在大家報告的時候，其實有一邊偷偷在用便利貼記下大家提到說接下來想要做的事情，跟學到可以改進的東西，那就是我們下個 sprint 很可能要做的事情。不斷回顧隨時調整，是我剛接下產品經理的時候，一位前輩說的唯一口訣：Be retrospective。
如果 review 有坦承布公問題點跟發現、想法的話，進入到 Planning 環節的時候，團隊成員應該每個人都會有想要做的事或是想到的解方，大家就用黃色便利貼寫出下星期想做的事項，我再用綠色便利貼整理成不同類別。
我們強調每個團隊成員都有自己的專業和重要的想法，所以身為產品經理的我不是去指派工程師、設計師一定要做什麼事，而是大家都可以提出有什麼應該或是想要做，然後我排定未來兩個禮拜執行的優先順序，畢竟我不太清楚技術端的基礎建設應該要做什麼。例如，雲端架構師會提出系統穩定所需要架設的基礎部署，設計師提出想畫新的介面和使用者訪談，工程師想要研究標記資料讓機器學習的方法、提出網頁元件應該要模組化等。大家充分理解彼此需求跟需互相配合事項後，我會敲定這兩週的團隊目標，然後設計師實際上這禮拜應該要先做使用者訪談，下禮拜再去改介面。
所以重點是充分溝通，然後每個 sprint 都要有個驗證目標，努力去驗證這個假設對不對，才不會白做工。跟一般傳統大公司、政府計劃，每個部門以月為單位去規劃執行，再交付給其他單位非常不同。作為一個不知道做什麼才會成功的新創團隊而言，我不可能讓鮮花一個月做使用者調查，再請設計師畫了二十幾頁漂亮的介面圖，結果兩個月後給產品上線測試才發現使用者根本不需要這個功能。所有的蒐集資料、規劃、畫介面、工程師開發功能、上架、給使用者測試，就是得在兩個禮拜之內完成，然後才能評估我們做的事是不是在對的方向上。
Sprint 能夠充分運行的另一個前提是，大家要能夠覺得可以隨時提出問題、隨時承認錯誤，才有辦法找到問題跟真正合作，要在幾乎完全扁平化的氣氛下工作。所以通常也會有 scrum master 的存在，扮演教練的角色, 來幫忙大家熟習 scrum 的流程和確保討論夠開放和切中目標，而不直接干預產品的走向。理想上，團隊中所有的人都可以是 scrum master，每個人都可以提出產品相關的解方，然後 product owner 做出產品最終方向決定。
保持彈性也很重要，像我們本來 OKR 目標關鍵結果定義不清楚，工程師提出疑惑，於是我們就拿出了另一張海報紙排定了這季跟今年的階段性任務目標。
所以這週的 sprint 要驗證的假設有兩個：
- 外部科技社群專家會需要社群在他們去政府開會的 pdf 上 comment
- 積極公民需要標注整理在臉書、PTT 上跨文本的言論
目前還在驗證中，結果敬啟期待，所以你有以上兩個需求的話，請盡快聯絡我們，安排使用者訪談和測試。
貼完便利貼之後……
有便利貼寫出要做什麼總是會讓人精神振奮，但是一定要把這個紀錄數位化，並且具體到每件 task 有一個 task owner（不然兩個和尚沒水喝），有個 deadline（PM 還有其他夥伴什麼時候可以找你看看工作情況）。所以一個好的 task 規劃是應該要一天內就能做完，如果不行，就要把要做的事情再拆小。不然任務太大，覺得太難完成，會很容易很抗拒開始工作。
所以我把任務壓成 Trello 這個專案管理工具上面的卡片時，我們團隊大家會互相確認 loading 會不會太重？優先順序是什麼？有哪些事我要先做？要做到怎樣的程度？目的是什麼？如果發現這個 task 窒礙難行，或是其他事情更重要，就隨時討論修正，大家有問題就一起解決。
我們也針對團隊的各種管理工具寫了一份流程文件，但夜深了，非同步協作的溝通方式就下次再寫囉！待寫清單上可能還有：
- 如何跟一邊有薪水地開發產品一邊跟社群協作
- 如何開始 team building 和 brainstorming
- 我們如何做 Persona, Journey Map 和 User story
最重要的是…….
讓大家心情快樂，大家狀態好才會能夠主動想到更好的解決方式。因此，高品質的食物與歡樂的工作氣氛很重要。請大家推薦各種美食，幫助我們的專案前進！
有興趣的人請趕快註冊 sense.tw 使用工具看看吧！
我們也正在招募行銷實習生，有興趣的這邊請進。
Originally published at blog.sense.tw on January 16, 2018. （連結已失效）
