團隊規模的增長，帶來的不僅僅是工作產出的增加， 還帶來各種各樣的成本的增加，效率反而大不如前了。所以拆分團隊，就成了團隊轉型其中的很重要的一部分。
隨著業務的不斷髮展，團隊也在不斷的發展。特別是在互聯網公司，團隊增長的速度比母雞下蛋的速度還快，原本一個十來人的團隊很可能在短短半年到一年的時間裡，裂變成上百人甚至上千人的團隊。團隊規模的增長，帶來的不僅僅是工作產出的增加， 還帶來各種各樣的成本的增加，效率反而大不如前了。
管理者往往納悶， 原本同樣的一項工作，小團隊很快就執行完成了，而現在團隊大了怎麼就遲遲執行不下去了呢？
於是，團隊的拆分就成了團隊轉型其中很重要的一部分。
在觀察了眾多的組織轉型、案例之後，再加上我的一些實踐，其實我心中的疑慮越來越多，在拆分的道路上也充滿了荊棘，這荊棘還真的不僅僅在於高層對組織結構轉型的支持，更多的還是在於組織轉型和拆分，真的有效嗎？
以下就是困擾了我許久的問題和對這些問題的一些理解。
一、團隊大了是不是真的就要拆？
團隊大了往往帶來的是效率的下降，我個人認為改進效率的首選方法還是從管理方法本身上先進行改進，不斷挖掘團隊的潛力和合作效率。團隊的拆分是需要從業務或產品的源頭開始拆分的，假如過早的拆分、或者生硬的拆分都會導致效率不升反降。
所以判斷是不是要拆，我覺得不是看是不是團隊大了，而是得思考一下：
- 目前的效率滿足業務了嗎？
- 是否在原本的基礎上還有改進的空間？
- 拆分之後是否真的會提高效率？
二、團隊應該按照什麼維度來拆？
主流的意見都是以業務的角度去拆分團隊，我個人覺得這個意見是沒有錯的，但我們卻也無法忽略其他職能團隊和組件團隊的存在。
如果團隊大了， 那就不會是一個單一的簡單組織形式， 必定是複雜的系統組成，而不同類型的團隊組織形式也是為了解決不同層面上的問題。沒有職能團隊，那麼誰來關注不同職能的人員的個人成長？沒有組件團隊，誰來解決系統的通用性問題？
所以，在大團隊下，不能脫離現實狀況來考慮團隊拆分，也不能脫離環境變化的因素而一成不變。這三種類型的團隊，應該是融合的，不斷轉換的。
三、怎麼“拆”團隊？
與其說是“拆”，不如說是“演變”。上文說到，團隊的組織形式有三類，業務、組件和職能。它們各有優劣，只不過在不同的環境和時間段，團隊有著不同的重點和目標，這就需要這三類組織形式不斷的變化與之相匹配，使之達到平衡高效的狀態。
另一方面，還可以減少組織結構的調整對於整個團隊的利益衝擊所導致的巨大阻力，增加團隊領導對於團隊組織結構調整的信心和決心。往往我們可以適時適度對目標進行調整傾斜，組織起相對鬆散的虛擬團隊，慢慢增加目標的比重，使得虛擬團隊越來越起到重要作用，並讓凝聚力增強。
然後達到一定程度的時候，領導只需要決定是否給出名正言順的明確組織結構而已，那時候的調整已經變的非常自然。
但也要注意，另一個層面的組織結構就會被削弱，但我們並不能完全摒棄它，因為在大團隊下一定會需要不同形式的組織形式存在起到一定的平衡作用。也許在哪一天，可能又會因為環境時間的變化，而“演變”回去，只因他需要重新達到一個高效的平衡狀態。
四、如何治理拆分出來的團隊？
團隊一旦拆了， 可能團隊會被拆分的越來越多，拆分並不是越細越好。
我個人意見還是：首選並不是拆團隊還是在改進管理，但因為業務需要不得不拆出來，那麼拆分出來團隊的治理就變的越來越重要了。
以下稍稍羅列一下我以為的一些需要注意的治理的點：
- 整體目標到各團隊目標的拆分（不建議拆責任）；
- 整體計劃的制定；
- 整體信息的同步和風險監控；
- 整體資源的調度；
- 整體技術架構規範；
- 整體的工作方式和節奏；
- 整體的培訓；
- 整體的文化建設。
這些整體性的管理規範的確立，能夠降低和減少更多團隊拆分的影響和成本，能夠用比較短的時間融入整體大團隊，極大的減少團隊拆分而帶來的副作用。
五、如何衡量團隊“拆”分之後的效果？
這點還真的問倒我了，我真的不能定下一系列的標準，或者數據指標，來很明確的告訴我們“拆”完之後的效果是好還是不好。但“拆”分團隊，跟其他管理手段一樣，都是為了解決某個或者某些問題，而且還是一個相對成本較高的管理手段。
所以上文也多次提到，如果有其他的成本較低的管理手段，請不要把“拆”分作為首選。
如果真的需要使用“拆”分團隊，我們就必須仔細思考和分析，是否能解決這個問題？採用“拆”分團隊的方法解決這個問題所帶來的副作用我們是否能夠承受？
最後，真要評判“拆”分之後的效果如何，我只能說，我們需要看看想要解決的問題是否一定程度上解決了？加上產生的副作用後整體的效率是否仍舊得到了一定程度上的提升？
當然，“拆”分之前，我們思考分析的再多也無法完全避免隨之而來的風險，無法完全預估到所產生的效果是好是壞。所以，我更推薦的方法是通過逐步細小的“演變”來“拆”分團隊，這樣能夠有效的控制風險，弱化“拆”分的成本。
我們在組織轉型和拆分團隊的過程當中經常遇到困境，究其原因，我猜想往往是因為對於團隊這個複雜系統還是想的過於簡單了。複雜系統的形成是有其內部的運轉體系和力量形成的，有時候並不完全取決於領導單方面的意願，或者說並不適合採用破壞性的力量去打破重組，這樣的方式太過於具有破壞性， 這本身就違背領導和團隊的意願。
複雜系統就是因為有各種形式的平衡所形成的，也並不能使用一種或者簡單的方式來組織和定義團隊。團隊的任何一種改變，必定會有有益的一面， 也會有副作用的一面，組織轉型並不像樂高玩具可以隨意組裝，他只是從一種平衡走向另一種平衡，但是對外表現卻會不一樣。
以上都只是就本人而言對於拆分團隊和組織轉型的經驗和理解，希望對有同樣困擾的人有所幫助，同樣也希望管理者在進行拆分和轉型的時候，慎重思考小心實踐，我相信團隊一定會起到很多積極的變化。
作者：鍾欣，網易杭研項目管理部資深項目經理，CSM、CSD、CSPO、PMP，曾任職於博克軟件和印孚瑟斯，是國內早期敏捷的實踐者，並深諳傳統軟件開發的理論和實踐。在構建敏捷團隊和敏捷轉型等領域積累了不少實踐經驗。自2014年加入網易以來，一直擔任雲計算的整體的項目管理工作，幫助雲計算這樣的百人以上團隊成功完成了產品化轉型，並起到了顯著的效果。
本文由 @網易杭研項目管理（微信公眾號：NetEasePM） 原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基於CC0協議
閱讀更多 人人都是產品經理 的文章
