列出清單，就是以終為始
工程師每天的工作是寫code，而我每天的例行公事中，有一塊就是看大家的輸出。這個「輸出」除了包括完成了什麼功能或是修正了什麼錯誤，也要求他們寫出學習技術的過程(為了解決問題，我們常常得學新東西)，撞了什麼牆，卡了什麼陰(沒辦法，解bug的過程就是這樣…😮💨)，怎麼幫專案人員解決問題(以免需要再教一次…😮💨)，怎麼幫自己解決問題等各種日誌。
每天都會被要求要寫這些東西，應該很容易養成習慣？一點也不。人類的惰性是深埋在基因裡的，往好處想是”最佳化”的源頭，只是這也是”文化”養成的頭號對手。團隊的成員理智上能接受，也能理解這麼要求的理由，只是要做得紮實，仍需要有人常常協助”溫馨提醒”一下。
這些日誌內容中，其中最容易疏忽的，就是工項的「檢查清單(checklist)」。
《清單革命: 不犯錯的祕密武器》 中，提了許多我們應該認真看待「檢查清單」這東西的原因。結論簡單濃縮起來說的話，幾乎可用2句話說完。第一句是「好記性不如爛筆頭」，每個人都一定吃過這種虧，再怎麼印象深刻的事情，再怎麼深受啟發的靈感，再怎麼人命關天的要事，就是會忘記。生病狀況不好會忘記，環境發生變化會忘記，生活瑣事太多會忘記，工作壓力太大會忘記…像現在自己金魚腦年紀漸長，很多時候甚至是一轉頭就忘記了！很多事真的不是不知道，就是忘了而已。所以我非常認同這個觀念，也常跟團隊的成員說，不寫下來，3週後你印象就模糊了，3個月後你連這件事是不是你做的都不認得。
第二句則是一個比較深的體悟：「列出清單，就是以終為始」。
組員開出的工項中，我很常在追問一件事：「你這個工項究竟要做什麼」？我能理解工程師不善表達及寫作的先天劣勢，所以我並沒太期待會在工項裡，清楚看到問題的來龍去脈。因此和團隊討論了幾次後，最終定案請大家要在工項中加入檢查清單。也許，大家會覺得很麻煩，還嫌要寫的東西不夠多嗎？但實務觀察後就會發現，這清單比想像的還重要許多。
為了要列出清單，我們就必須開始去想像，最後我們要看到的結果應該是什麼？為了產生想要的結果，我們應該要確認的規格是什麼？為了要實作這個結果，我們應該先測試看看有什麼技術障礙？我們有缺圖，有缺音效嗎？要找誰拿？最終，若是有了這些結果，就是這個工項能結案的條件嗎？有時，當我和工程師認真討論起來，許多重要的問題就會浮現；有時光是要求工程師列出工項的結案條件，就可以挖出很多潛在的風險。也許大家都不喜歡動手前，還得想這些有的沒的，「做下去就知道了」的思維，很簡單直白又正確，但其實大家心裡都知道，事前計劃可能花掉一小時或一天，但省下來的可能是3小時甚至是3天。我們並不是在寫什麼偉大或完整的計劃書，光是嘗試列出那麼一個不起眼的清單，就能強迫我們切到「以終為始」的角度看同一件事。
以終為始，就是思考的起點。
既然大家都自認是所謂的「知識工作者」，那「知識」就應該要留下來，「思考」就應該是工作中要做的事。把產品做出來確實是一個終點，但「怎麼做出來」是更重要更長遠的終點。每個飛機的駕駛員都受過訓練，警報器響起的時候要冷靜，不要慌張，把檢查表拿出來，逐項檢查照做；每個醫生在手術前，也都會和團隊把檢查表拿出來逐項確認，有沒有該做而沒做的事；電廠機組人員在維修前，必然會把檢查表拿出來，看清楚該做什麼檢查，否則自己肯定會被”電”死。
檢查表也許不是什麼看起來很Sexy的東西，但長遠來看，那是能讓我們大家生活更Easy的東西。