方針（Policy），概括團隊協議、改善行動、Definition of Done 等等，通常會在團隊進行 Retrospective 或類似活動時去提出與更新，像是號誌一樣。而講到號誌就難免聊到總是會有人不遵守號誌的事實，這種情況像是訂定了方針後卻又不遵守一樣，那就難以確認方針是否有用。昨天聊到了狀態更加顯著，就是一種協助遵循方針的方式，比如說若有一個方針是要避免 Lead Time 超過 10 天，那將 Age Time 顯著化就能有所幫助，方針執行一段時間後，再透過開發流暢度的相關指標判斷是否有其幫助，大概就是這樣子的搭配。
所以要現形開發流程的一個環節，就是讓方針更好追蹤執行狀況，為了能夠追蹤，通常在訂定方針時都應該要有以下四種要素，讓這個方針是更具體且知道如何追蹤的。
有了這些要素後，就要來思考如何保證執行率了，這時候將其「現形」是一個很好的方式。如果團隊空間是有牆面或白板的話，就將這些方針用足夠在五步之遙看清楚的字體大小，紀錄在牆面，最起碼寫下執行方式的簡述，以及下次要檢視的日期。若是在數位化工具的話，就可以放在團隊知識管理空間的首頁，或任何每天都會看到的地方。
另外一個方式就是盡量放置與方針相關的操作附近。像是放置在 Kaban board 上對應的階段，比如說有一個方針是測試階段能夠進行中的 PBI 數量不能超過 3 個，就可以在測試階段的欄位上，貼上這段文字。而在數位化工具的舉例中，可以將 Definition of Done 的敘述或連結，放置在 PBI 敘述的頁面中，最好是設定成 Template，只要建立 PBI 就可以直接附帶上。
然而，這些方針若是散落在各地方，也難以綜觀去檢視。筆者通常會透過專案管理工具，或者是 Google Sheet 將這些方針集中在一起，好處是有個地方提醒團隊目前有哪些方針應該要去實踐、哪些該檢視成效了。另外也是可以藉此評估這段時期要做的新變動是否過多，團隊有沒有能量去執行。
講到擔心方針太多，在做這些方針管理時，也可以參考《執行力修煉》一書中提到的四種紀律的方式去進行。為方便讀者容易理解，筆者將其中的五個概念去講述：
極重要目標的制定，可以協助團隊在訂定可作為領先指標的方針時，收斂在團隊當前該聚焦的方向上，避免為訂定而訂定，產出許多當前重要性不高或影響不大的方針。
行駛在公路上除了號誌、標線、車流控管相關規則等顯性措施外，其實也有很多隱性的指引，比如說從 A 地往 B 地，走哪幾條路可能更順、哪些時段通常車會比較多、有沒有野生動物會出落等等。若是這些顯性措施在開發流程中是方針，那這些隱性的指引就是各種在開發過程中逐步探索出來的知識。
這些知識很容易就只存在某些人的腦海裡，只有事情發生時，才能透過這些人得知。但若是他們已經剛好請假，或者已經不在這個脈絡下，那就可能會讓後人再度踩坑，重新探索，這是很可惜的一件事。所以現形這些知識，並且能夠擴散到整個團隊，甚至分享給可能會用的夥伴，是很重要的一件事。
而該如何擴散這些知識，可以從三個面向去探討：
經過疫情時代的衝擊，以及跨辦公室的合作變多，現在的工作方式越來越仰賴通訊工具進行非同步溝通，像是 Slack、Teams 之類的，很多知識的探索其實就是發生在這些對話之中。如果能讓這些對話落落長的文字串，能夠直接變成一個知識點，擴散給其他沒參與對話的人，以及後來在工具上下關鍵字檢索的人，那就是一個很有效的現形方式。
這個部分筆者或許可以先來引用之前寫的文章《Slack 溝通指南》內的幾段話：
這段話大致從開啟對話、進行對話、結束對話三個階段講述在 Slack 上良好的使用方式。但背後的觀念卻可以用在其他工具或現實的對話中。
在開啟對話時，盡量是開放的，讓需要知道這份資訊的相關夥伴知道即將有某個議題相關的討論要發生，自己決定是否參加，抑或是日後再來找尋相關人或紀錄追蹤。
進行對話時，應該能集中在一處，方便之後理解時，能比較好追尋脈絡。而透過好奇、詢問取代質疑的方式，更能夠將知識點從參與者的腦海裡挖掘出來，包括考量、脈絡、經驗等等，擴散這個議題的廣度。
在結束對話時，需要總結這份議題，建立出一個精練的版本方便流通，就像是傳輸檔案時先壓縮或更好與快速的擴散一樣。直接寫出結論放在頻道上，更能讓相關人士知道對話已經結束了，就算沒有時間參與討論或觀看對話紀錄，也可以至少用個三分鐘檢視結論，也能意識到日後可以下什麼關鍵字檢索。
透過這些實踐，就能讓通訊工具本身，成為一個知識庫。
儘管透過通訊工具的檢索有一定的方便度，但畢竟不是所有對話都會發生在這些通訊工具上，也不一定要檢索的人都在對話的頻道上。所以若有一個知識管理工具存放這知識點會更好，諸如 Wiki、Confluence、任何 Knowledge Management System (KMS) 工具都可以。
但是使用這些工具時，最難的地方或許反而不是寫，而是要怎麼存放，目錄結構該如何設計。其實到了現代，這些工具的檢索功能都很完善了，所以筆者建議可以不用太糾結在目錄結構的設計，而著重在是否方便檢索，包括在「我知道我不知道」時，這些知識筆記是否有充足的關鍵字能夠被搜尋，以及在「我不知道我不知道」時，有沒有索引筆記能夠快速瀏覽某個主題的相關知識點。
所以建議可以採用這幾年開始盛行的卡片盒筆記的相關概念，將知識紀錄的筆記盡量寫的原子化，標題取的更加具體，這樣關鍵字就更容易覆蓋在整篇筆記中。並且建立一個個索引筆記，將與某個主題相關的知識點都用超連結的方式建立起一份索引清單。而在各個知識筆記，也盡量多參照其他知識筆記，建立連結。這樣就可以形成一份方便檢索的知識網路。
而在建立知識筆記時，也可以善用這些數位化工具的樣板功能，提供版面與關鍵提問協助編寫者建立良好的筆記。
最後就是知識管理的最終會遇到的困境，就是知識過期的問題，只要寫成文字，這畢竟就是難以避免的。所以與其花太大的成本在避免過期，不如著重在遇到過期時該如何處理。
首先最重要的事情是讓該篇筆記的發表與更新時間足夠醒目，讓瀏覽者意識到這篇筆記的有效性多高。而當瀏覽者發現這份資訊過期時，可以仿效童子軍原則，去隨手更新這份資訊。若是瀏覽者的能力難以去探索這份知識最新的狀況，至少可以在頁面的開頭放置警與，提醒未來的瀏覽者這份資訊需要更新。並且將這份資訊擴散到團隊中，讓有能力的夥伴協助去更新。
若是這份資訊已經不太需要了，就善用封存功能吧！簡化知識庫，是能夠幫助專注的一個方式，更能現形重要的知識是什麼。
iThome鐵人賽
看影片追技術