連載「團隊任務管理技巧」第3篇
任務要拆到多細？大小剛好的參考標準
關於本連載
「團隊任務管理技巧」是寫給剛開始使用任務管理或專案管理工具的團隊的連載，共 8 篇，另有 1 篇番外。不限產業，可以從任何一篇開始閱讀。
- 工作要用什麼單位來分？
- 讓人看得懂的任務寫法
- 任務要拆到多細？本文
- 怎麼決定負責人和到期日
- 怎麼回覆留言
- 進度要怎麼傳達？
- 和公司外部的人溝通時怎麼寫
- 怎麼收尾即將推出
番外篇「讓語言不同的成員也能看懂的寫法」（即將推出）
只登錄了「參加展覽」這一個任務，回過神來已經是展覽前一天，手忙腳亂。反過來，連「寄一封郵件」都拆成任務，結果任務超過 100 個，分不清哪個才重要。
這兩種情況，都是因為任務的大小不合適。
註：本文由 GeckoFlag 的開發者撰寫。
結論：拆到一個人幾天能做完的大小
參考標準有 3 條。
大小剛好的參考標準
- 負責人能定為一個人
- 幾天內能做完，最長也只要一兩週
- 做完了沒有，一看就清楚
3 條都符合，就是剛好的大小。有不符合的，就拆開，或者合併。
太大的徵兆
- 負責人有好幾個
- 「正在進行」的回報持續了好幾週
- 寫不出完成標準（寫法在第2篇「讓人看得懂的任務寫法」中有說明）
太大的任務，從外面看不出進展到哪裡。等發現延遲時，往往已經快到到期日了。
太細的徵兆
- 登錄花的時間，比作業花的時間還長
- 列出來的全是幾分鐘就能做完的事
- 清單被塞滿，重要的任務反而看不到了
幾分鐘就能做完的事，不要單獨建立任務，而是在任務的說明裡，當作「要做的事」用項目符號列出來。
拆分的步驟
以參展準備為例。
- 寫出最後必須備齊的東西：攤位、發放品、當天的人力、進場和撤場
- 針對每一項，寫出需要做的事
- 依負責人和期間重新歸納：拆到一個人幾天能做完的大小
- 寫下先後順序：前面的事沒做完就不能開始的，要寫上順序
| 大項 | 任務 | 負責人 | 順序 |
|---|---|---|---|
| 攤位 | 畫攤位配置圖 | 佐藤 | 最先 |
| 攤位 | 安排展示台和照明 | 佐藤 | 配置圖之後 |
| 發放品 | 整理型錄的文稿 | 鈴木 | 最先 |
| 發放品 | 把型錄交給印刷廠 | 鈴木 | 文稿之後 |
| 人力 | 做當天的值班表 | 高橋 | 最先 |
| 進場・撤場 | 預約貨運公司 | 高橋 | 配置圖之後 |
如果只寫「準備型錄」，就看不出是卡在文稿還是卡在交印刷廠。拆開之後，就能知道是哪裡延遲了。
2 層就夠了
拆分時，分成「大項」和「個別作業」這 2 層，大多就夠了。拆到 3 層、4 層，就很難看清全貌，更新起來也更費工。
想要第 3 層的時候，表示這個大項太大了。可以把大項一分為二，或者另外建立一個專案（專案的劃分方式，在第1篇「工作要用什麼單位來分？」中有說明）。
容易卡關的地方
1一開始就想拆得完美
之後的事，不開始做是不會知道的。只拆看得到的範圍，從近的開始拆細。比較遠的，先維持大項也沒關係。
2拆完之後，把大項那個任務擱著不管
個別作業全都做完了，大項的任務卻還停在「處理中」，這種情況時常發生。做完最後一項作業時，也要把大項那個任務設為完成。
例如，曾經有過這樣的事
「製作公司簡介」被當成一個任務，結果拍照的日期還沒決定這件事，直到截止前兩週都沒有人發現。
拆成文稿、拍攝、設計、印刷之後，每週開會時就能確認卡在哪裡。
在 GeckoFlag 中可以這樣拆
- 可以在議題底下建立子議題（父子議題）。在議題清單和甘特圖中，可以把子議題收合在父議題底下
- 父子議題最多 2 層。和本文「2 層就夠了」的想法一樣，不會拆得太深
- 父議題和子議題要放在同一個專案裡
- 順序也要寫在說明裡
實際畫面可以在 Demo 中試用。
總結
任務要拆到「一個人幾天能做完，做完了沒有一看就清楚」的大小。拆分時，從最後要備齊的東西倒推回來，控制在 2 層以內。下一篇將介紹怎麼替拆好的任務決定負責人和到期日。
連載標題和完成標準的寫法，在第2篇「讓人看得懂的任務寫法」中有說明
連載第4篇「怎麼決定負責人和到期日」