张小龙的文章原文地址：http://www.leiphone.com/news/201610/KoA7nWnVJPls5p5g.html
文章一共讲了三个问题，这里只谈一下敏捷性。
文章的观点，产品要快速迭代，保持敏捷性，就需要将团队拆分成小团队，并尽可能的减少流程带来的低效。
这个观点我非常的认同，但文章里只说了结果，没说为什么要这么做，以及哪些场景才适合这么做，所以这里我想结合平时的一些经验谈下我的看法，以及自己在实践过程中遇到的一些坑。
首先，大公司或大团队低效的原因有两个
1、功能和系统越来越复杂
产品经过一段时间的发展，功能上的越来越多，系统也变得越来越复杂，这个时候如果没有好的规划和设计，功能或之间的依赖和耦合将会越来越厉害，往往是牵一发而动全身，外部看起来一个很小的改动，很有可能牵涉到好多模块的改动
2、犯错机会越来越少
产品成熟以后，积累了大量的用户，现在犯一个错，影响的用户也越来越多，运营要面对的压力也越来越大
那小团队又是如何解决以上两个问题的呢
首先，要解决系统越来越复杂的问题，就需要将系统和功能尽量的服务化，每个模块负责的内容尽量做到黑盒，外部不用理解内部的实现逻辑，只是通过数据的交换来通讯。这样的好处就是能够将一个很大的系统分割成很多个相互独立的模块，每个模块可以交给单独的团队负责，这也是小团队存在的一个充分条件。所以，这里说的小团队解决系统复杂性问题，其本质是将系统做更合理的划分，将大团队分解为小团队分工管理。
其次，怎么避免出错，在大团队或大公司里往往是通过流程来控制，这是一种上下游交付时的自我保护。例如即使开发说只改动了一小点，测试也要做一轮完整的回归，因为这个是流程规定的。为什么每一步都需要严格按照流程来走呢，因为能拍板的人太少，或者说能有权绕开流程的人往往是团队为数不多的负责人，就像刚才的场景，但如果要绕开这个流程就需要请示团队负责人，那这样负责人就会很忙，根本管不过来，最后结果可想而知，按流程走呗。而刚才的问题遇到小团队时，负责人会更快的做出决策，拍板到底要不要绕开流程，而且小团队成员之间也更有默契，大家都是一个整体，这种自我保护的意识相对来说就比较弱化了。
最后，小团队其实对人员的要求要比大团队更高，因为要找到那么多合格的团队负责人，让他们能够为自己的模块或产品负责，就不是那么容易的，然后还要充分的信任和放权。每个团队虽然各自为战，但需要能理解并保持和公司的核心利益一致。这就需要公司的管理团队有足够的智慧，能够协调团队之间的合作和利益。所以实践下来要远比想象中的困难的多。
有时间的话，我在细聊这里面的困难以及如何解决，这篇就先到这里。
