作為一個菜鳥團隊領導
就在昨天，自己團隊底下的最後一位組員正式離職了。除了表示這三、四個月公司內部的事件某些意義上告一段落，也意味著我實質八個月、掛名四個月的Team Lead 正式結束。
回顧這段不長的時間，我嘗試做了幾件事情：
- 細分任務
- 估計Sprint 尺度能完成的進度
- 滿足組員對工作上技術學習的期待
- 培訓以及技術交流
本文會針對上述幾點，分別寫下我的想法與執行的方式。作為一個時代終結的紀錄與分享。
細分任務
開發的流程中，PM 會寫下Story 來描述預期的開發最終成果，並且訂定再更細緻的feature 描述，對於前端開發來說，通常是prototype 或已經是設計過的設計稿。在開發前，我的一個職責是需要將這些所能得到的資訊，細分成適當大小 的任務，並且將它們開成一張一張的ticket ，然後適當分配 給組員。
對我而言，所謂的 適當大小 與 適當分配有幾個目標：
- 開發時間莫拉太長
- 各個任務之間盡可能不互相依
- 組員間都能夠對專案各處有所認識
若一個任務尺度切分得過大，會讓開發時間拉得太長。而除了對PM 與我自己的進度追蹤是一個麻煩，對於開發者的心態也會是個挑戰。開發是一件需要專注力的工作，並非是傳統工業生產線上，原料來結果出這樣穩定且定性的工作型態。因此如果讓開發者在同一任務上花費過多的時間，卻遲遲無法結束，會讓其專注力與耐心銳減，接下來產出的程式碼品質也會大幅下降，這對於事後的程式碼審查與維護 ，都額外增加了難度，進而讓開發成本倍增。
想像一個前端專案，如果切分任務的方式不夠乾脆，永遠是資料連帶部分畫面，或畫面夾帶部分資料串接。抑或分配任務時，將上游工作集中於某一位開發者。如此會增加每個任務之間的相依性。除了有機會讓開發者閒置外，也會出現上段所說開發時間拉過長的問題。如此一來，不但浪費開發能量，對於開發上的順暢度也會因而降低。
最後的目標是希望各組員對於專案的各處，都能夠盡可能有所認識。目的由小至大，降低程式碼審查的難度以及在往後專案維護與再開發的人力彈性，也是防止團隊內部人員請假乃至離職的保護傘。
因此在分配任務時，會盡可能讓每一個人都能夠對於單一專案內的不同功能都能稍微有所接觸，要能達到這點，也與上一點有所關聯，降低任務間的相依性，才有機會讓開發者能夠無所顧忌地參與不同的專案。這點也可以藉由程式碼審查達到，讓正在開發頁面A 的開發者審查開發頁面B 的開發者的程式碼，也同樣能夠讓開發者對彼此正在實作的功能、方式更為理解。
估計Sprint 尺度能完成的進度
在過去幾個月，我所屬的部門以Scrum 的形式開發，以兩週為一個Sprint 週期，因此在Sprint 開始前與過程中，無論是回應PM 的詢問、對進度的控管，甚至是關乎團隊的士氣，估計一個粗略的任務完成時間是一件重要的事。
在公司中負責掌控各專案的角色是PM ，也因此作為PM 與開發團隊間的中介層有責任要回應PM 對於專案進度的問題。所以必須開始學著估計任務的完成時間，而這件事發生的時間點，可能在團隊討論之後，也有可能在討論之前。當然，正式團隊的估時討論前，所能夠給出的數字相對粗糙，容錯性也應該相對高。但學習如何在開發者們沒有先相互討論過，僅憑自己對專案的認識，以及自己的專業技能，估計出粗糙的開發時程，有助於PM 的安排，以及安定需求方的焦慮。
而在團隊的估計會議中，雖然是個透明的、尊重各開發者自行衡量時間的會議，當往往也必須在會議中先抓出一個合理的進度，作為團隊的目標。如果抓得過長，會有機會發生一個Sprint 無法完成一項大功能的情況；若抓得過短，則會讓團隊感到壓力十足。因此在每次估計中，調整自己對於團隊的認識以及對公司進度的期許，進而估計出更精準的時間，是能夠有效提升團隊士氣的。對於一個團隊領導來說，也是更了解自己組員的能力與狀況的好機會。
滿足組員對工作上技術學習的期待
我很喜歡在大小內部會議中，詢問組員有沒有近期對於技術的期待。這個問題的目的除了了解組員近期所關注的議題外，也希望在工作分配上，盡可能地滿足這些期待。
例如有組員希望能多觸碰GA 等追蹤成效的技術，也例如有組員想學習如何設定一個基礎的專案配置。而當接收到這些期待時，作為工作的切分、分配主導者，會盡可能發想如何使用這些技術，並安插這些組員在相對應的工作上。同時鼓勵他們在利用工作時間學習到自己渴望得到的技術時，也盡可能分享心得給其他組員（當然包括我），進而也是強迫該員整理學習的成果。
這除了是在心靈上讓團隊能夠有更好的氛圍外，我也堅信這才是增加一個團隊技能多樣性的好方式。對我來說，與其是一個協調且一致的合唱團，更期待自己團隊是一個各懷鬼胎但維持相同調式的爵士樂樂團。
培訓以及技術交流
一個人加入一間公司、一個團隊往往有各種理由，除了負擔生活支出、憧憬公司的方向外，在年紀相對輕的階段，更冀望的應該是增進自己的能力。
除在成員加入初期時，簡單的銜接他的所知與公司所用，這除了是實務上補上他的不足外，也是將目前團隊所凝聚的一些coding style 、實作慣例、編程理念給傳達給他。當然如果可以，也可讓剛從外部加入的組員提出他所看到與他過去所認識有哪些不同，是一個改善內部架構的好時機。
另外一個不錯的方式是辦內部技術分享，這在業界也是時有所聞。我自己所待的團隊也有十分簡單形式的內部技術分享，主題的規模從一篇文章到一項新技術都是歡迎的。另外也要最起碼的留下什麼紀錄，可能是流水帳的筆記、演說投影片，或甚至是一篇文章。
由於前端技術總是時時有新東西，雖不需要不知目的地追趕，但還是應該鼓勵稍微觸碰或至少讀過該技術的訴求。如果能夠適時在相對不緊迫的專案中，試著玩少量的新技術，除了會增加團隊開發的新鮮感，也創造一個機會讓大家能夠試用該技術，好的可以留下，不好的也讓大家都理解為何不適合目前的團隊。
總結
我想在這篇文章傳達的是，作為一個前端開發組別尺度的團隊領導，除了「管理」的能力以外，技術本身其實也是相當重要的。畢竟這仍是一個需要親力親為，並且直接接觸組員的管理職。上述所說的幾點，幾乎每一項都脫離不了技術本身：能切出好的任務需要有足夠的技術涵養；欲促進組員的技術成長自己當然也需要時時增進自己。
也因此，我自己是喜歡這份職務的，因為這讓我對於人與技術的理解能夠結合，並且兩者互相促進成長。
最後
送走最後一位組員，心裡是滿滿感傷。作為團隊領導的這段時間，感謝我的前主管在權力的下放上，給予我很多尊重與空間。也感謝PM 團隊願意多次與我協調出理想與現實間的平衡點。另外也感謝後端團隊工程師大大們的專業，讓我們前端團隊在介接與開發上皆能夠順利進行。
而最後感謝我的三位組員，這段時間的配合與包容。本來想祝福大家鴻圖大展，不過發現輪不到我，有人都已經在Google 了，所以還是祝福個心想事成吧。
