連載「團隊任務管理技巧」第8篇
怎麼收尾：決定完成的判斷基準，留下日後能回頭查看的紀錄
關於本連載
「團隊任務管理技巧」是寫給剛開始使用任務管理或專案管理工具的團隊的連載，共 8 篇，另有 1 篇番外。不限產業，可以從任何一篇開始閱讀。
番外篇「讓語言不同的成員也能看懂的寫法」（即將推出）
工作開始容易，收尾難。還剩一點小尾巴、遲遲關不掉的任務。以為已經做完了，客戶卻還沒確認的工作。半年後被問到「當初為什麼這樣決定」，卻沒有人答得出來。在連載的最後一篇，我們來想想工作怎麼收尾。
註：本文由 GeckoFlag 的開發者撰寫。
結論：先寫好完成標準，決定的事用文字留下來
怎麼結束，要在工作開始時決定，而不是在最後。而且，把過程中決定的事隨時寫成文字，結束後的紀錄自然就齊全了。
完成變得模糊的 3 個原因
- 沒有寫完成標準（寫法在第2篇中有說明）
- 沒有決定由誰改為完成
- 還剩一點小工作，關不掉
決定完成的判斷基準
除了每個任務各自的完成標準，團隊再訂一套共同的判斷基準，就不會猶豫。例如下面這些。
- 交辦的人（或客戶）已經確認
- 做好的東西已經放在約定的位置
- 已經告訴相關的人工作完成了
同時，也要決定由交辦的人還是負責人改為完成（第6篇中也提到過）。
剩下的工作另外建立新任務
有些任務大部分已經做完，卻因為還剩一點小工作而關不掉。這時，把剩下的部分建立成新任務，原本的任務改為完成。清單裡就只會列出「真正還剩下的事」，進度也能看得正確。
「決定不做了」的任務，也寫一行理由再關掉。比起放著不管，留下決定不做的紀錄更有用。
如何留下日後能回頭查看的紀錄
1寫下決定了什麼，以及理由
只寫「決定採用 A 方案」，半年後就不知道「為什麼沒選 B 方案」。要寫成「決定採用 A 方案。理由：在預算內且趕得上交期。B 方案下個會計年度再研議」這樣。
2當面或電話中決定的事也要寫
會議上決定的事，當天就寫到任務的留言裡。在場的人的記憶，比想像中更快出現落差。
3寫明最終版在哪裡
檔案有好幾個版本時，要在完成回報裡寫明哪個是最終版。
4重複的工作，把步驟整理下來
每年的活動、每月的作業，結束後把步驟和注意事項整理下來。下次準備時就能直接開始。
簡短的回顧
大型工作結束後，只要寫下以下 3 件事。不必拘泥形式，幾行就夠了。
回顧三行
- 做得好的地方：
- 遇到的困難：
- 下次要改的地方：
把「下次要改的地方」設為下次同樣工作的第一個任務，就不會忘記。
有紀錄，交接就輕鬆
負責人更換時，從頭準備交接資料很費工。如果平時任務和留言裡都有紀錄，一句「請看這個專案」就能完成大部分交接。只有紀錄裡看不出來的事（對方的為人、沒辦法寫下來的情況），才需要口頭告訴接手的人。
例如，曾經有過這樣的事
開始準備和去年一樣的活動時，沒有人記得「去年為什麼選了這個場地」。幸好去年的任務裡留了一行選場地的理由，才不用把同樣的討論再來一次。
在 GeckoFlag 中可以這樣留下紀錄
- 改成視為完成的狀態後，議題會從儀表板的「我的議題」中移除。議題本身和留言都會保留，之後還能打開查看。
- 結束的專案可以標記為完成。
- 在議題清單中，可以用部分符合搜尋留言內文。如果養成寫「理由」這類字眼的習慣，之後就更容易找到。
- 可以在每個專案的 Wiki 中整理步驟和規則。
- 在檔案分享中，可以為每個專案建立資料夾，存放最終版。
實際畫面可以在 Demo 中試用。
總結
完成的判斷基準在一開始就決定好，剩下的工作另外建立新任務，把原本的任務關掉。決定的事連同理由一起用文字留下來。這個連載介紹的寫法，從今天起用任何工具都可以試試看。先從一個團隊容易達成共識的做起吧。
連載也歡迎閱讀第2篇「讓人看得懂的任務寫法」和第6篇「進度要怎麼傳達？」。番外篇「讓語言不同的成員也能看懂的寫法」即將推出