前面幾天寫了 POC、文件，以及怎麼把一些實際工作整理下來。
到了這一天，我想寫的是另一個我自己也還在學的事情：
帶人。
以前我比較習慣把自己的事情做好。
碰到問題就自己查、自己處理，久了之後很多事情會變成一種習慣。
但真的開始帶人之後，我才發現一件事。
我知道自己會怎麼做，不代表我知道要怎麼把這些東西教給別人。
我也是第一次當小主管，之前沒有什麼真正帶人的經驗。
所以一開始其實也不知道什麼樣的方式比較好。
後來我比較常用的方法，就是：
邊做邊帶。
讓新人直接參與實際工作，我在旁邊協助。
如果有問題，就在當下處理。
如果哪一段不熟，也可以很快知道問題出在哪裡。
當時團隊人數不多，大概 4 個人，包含我自己。
所以工作不太可能切得非常細。
不會變成：
大家基本上都還是要輪流處理不同客戶的事情。
我會先排一個輪替表。
大概每兩週輪一次。
會選兩週，是因為有些客戶是每週要出報告，有些則是雙週。
如果用兩週當一個區間，交接上會比較清楚。
我們的切換時間會固定在：
雙週的星期五中午 12 點。
到了時間，我會在群組裡說明接下來誰負責哪些客戶。
每個人大概會負責 4 到 5 家客戶。
但我不會只看客戶數量。
因為有些客戶事件很多，有些客戶平常比較安靜。
如果只是單純平均分成每人 4 家，看起來很公平，實際上可能差很多。
所以我會一起看：
再決定怎麼分。
也就是說，我比較在意的是：
整體工作量不要差太多。
而不是大家手上的客戶數一定要完全一樣。
另外一件我會注意的事情，是不要把每個人的工作排得太滿。
通常會希望至少有一個人，相對比較有空間一點。
因為工作很難完全照排班表走。
可能有人臨時有事情。
也可能某個客戶突然有比較多事件。
或者像我自己，有時候會去處理 POC、開會或安裝。
這時候原本手上的週報，就可能需要其他人幫忙。
所以有一個比較有空間的人，可以在需要的時候先補上來。
我覺得這樣會比所有人的工作都剛好塞滿，比較容易調整。
雖然有固定的輪替時間，但我不會完全照表格硬切。
正式切換前，我通常還是會再問一下大家：
有沒有被安排其他事情？
有沒有臨時的案子？
有沒有哪個客戶目前比較忙？
如果有，就再調整。
所以對我來說，排班表比較像是一個基準。
不是說排完之後就完全不能動。
真正開始帶新人之後，我遇到的問題反而不是工作怎麼分。
而是：
我要怎麼把自己會的東西教給別人？
有些事情自己做久了，會覺得很自然。
例如看到一筆 Alert，我可能會習慣先看：
但對新人來說，這些都不是理所當然。
如果我只是直接跟他說：
「這一筆沒問題。」
他下次碰到另一筆，可能還是不知道怎麼判斷。
所以後來我比較傾向：
讓他自己先做。
我在旁邊看。
有問題再一起處理。
像是產品基本操作、客戶初步的應對，我會讓新人先嘗試。
不確定就問我。
我不會要求他剛開始就什麼都知道。
本來就是第一次碰這個產品，或第一次碰這種客戶環境，有問題很正常。
如果每一步都是我直接做給他看，可能當下覺得懂了。
但真的輪到自己操作時，又會卡住。
所以我比較喜歡讓他先操作。
真的卡住，再處理。
我自己覺得這樣比較容易記得。
Alert 也是一樣。
如果新人碰到自己不確定的事件，我會一起看。
然後跟他說我現在會注意哪些地方。
例如：
這個 IP 是不是外部來源？
這個 Port 在這個環境合不合理？
發生的時間正不正常？
這台設備平常是做什麼的？
前後還有沒有其他 Alert？
客戶有沒有可能正在做測試？
最後再跟他說：
我會怎麼處理，以及為什麼。
我覺得這比直接給一個答案有用一點。
因為他真的碰過一次之後，下次看到類似的狀況，比較容易想到之前是怎麼判斷的。
當一個人對產品比較熟之後，我也會開始讓他接觸一些建置的工作。
不是一下就全部交給他。
而是慢慢增加。
因為產品操作跟真正建置還是不太一樣。
開始碰建置之後，會遇到更多東西。
像是：
這些東西如果只看產品畫面，不一定會碰到。
所以熟悉之後，我會讓他慢慢一起做。
POC 是我覺得滿適合拿來帶人的一種方式。
因為一個 POC 會碰到的事情很多。
不是只有安裝產品。
通常從一開始就會經過：
POC 會前會 -> 環境確認 -> 產品建置 -> 資料與功能驗證 -> 問題處理 -> 結案報告
所以我會跟新人一起接 POC。
但不會變成我全部做完，他只在旁邊看。
我會盡量讓他先處理。
我在後面協助。
例如一開始可能只是先參與會前會。
再來可能一起確認環境。
然後慢慢讓他做部分建置。
之後再接驗證、問題處理。
熟悉之後，再讓他多負責一些。
我後來會用這種方式，主要原因也很簡單。
因為我自己沒有什麼指導別人的經驗。
一開始也不知道怎樣教才是最好。
所以我會覺得：
一起做，有問題就直接處理。
哪一段不懂，很快就會看出來。
哪一個操作做錯，也可以馬上修正。
如果只是先講很多內容，新人當下可能聽懂了。
但真正碰到實際環境時，還是可能不知道怎麼做。
反而真的自己做過一次，再碰到問題，再去理解原因，我覺得比較容易留下印象。
除了技術操作之外，簡報我也會讓新人自己做。
我會提供之前做過的版本給他參考。
但不會叫他直接照抄。
還是會希望他自己整理一個版本。
做完之後，也會讓他先報告給我聽。
原因不是要把他訓練成多厲害的簡報者。
只是想確認一件事情：
他知不知道自己做的東西是什麼。
因為如果一份 PPT 是自己整理的，但實際要講的時候不知道內容代表什麼，那可能只是把資料放上去而已。
所以我會讓他自己講一次。
哪裡講不清楚，就再一起確認。
如果要我說這是一套什麼團隊管理方法，我其實不會這樣形容。
因為很多方式都是實際工作之後，慢慢調整出來的。
排班先排。
工作量不平均，就再調。
有人突然有事，就找人幫忙。
新人不熟，就一起做。
Alert 不會判斷，就一起看。
POC 不熟，就從旁邊一起做到慢慢可以自己處理。
我自己比較在意的是：
事情有人可以接，新人也可以在真的工作裡慢慢學會。
第一次帶人時，我其實也不知道什麼方式最好。
只是後來覺得，很多事情如果只是講過一次，很容易忘記，不單單新人會忘記，我自己也是會。
所以真的自己做過、碰到問題、再一起處理，反而比較容易知道為什麼要這樣做。
所以我後來比較常用的方式，就是邊做邊帶。
排班也是一樣。
先有一個基本安排，再根據實際工作量去調整。
我現在還是覺得自己在學怎麼帶人。
但至少對我來說，讓新人實際參與工作，有問題就當下處理，是目前比較適合我的方式。
iThome鐵人賽
看影片追技術