顯示具有 coaching 標籤的文章。 顯示所有文章
顯示具有 coaching 標籤的文章。 顯示所有文章

3/14/2021

如何用教練(coaching)的方式引導團隊成員



作為主管,帶領引導團隊朝組織期待的方向前進有很多種方式。其中,「教練式引導」針對特定團隊成員行為改善的其中一種方式。

主管對於團隊成員的引導方式大概有四大方向:教練coaching, 導師mentoring, 領導leading 與管理management。在軟體團隊中,領導與管理是主管一定會做的,而教練coach與導師mentor就會視團隊的實際情況而定。

管理management:簡單的說,是直接或間接以組織所賦予的權力,以具體的方法,要求成員達到結果或者某種行為。舉例來說:「某甲,明天早上十點請到會議室去和某乙討論某專案」就是個具體的管理作為

領導leading:簡單的說,以自己的行為加上組織賦予的權利,以身作則的達到團隊合作的結果。舉例來說:「某甲,我明天早上十點會到會議室去和某乙討論專案,一起和我去吧」

導師mentor:一般來說是比較有經驗的成員,在執行自身的任務的時候,順便分享給相對沒經驗的成員。也許會回答問題,也可能教導做法,或者也分享經驗。通常由主管指派資深成員做mentor,但主管也有可能自己作為mentor角色。導師通常會比學生更厲害或更有實質經驗

教練coaching:以「口說」或者「間接」的方式,激勵或指引成員達到具體的結果。這具體的結果,幾乎100%是有成員直接完成。教練不一定比學生更厲害或更有實質經驗,但通常會更有「口說教學」經驗。例如在世界排名頂尖的職業網球選手,都有雇用教練陪伴指引戰術與練球,但那些教練過去甚至不見得是職業網球選手。

角色區分有時候並不那麼重要。例如管理與領導常常是混合進行,而在軟體團隊中mentoring coaching 當然也常混用。更常發生的例子是,主管指派一個導師mentor給新進同仁時,實際上常常混合了leading/mentoring/coaching。混合並不是壞事情,但如果資深同事,可以透過區別自己的角色,進而使用不同的工具達到目的,那效果會更好!


這篇文章僅只專注於教練式引導。



教練式引導的基本方式: GROW

最最基本的教練式引導模型是Grow,它有四個循環的階段:

GROW: Goal, Reality, Options, Will (what)

目標Goal:

教練和學生要決定一個具體的目標。這個目標可以是組織需要的目標,也可以是學生個人的目標。目標必須是可清楚辨別結果的。例如,網球選手想在四大公開賽進入前四強。在學生剛加入團隊時,可能會訂出目標是「了解現在的系統」,這其實並非清楚可辨別的結果,教練應該和學生花時間,討論具體的結果,例如「根據現在bug清單,修好一個bug並送出Pull Request之後通過團隊所有其他成員的code review並且合併到master branch」。雖然一次可以訂多個目標,但建議還是少量目標為主。

現況Reality:

教練和學生列出和具體目標相關的現況。例如網球選手此時世界排名是200,過去平均多久打一次正式比賽,平均練習時間等等。

以軟體開發團隊來說,現況可能是剛剛加入團隊,才剛剛有git的權限,過去的文件還沒看完,對某些專業領域還不了解,還不知道哪些問題應該問哪些人等等。

現況的描述是相當私人化,對於某些人來說可能還先牽涉到部分自我敏感的資訊,尤其是自己弱點。在還沒有互信的時候,此階段執行要特別謹慎。


執行選項options

了解現況之後,教練就要和學生討論選擇做法。這些做法當然是「學生」要去做的。以網球教練為例,可能會建立心肺功能的健身菜單,也可能會安排練習賽,也可能會為了強化發球。通常可執行的選項會多過可用的時間。當然就要和學生討論哪些選項應該要做,那些不做。

軟體開發團隊也會設定這些選項,但更著重要選項的優先順序,也就是哪些要先做,那些之後再做。

意願will/what:

監控執行,特別是監控執行意願。一個剛加入團隊的新鮮人,初期在意願上通常不是太大問題。如果已經在社會打滾多年,因為換工作的關係加入一個新團隊,作為教練或主管,就要稍微留意一下是否有意願或者動機的喪失。

這GROW是個循環,教練不見得一定要告訴學生這個模型,如果可以說明清楚是最好。根據實際情況,循環的長度會有不同,可是軟體開發團隊中的教練應該盡量控制在1~2週之間,切勿太長。


教練的功能

GROW模型優點是相當簡單,容易理解。缺點是教練實質功能在這個模型比較隱晦。在執行此模型時,也可參考以下重要功能:

建立互信

建立互信是教練最最重要的功能,沒有互信的情況下,很難達到教練完全的功能。

軟體開發工作上的互信應該會比運動型的教練容易一些,只要執行以下三點:(a)自己保持清楚明確的溝通 (b)永遠花時間跟確保完整傾聽對方 (c) 固定時間回饋  通常就能有一定的互信

因材施教

在軟體開發團隊中,教練vs學生,通常是一對一。而每個學生的情況截然不同,因材施教是顯而易見要達到的。因材施教在非技術的領域比較難,最好的方式可能還是縮短GROW的循環時間,如此可以在短的時間修正互相之間的不了解。


建立安全網

運動類型的教練都有其專業能力,可以判斷目前學生是要突破肌耐力極限,還是快要受傷應該休息。甚至某些運動項目,例如體操,就還真的有實際上的"安全網",因為受重大傷害絕對不會對目標有幫助。

就軟體開發團隊來說,安全網其實很重要,但相當隱晦。例如對於相對沒有工作經驗的人,教練應該在「現況討論」時,列出更細節的項目,例如估計時間的時候要估計完整的時間,包含unit test跟撰寫文件的時間。這些實質細節項目,其實會讓新鮮人更清楚並且有信心的做事。

安全網也有可能是透過工具,先行體驗犯錯,而減少日後在真實情況下犯錯的機會。例如,即便團隊沒有要求,教練也可以和學生討論使用某些靜態程式碼工具,在送出PR review先自己找看看有沒有顯而易見的問題。

建立安全網在某些時候是個極為重要的任務。一個教練要謹記,教練成功的原因,是因為學生成功了!不會有一種學生失敗了但是教練成功了的情況。因此安全網是個避免災難式失敗的保險方式。


鼓勵人心

真誠的鼓勵其實對大家都有幫助。尤其是在完成目標之後。因此目標的設定,最好是許多短期目標構成長期目標。舉例來說,如果網球選手的目標是進入四大賽的前四強,但目前世界排名還200,短期目標可能是先在最近的幾次三級比賽獲得冠軍。

軟體專案的目標甚至可以是逐日設定,所以鼓勵也可以逐日發生。所以當教練必然要花一些時間陪著學生。

時間分配

軟體團隊身兼教練的人,通常不會和運動類型的教練一樣是全職的工作。每個人在團隊都應該要有產出,兼職的教練也不例外,所以時間分配在學生的身上恐怕要特別注意。

最基本是要和主管討論時間分配。如果要不影響工作進度,一般的原則,每天15~20分鐘,再加上偶爾中午一起吃飯的時間就應該是上限。

這裡的15~20分鐘,指的當然是學生和教練一起執行檢討GROW模型的時間,並不包含假設教練身兼導師一起和學生工作的情況。

尋找外援

以有世界排名網球選手來說,年紀稍長的教練幾乎不可能跟他打練習賽,所以教練可能會透過自己的人脈(例如同個經紀公司)找到同等級的職業選手來打友誼賽。而更厲害的教練可以說服更高一級的選手來和自己的選手練習。

就軟體開發團隊來說,教練有可能比學生在專業領域還要厲害很多。然而也有可能由於教練資歷太深,反而對最近幾年的新的開發工具並不了解,教練也可以直接安排其他成員專門對某工具對學生直接教學。


其他教練模型

市面還是有很多不同的教練課程與書籍闡述不同的工具和模型。可以參考這裏