前幾天聊到與團隊閒聊以及透過分享去激發團隊的討論，讓彼此認知逐漸同步，暸解團隊的狀況以及相互的想法。而當交流熱絡到一定的程度時，就可以開始考慮大家一起制定一個可落實的政策，嘗試一起完成看看。

制定政策是什麼意思呢？就是把團隊取得共識的想法，變成一個要去執行且貫徹的目標，並且持續追蹤完成的狀況，再根據實際運作的狀況得到的回饋，不斷修正，讓團隊得以進步。

比如說，團隊最近聊到程式碼風格的議題，討論到目前沒有統一程式碼風格造成的困擾，接著有人就提議了，不如來嘗試統一程式碼風格看看，這就是一個政策。或是說，長久以來團隊要做的事情不斷的塞進來，沒有完成的一日，導致成員士氣低落，於是就有人說，那是否嘗試固定每週一進行規劃該週要做的事情，然後協調出一個那個禮拜有能力做完的範圍，這也是一個政策。

但是光是這樣訂定還不夠，要定義的是一個「可落實」的政策。這有兩個層面的意思，第一個是訂出來政策是要團隊有辦法完成的，第二個是政策的敘述盡量完善，是知道怎麼被執行、被追蹤的。光這樣講可能還有點模糊，那我們就分別舉例吧。

怎樣的政策是團隊無法完成的？無法完成的原因不在於政策描述不夠詳細，而可能是團隊職責無法干涉的、或是超出團隊現在的能力或是。誇張一點的舉例就是訂定一個希望公司每半年加薪，或是所有人每天都要各產出 30 個 commit 之類的。政策的目的是借助團隊自發性的改進或是排除內部的障礙，讓每個人更能順利、穩定的輸出產能，甚至增加產能。所以盡量針對當前團隊遇到的痛點，且有辦法透過大家一起改善的方向去訂定政策。

至於怎樣的政策敘述是完善的呢？裡面包括實施細節、達成條件、追蹤方式等訊息。以前面的程式碼風格的問題為例，今天提出的政策方向是「統一程式碼風格」，一次要針對所有程式碼都統一風格，可能會因為範圍太大，有點窒礙難行，所以可以先限縮範圍在 JavaScript 的程式碼，然後只有新的 commit 需要遵守，先不溯及既往，不然光是重構就瘋了。再來是要遵循怎樣的風格，有人喜歡 Airbnb 的風格，有人喜歡 StandardJS 的風格 ，可以先選擇一個作為標準去遵循，再以此標準做修改。剛開始落實時，可以先嘗試挑幾個目前比較活躍的 JS 專案看實驗看，編寫一個腳本去只針對 Git 顯示有變動的程式碼去透過 ESLint 檢查是否符合風格。

這樣不斷的限縮範圍和補完後，一個可落實的政策就差不多完成了。接著可再訂定哪一天大家要來重新檢視這個政策是否要改進，比如說讓大家提出想要修改其中哪一條風格設定，讓原本遵循的風格更符合團隊當前習慣等等。

制定一個可落實的政策是需要滿多討論的，絕對不是一時腦熱說做，然後結果沒人知道怎麼做，或是難度太高最後不了了之。在訂定政策時，先彼此問問看是否已經足夠暸解要怎麼做，以及這個難度是否為團隊當前可以接受的，如果不是，看是要限縮範圍、還是要再換一個政策。最後再想想要怎麼讓這個政策接收回饋、逐漸改善，不是所有政策都要在第一時間訂定完美，這件事很難，所以要有接受回饋並能夠改善的方式，讓政策更加完善。