這學期修了指導教授開的課程─「樣式導向軟體設計」

當課程一開始時，老師告訴我們要開始寫程式時，有4個步驟

UnderStanding the problem  -> input/output/constraints (瞭解問題)

Devising a plan -> list the steps (tasks)---"Checklist" (將問題切成數個任務)

Carring out the plan -> Test/Code (開始寫程式及測試)

Looking back -> Retrospective  (回顧)

而其中第二步驟，Devising a plan 也就是為工作列一個清單

印象很深刻的是，老師講的這個步驟時，告訴了我們這本書「清單革命」，

並且囑咐我們，他認為這本書是我們每個人都應該要看的一本書

 

不管是程式設計師、財務經理、消防隊員、警察或律師，幾乎所有專業人士的工作都變得錯綜複雜

只靠記憶做事，必然會有疏漏，在複雜的環境下，專家常面臨兩大難題，

首先是記憶力不夠可靠而且無法保持專注，人們往往為了處理緊急事件，就疏忽了一些常規、繁瑣的工作

還有另一個困難，有些事即使沒有忘記，也很容易省略掉

而清單可以預防疏失，提醒我們至少要確實做好哪些步驟

這麼做不只是為了確認，而且能追求更優異的表現

 

作者提到，清單有好有壞，不好的清單敘述模糊、不夠明確，或是過於冗長，不合實際所需

好的清單簡明扼要，有效率，而且能夠切中問題，即使在極困難的情困難下，用起來也不難

好的清單不是每一個步驟都必須條列出來，畢竟只靠清單，你可能還是不會有辦法完成專業的事(例如:寫程式、醫生開刀、開飛機)

清單只是提醒我們最關鍵和最重要的幾個步驟，也就是技術純熟的專業人士也可能疏忽的地方

 

在製作清單的時候，你必須做一些重要的決定

首先，你得確定使用清單的暫停點(例如發生意外或緊急狀況時，應該做哪些事)

其次，必須決定採用操作確認模式，或是大家一起一步步照著清單來做

前者是由團隊成員根據他們的記憶與經驗分頭去檢查各個項目，然後暫停，最後確認該做的是否都做了

後者則像食譜，唸一項做一項，不管是什麼樣的清單，都必須適合當時的情況

清單列的項目不可太多，最好是在五項到九項之間，因為這樣最容易記憶

清單的用字遣詞要簡單、明確，使用業界最熟悉的語言

清單最好單頁就可以全部印出來，同時避免擠成一堆或使用不必要的顏色

選擇乾淨易讀的字體及排版，以方便閱讀

最初擬好的清單最後往往改得面目全非

不管如何，還是要不斷研究、修正與實驗，直到可以派上用場、使用起來沒有問題為止

而作者告訴我們，我們常誤以為執行清單是複雜的工作

其實清單並不能教你蓋摩天大樓或解決飛機碰到的緊急狀況

沒有專業技能為底，再怎麼好的清單也沒用，清單是簡便、可以迅速解決問題的工具

用以加強專家的技能，是最佳的安全防護網

 

而我自己本人最常用的清單則是待辦事項清單

在這本書壇的清單比較像是工作的SOP清單

軟體開發中，也常常會有一些清單，

例如 : Working aggrement(工作協議，制定一些寫程式的規範，像是有沒有遵守coding standard)、

DOD(Defintion Of Done)

如果僅有短時間能夠閱讀此書，我會建議可以優先讀第二章和第六章

此書用了大量故事、案例、研究輔助說明使用清單的實用與好處