張小龍的文章原文地址：http://www.leiphone.com/news/201610/KoA7nWnVJPls5p5g.html
文章一共講了三個問題，這里只談一下敏捷性。
文章的觀點，產品要快速迭代，保持敏捷性，就需要將團隊拆分成小團隊，并盡可能的減少流程帶來的低效。
這個觀點我非常的認同，但文章里只說了結果，沒說為什么要這么做，以及哪些場景才適合這么做，所以這里我想結合平時的一些經驗談下我的看法，以及自己在實踐過程中遇到的一些坑。
首先，大公司或大團隊低效的原因有兩個
1、功能和系統越來越復雜
產品經過一段時間的發(fā)展，功能上的越來越多，系統也變得越來越復雜，這個時候如果沒有好的規(guī)劃和設計，功能或之間的依賴和耦合將會越來越厲害，往往是牽一發(fā)而動全身，外部看起來一個很小的改動，很有可能牽涉到好多模塊的改動
2、犯錯機會越來越少
產品成熟以后，積累了大量的用戶，現在犯一個錯，影響的用戶也越來越多，運營要面對的壓力也越來越大
那小團隊又是如何解決以上兩個問題的呢
首先，要解決系統越來越復雜的問題，就需要將系統和功能盡量的服務化，每個模塊負責的內容盡量做到黑盒，外部不用理解內部的實現邏輯，只是通過數據的交換來通訊。這樣的好處就是能夠將一個很大的系統分割成很多個相互獨立的模塊，每個模塊可以交給單獨的團隊負責，這也是小團隊存在的一個充分條件。所以，這里說的小團隊解決系統復雜性問題，其本質是將系統做更合理的劃分，將大團隊分解為小團隊分工管理。
其次，怎么避免出錯，在大團隊或大公司里往往是通過流程來控制，這是一種上下游交付時的自我保護。例如即使開發(fā)說只改動了一小點，測試也要做一輪完整的回歸，因為這個是流程規(guī)定的。為什么每一步都需要嚴格按照流程來走呢，因為能拍板的人太少，或者說能有權繞開流程的人往往是團隊為數不多的負責人，就像剛才的場景，但如果要繞開這個流程就需要請示團隊負責人，那這樣負責人就會很忙，根本管不過來，最后結果可想而知，按流程走唄。而剛才的問題遇到小團隊時，負責人會更快的做出決策，拍板到底要不要繞開流程，而且小團隊成員之間也更有默契，大家都是一個整體，這種自我保護的意識相對來說就比較弱化了。
最后，小團隊其實對人員的要求要比大團隊更高，因為要找到那么多合格的團隊負責人，讓他們能夠為自己的模塊或產品負責，就不是那么容易的，然后還要充分的信任和放權。每個團隊雖然各自為戰(zhàn)，但需要能理解并保持和公司的核心利益一致。這就需要公司的管理團隊有足夠的智慧，能夠協調團隊之間的合作和利益。所以實踐下來要遠比想象中的困難的多。
有時間的話，我在細聊這里面的困難以及如何解決，這篇就先到這里。
