過去兩年透過改善流程管理個人與組織注意力的實務經驗
「沒有 Email 的世界」一書的書標有一點標題黨，整本可以說其實是在分享如何改善個人與組織的工作流程，來最佳化注意力與生產力。
值得注意的是此書聚焦在「流程」而不是「工具」；工具只是拿來落實新流程的手段。
當初讀這本書只是亂逛被書商廣告打到，當作閒書翻一翻。赫然發現書中提到不少自己過去兩三年才摸索出來、甚至還在實驗階段中的流程方法；其中也分別包括了我自己用在個人與組織上的流程，包括經營社群、帶開源軟體開發團隊等。
本文整理了一些這類個人經驗，順便與書中提到的概念和方法互相對照。
集中任務資訊脈落，並且參與時機主動權還給當事人
每次切換脈落都伴隨著一定程度的成本耗損（ overhead ）；書中提及「蜂巢式」工作模式，意指不斷切換不同工作脈落的模式，像是用電子郵件同一天內處理十個不同的專案。而蜂巢式的工作流程會嚴重耗損個人注意力，進而傷害組織的生產力。
書中建議幾種集中任務資訊脈落的工具可用來實踐集中注意力的工作模式，我另外也加進一些我想到的：
- 使用看板風格（ Kanban ）
- 使用 mail group
- 使用 thread
看板管理維度
看板管理常見（且幾乎是眾人耳熟能詳）的工具有 Trello、Jira 與 Asan 等。
除了常見的「以狀態為 column/list 」的呈現風格，我另外會根據實際需求，採用「維度較少的狀態採用標籤 label ，而維度較多的狀態才用 column/list」。
舉例來說，個人生活中充滿「相對小但數量多的專案」，例如報稅工作就可以切成「初次閱讀報表、針對不懂的項目研究、總結與上傳」，安裝大型貓跳台可以分成「丈量房屋空間尺寸、訂購材料與商品、第一次安裝、第二次安裝與完工」。
我將看板風格用於管理個人生活時，因為個性使然，五個十個「專案」同時發展在我的生活中是常態，某個面向。「報稅」、「裝貓跳台」等就會是我的看板 column list 的標題，而用 label 標示 TODO 、 Doing 、 Pending 與 Done 等狀態。
TODO 、 Doing 、 Pending 與 Done 的這些狀態總是只有大約四五個，也就是說，當這些小但是多的專案要集中在一個看板管理時，只要專案總數超過四五個，我就會採用這種變形的看板管理風格。足夠大的專案才會自己一個 board ，然後避免生活中同時超過四個 board ；我自己的經驗是，一旦超過四個，就會難以管理與推進事情，伴隨而來的是頻繁且強烈的挫折感，然後就放棄了 XD
使用 Mail Group
「沒有 Email 的世界」一書中提到 email address 可以不用以「人」而是以「專案」為「受眾」；會以人為受眾只是網路技術發展史的產物。例如 project@xxx.com 。
這個經驗與我過去兩年在試著推廣 mailing list 這個「古老」傳統不謀而合[1]。這類郵件風格有下列好處：
- 暗示受眾對象是「組織」或是「專案」本身，個人針對性低，比較不會引發情緒與焦慮。
- 收件時即明確提示工作脈落，減少切換工作流程時的 overhead 。
- 資訊科技角度上，便於備份與再傳播
[1] 例如 Linux kernel 專案和 Debian 專案至今仍然以 mail group 為主要通訊與協作管道
協定原則與 Office Hour
身為電腦科學博士的、「沒有 Email 的世界」一書的作者 Cal Newport ，在書中提到一個我很喜歡的比喻：Claude Shannon[1] 在 1948 發表的論文中、 information theory 得出的結論：透過調整規則，可以減少互動需要的資訊量，這個結論被 Cal 套用在知識工作者日常的協調工作中，Cal 稱這些「規則」叫做「協定」（ protocols），而辦公室中大家講好什麼時候要開會、開會形式等等，被 Cal （向 Shannon 致敬地）稱為「 coordination protocols 」。
Office hour 是 Cal 認為參與協調需要相對頻繁但是不緊急時，成本低但效果好的 protocol 。我很同意。例如下面三個例子。
[1] 另外， Shannon 在 1937 年、 21 歲的時候，出版了被譽為可能是人類史上影響力最大的碩士論文 XD 該論文基本上奠定了數位電子學的基礎，有夠猛。
[2] 「你什麼時候有空？」「週一」「週一我不方便耶，週三？」「週三我不行」...沒完沒了
社群顧問與協調
我在今年將 PyCon Taiwan 社群籌備相關的事情，跟夥伴講好「雙週星期一與四」的某個時段一定可以在網路上透過視訊的方式找到我，大幅省下我類似顧問與協調角色的認知負擔；至少我不用疲於與人約開會時間[2]，並且可以提早一兩週就安排好該 office hour 前後的其他工作，不會有強迫要 context switch 的內心排斥感。
Hacking Hours
另外一個例子是每雙週三帶領某保育工作相關的公民科學計畫，我將 office hour 拓展為半諮詢、協調、半 sprint 開發的 「 sprint/hacking/pair programming hour 」，也很明顯地讓我用一種較無心裡負擔，但專案（緩慢）但持續地有在前進。作為 side project / fun project ，這是很舒服的節奏。
Co-writing Hours
類似上述的 hacking hours ，只是活動內容改成與朋友共同寫書。
30x Rule
30x Rule 意指「如果一件事情常常需要重複、有預期超過 30 次以上，那就值得花 30 倍的時間去訓練某人或是自動化程式，來做自己用一倍的時候就可以做好的事情」。
我第一個想到的是從 2019 年開始起草、至今基本流程似乎以接近成熟的 PyCon Taiwan 籌備招募工作。這個招募工作用意是引導新任志工，使他們能夠快愉快地融入社群並盡快上手各種志工任務。前文所謂「流程接近成熟」，意指大約五人的招募團隊，每個人都能按照已經不太變化的招募流程 SOP 來執行每次的招募與訓練工作。
社群需要新陳代謝，所以這類招募工作需求，似乎沒有什麼理由要有終止的一天。所以可以說是有預期會執行 30 次以上。因此將流程文件化[1]、並且老手帶新手做個一兩次，就可以 scale up 執行能量了。
執行能量一旦 scale up 之後，團隊彼此就會感到更輕鬆、釋放出更多創造力來做更有價值的事情，例如改善流程、主動成功招募整個團隊最需要的人才。整個對於個人的社群體驗會提昇，會在社群活動中感到成就感、與人交流、做有價值的事情，但又沒有太大的負擔。
[1] 文件化可說是自動化、程式化的一種概念，只是採用自然語言、執行「程式」的是人；法律可說是社會的程式碼，法官是 compiler 或 interpreter
小結與其他老生常談
對於知識型工作，最重要且要管理的是注意力，其次才是時間。所謂時間管理，精確來說是注意力、精力與意志力管理；時間本身是無法管理與分配的，每人每天都只有 24 小時，這件事情是客觀事實。然而我們可以管理、維護甚至鍛鍊發展自己的注意力、精力甚至是意志力；每人每天的注意力、精力與意志力水平都是浮動的，浮動的事情人為介入管理，才與沒有管理的情境下有差別。
生產力是知識型工作者的注意力、精力與意志力的綜合表現結果。管理、設計與發展工作流程，就是在管理生產力。