如何組織團隊？Part I

隨著團隊人數的成長，溝通的成本越來越高，可以做的事情也越來越多（不然加人幹嘛呢～），大家對目標的認知也越來越難統一，無可避免地就會來到要重新組織團隊的時刻。

因為我沒有在比較大的組織工作的經驗，所以在這個過程中，也是不段的碰壁、嘗試錯誤，想找到更好的方法。這次想聊聊組織團隊的方式與我自己嘗試過的心得。

一個團隊通常建議的人數是 5–9 人，不過以我自己的經歷，7 人大概就是上限。超過 7 人因為可以做的事情太多了，一來會議時間變得太長（會議時間通常是參加人數的平方）。再來，每個 sprint 的目標很難掌控，大家會認為其他人做的事情跟自己不是那麼相關，在會議上也無法全程都很專注，反而會覺得太多跟自己無關的事情，造成整體效率的下降。因此團隊一但超過 7 人，我認為就可以開始思考如何重新組織團隊。

基本上我知道的分團隊的方式有兩大主流：

1. Functional team

2. Cross-functional team

Functional team 就是按照 developer 的 function 來分團隊 ，通常就是 frontend / backend / app / devops / QA 等。好處是專業區分明確，各 function 的事項就是找該團隊進行。每個團隊對自己的職掌的 function 也非常專精（不然怎麼叫 functional team 呢？）。

但缺點是 PM/EM 必須先將 user story 切分出各 function 的 task，再分配到團隊中進行開發。在這個模式下，多數的 user story 其實都是要跨團隊合作，團隊對自己 function 的東西會很熟悉，但因為收到的項目都是切分好的 task ，對整個 product 的目標可能就不是那麼的了解，另外也有跨團隊溝通的成本在裡面。我聽聞過使用這個模式的團隊，往往對產品的責任都會落在 PM 身上，工程較少可以參與產品規劃的過程。不過因為我個人一直以來都沒有在 functional team 的工作經驗，所以上述的情況其實都是聽別人說的，並非我的自身經驗。

再來就是我比較熟悉的 cross-functional team，因為我的工作經驗一直都是在 cross-functional team 的環境。相對於 functional team ，cross-functional team 的每個團隊是由跨 function 的成員組成。一個團隊包含可以完成一個 end-to-end user story 的成員。通常這樣的一個團隊就會有 front end / backend / app / qa 等成員混編組成。因為整個團隊是已完成一個個 user story 的方式去協作，所以對於每個 story 會有較完整的認識。團隊可以 end-to-end 的決定整個 user story 的規劃與實作。實際上任何 startup 早期應都是以 cross-functional team 在運作（因為每個 function 都只有一兩人，甚至有人要身兼多職），直到人數多到要分團隊。

而分 cross-functional team 的方法，我們嘗試過兩種方式：

1. 以產品功能來區分 -> 所謂的 feature team。

2. 不區分產品功能，採用 large scale scrum 的流程運行。

在一開始的時候，我們嘗試了以產品 domain 來區分。每個團隊負責產品中的某一個項目，以 Popdaily 的 app 來說，就是三個主要的 domain ：社區、地圖和匿名聊。這樣分的好處是，每個團隊可以專注在發展自己 domain 上面，訂立產品的目標，並不受其他項目的干擾前進。

不過實行一陣子後發現在這個階段還不太適合這樣運行。

首先，要讓每個團隊不受干擾的前進，必須有一個很穩固的軟體架構來支持。但原本的技術債已經欠到脫褲，以 domain 來切分團隊 ，就發現多數的技術債或是產品運行發現的 bug 修正幾乎都會落到社區團隊上。導致新加入的成員也都分到社區 ，讓團隊之間的人數越來越不平衡，幾乎大部分人都在社區，進而導致會議時間和目標非常的難以掌握。

再者，產品其實還沒有一個穩定的發展模式，在這個階段應該要以統一的方式規劃整個產品的戰略，切分 domain 的方式反而讓各 domain 都獨立作戰，沒有人綜觀全局去考量各 domain 間的整合。

另外，因為三不五時就會發生某些事情需要特定人手支援，所以成員也往往需要在不同的團隊調度，無法固定每個團隊的成員。這樣一來也喪失用 domain 分團隊的意義。

所以運行一陣子後，我們決定改為不分產品 domain 的 large scale scrum 方式來運行。團隊是由 cross-functional 的固定成員所組成，一個團隊是 5–7 人。

我們會由 PO/PM 們先決定好下個 sprint 要開發的所有 user story ，在前一個 sprint 的星期三舉辦一個 pre-planning meeting 將所有預計要開發的 user story 介紹給整個團隊，然後由各團隊的代表和 PM 們決定每個團隊要認領的 story 有哪些。之後就跟一般的 scrum 一樣，在 sprint 開始的星期一各 team 針對所認領的 story 進行估點，並且確認可以 deliver 的 story 有哪些，然後就進入開發週期。

這樣的流程進行了一個月（兩個 sprint ），我觀察到幾個明顯的好處：

1. 產品在規劃時能更容易考量跨 domain 間的整合度，PO 能以產品的整體性去思考。

2. 團隊能接觸產品的不同的 domain ，提高團隊對產品整體的熟悉程度。

3. 因為團隊成員固定，每個 sprint 的 goal 能更明確，並且能更清楚的評估開發的 scope 。團隊成員間的默契也能培養的更好。

而瓶頸應該會在 pre-planning 這邊，PO / PM 要產生整個 sprint 能開發的項目並進行排序。隨著團隊的持續成長，勢必會越來越難以進行。這部分會是未來團隊成長的挑戰。

目前我們也讓 designer 從原本 own 一個 domain，改為加入到團隊中並且隨著每個 sprint 的目標去設計產品中不同面向的 feature。不過這個部分才剛開始試行，可能需要過一陣子再來分享實行的成果。

我認為團隊運行與管理方式必須因應公司與產品不同的階段而不斷的調整，不可能有一個固定的方式可以一直良好的運作下去。我很喜歡一句經典：

唯一不變的就是改變

對我來說，管理的重點是養成整個團隊不斷學習與成長的工作文化，擁抱改變並從中學習，持續讓團隊演進並能找到最適合當下階段的運作模式。像早先嘗試的 feature team ，我認為這是現在產品階段還沒到夠成熟的階段可以進行。目前我們會 focus 在現在的 large scale scrum ，應該可以運行好一陣子並不斷優化其中的流程。

最終的目標是讓 team 能轉變為 empowered product team （https://svpg.com/product-vs-feature-teams/），期望對建構一個優秀的產品團隊有興趣的人也能一起加入，共同打造一個能不斷成長的產品團隊！

工商時間

我們正在招募前端、後端與 App（RN） 工程師，程度為 middle level 到 senior，有興趣聊聊的人都可以將 resume 寄到 [email protected]