手順不足與知識不足應該分開考慮的話
前言
當專案裡的成員卡住時，有時會採取「新增操作手冊」或「把操作手冊寫得更詳細」這類對應。
當然，有時候原因確實是手順不足。
不過，實際上也有不少情況是因為知識不足而卡住，卻試圖用操作手冊來解決。
我認為，手順不足與知識不足應該分開看待。
本文中的「知識」是指「程式語言、框架等，執行作業所需的一般技術知識」。業務知識或專案特有知識屬於不同的論點，因此本文不納入討論。
什麼是手順不足
手順不足是指「應該做什麼、應該按照什麼順序做，沒有被定義的狀態」。
例如，新成員加入專案時，如果沒有定義「要安裝哪些工具」「原始碼要從哪裡取得」「設定檔要從哪裡拿到」，就屬於這種情況。
即使具備開發所需的知識，仍然會因為不知道怎麼進行環境建置而卡住。
什麼是知識不足
另一方面，知識不足是指「雖然知道需要做哪些工作，但缺乏執行所需的技術理解」的狀態。
例如，像下面這些情況：
- 知道需要修改哪裡，但不知道怎麼實作
- 看不懂錯誤訊息的內容
- 不知道語言或框架的使用方式
在這種情況下，即使手順存在，因為缺乏執行所需的知識，作業還是無法推進。
為什麼會混淆
手順不足與知識不足，兩者都會以「成員卡住」的形式表現出來。
例如作業停住、產生詢問、或比預期花更多時間等情況。
我自己在現場時，有時會回應其他成員的提問，反過來也會由我自己提出問題。
在這過程中我感受到的，是「不是不知道手順」，而是「缺乏實現手順中內容所需的知識」這種情況其實意外地多。
但從外部看起來，兩者都像是作業卡住，因此在原因還沒有充分釐清之前，就容易直接變成「那就把手順補上吧」的討論。
混淆時會發生什麼事
如果把手順不足與知識不足混為一談，可能會對知識不足的問題嘗試用操作手冊來解決。
當你持續針對知識不足補充操作手冊時，會開始增加各種針對特定情況的說明。
結果就是操作手冊變得臃腫，連原本可以簡潔完成的作業，也得在大量說明中找尋。
如果誤判問題原因，就無法採取適當的對策，類似的卡關情況也會一再重演。
常見的樣態
像是接到「照著操作手冊實作還是會出錯」的詢問，實際調查後發現，原因其實是對框架或函式庫的使用方式本身理解不足，這類案例就很常見。
這並不只發生在某一個特定的人身上，只要是新技術或經驗較少的領域，我認為包含我自己在內，任何人都可能遇到。
不過，對於這種情況，如果不斷採取「在操作手冊中補充框架或函式庫的使用方式」的做法，就會逐漸累積針對特定現象的補充說明和確認項目，最後讓閱讀操作手冊的負擔越來越大。
另一方面，根本原因的技術理解部分，往往還是沒有獲得太多改善，就這樣被留了下來。
解決方法不同
手順不足與知識不足，需要的對策也不同。
如果是手順不足，
- 整備作業流程
- 將規則明文化
- 製作檢查清單
等做法會很有效。
另一方面，如果是知識不足，
- 透過 OJT 或結對作業提供協助
- 分享技術資訊
- 提供學習機會
等做法就很有必要。
操作手冊是用來呈現「要做什麼」，知識則是用來支撐「怎麼實現」。
兩者看起來相似，但角色其實不同。
總結
當成員卡住時，首先應該思考的是：這是手順不足，還是知識不足。
如果是手順不足，就整備手順。
如果是知識不足，就用學習與教育來補足。
如果不先做這樣的切分就持續處理，很容易變成只有操作手冊不斷膨脹，卻無法帶來本質性解決的狀態。
為了正確解決問題，意識到並辨識出真正的原因是很重要的。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
