iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 6
0

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

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

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

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

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

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

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

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


上一篇
嘗試營造團隊的氛圍
下一篇
讓阻礙可以被看見
系列文
為團隊與組織導入敏捷的經驗分享32

尚未有邦友留言

立即登入留言