早期，腾讯公司的架构是比较简单的。从上至下分别是：公司——商业单元（BU）——部门——组——员工，每个部门基本上就是负责一个大的产品，每个组都是按照专业进行分工和管理，例如：产品组、终端组、后台组、设计组、运维组、质量组等等。
草拟一个项目需要在每个小组里面抽调人力，部门的总经理就需要和每个小组的组长沟通，经过沟通以后，确定了该项目需要的人力安排，然后就开始执行项目。执行项目过程中的困难，需要决策，例如：人员安排调整，产品需求变更和是否延期发布等等，都需要总经理和组长们开会协调或者私下沟通决定，组员们需要等待协调的结果去执行，这个过程如果需要开会，与会人数有限，并且不能把实际相关的人拉进来，还需要实际执行人员写报告给组长，组长给总经理回报。
在实际执行的结果中，总经理和领导们没有完全了解到实际情况，在开会的时候还会把实际相关的人拉到会议室再确认一遍，最终会议的结果通过每个组长的邮件或者是小组内会议进行传达，员工这才知道执行结果。有时候因为每个组长的理解和表达方式不一样，还会在执行项目的时候暴露信息不一致的问题，这些问题还要经过向上级反馈和确认之后，调整后再次执行。
腾讯公司早期规模不大，人数少，每个部门人数在100人左右，所以产品和项目数都少，上面所说的流程也不算太漫长。直到腾讯公司上市以后，每个部门都进行了扩张，每个部门的人数迅速扩张到200至300人，基层人数激增，领导干部储备不足，并且在成立BU之后，有些横向支撑组还组成了独立部门，这样直接导致在执行项目的时候，要跨部门进行协调工作，慢慢出现了“决策越来越慢”、“流程越来越长”、“团队离用户越来越远”的“大企业病”。
问题出现了，应该要怎么解决呢？
对应以上的问题，腾讯公司决定采用敏捷Scrum做出以下的实践：
- 决策快速化
- 流程轻量化
- 团队自组织
经过一段时间Scrum的实践，为了让Scrum团队实现以上效果，需要做到一些约定：
- 团队成员的角色是齐备的
- 团队承担的业务是闭环的
- 团队成员项目期间最好坐在一起
- 团队规模控制在15人以内
决策快速化
实现决策快速化最大的障碍是任何协调和沟通都需要正式开会。例如，我们每个Scrum团队的团队成员都是角色齐备的，也就是每个Scrum团队具备自己完成业务目标的所有专业角色，包括：产品经理、终端研发人员、后台开发人员、设计师、运维人员、测试人员等等。那么需要作出任何决策的时候，每个团队中团队可以直接作出决策，不需要开会，不需要请示领导，人数不超过15人，既可以找工作桌旁边的任何空地，也可以直接围绕白板开会，会议记录写在白板上，拍下一张照片，发邮件向上汇报记录一下就可以了，这样会议不会超过30分钟，简洁高效，而且团队中每个人都可以参与进来。
看到这里，你可能会产生疑问，每个团队里做出决策就执行， 那领导的存在的价值在哪里？
领导的价值在于：第一、正确规划需要多少组Scrum团队才能完成部门业绩；第二、制定每组Scrum团队的业务目标；第三、确保每组Scrum团队包括所需要的角色和人员。而完成这三件事，就是部门领导存在的价值，如何平衡从中人员调配和目标划分并且完成业绩，这就需要一定的技巧和精力。
流程轻量化
实现流程轻量化的最大障碍是团队没有坐在一起。如果团队中的成员都坐在一起，促进成员之间的沟通和协作，根本不需要系统的流程或者工具来管理，有什么需求和问题，直接说出来就可以了，甚至是要想知道这个成员的工作进展如何，只要走到座位旁边看一眼就知道了。
我曾经拜访过的一些企业里面，我发现，如果某个企业里面，每个人都是在规规矩矩坐在座位上，整个办公场所都是安安静静，连一根针掉在地上都能听见，那么这个企业团队协作是很有问题的，估计团队成员之间的合作只是走流程提单的。团队氛围热热闹闹的，团队成员之间亲密无间的合作，互相之间没有上下级之分地大呼小叫，这样的团队协作氛围更融洽，更容易促进工作协调开展。而冷漠的团队氛围中，每次工作只需要提单走流程，把人与人之间的距离拉得很疏远，即使知道对面的同事也要走流程提工作单，你不提单，别人也不知道你的工作量。
我在腾讯公司管理团队的时候，会想尽一切办法让团队成员相互熟悉起来，每个人的个性、爱好、长处都会得到充分的展现，这样子团队协作才能物尽其用、人尽其才，既然团队成员能够顺畅配合，又何必追求流程呢？
团队自组织
实现团队自组织是最难的。因为业务的闭环是很多企业很难做到的。也去的闭环意义在于，团队所作所为能立即影响业务目标，根据反馈的好坏迅速调整，最终实现业务目标。
我们所看到腾讯公司的大产品，腾讯都会拆分某个模块给某个敏捷团队负责，拆分的原则就是这个产品模块可以独立闭环。
举个例子，具体产品名称就不说了，这个产品里面有一个“搜索框”，就是独立的一直十几人的团队负责。这个团队只负责这个搜索框以及后面的二级页面。根据运营需要，这个搜索框会展示不同的Hot Key，这些Hoy Key除却公司内部的战略要求，其它的都是需要客户付费才会展示的，团队会关注哪些Hot Key 适合展示，这个Hot Key转化率很高，最终这个项目挣的钱最多。而如果你输入一个泛词在这个搜索框搜索，例如“游戏”，每一个展示出来的游戏都需要收费，那么如何评判什么展示效果和演变的算法的标准，就由团队不断根据数据和用户反馈进行调整和优化。当团队的日常运作都在围绕着自己的业务目标的时候，这就代表着他们慢慢自组织起来了。
不超15人的Scrun团队
Scrum团队规模为何要在15人以内，有这方面的原因。首先，根据西方的组织行为学，里面有一个Magic Number “七”。当团队规模大于七个之后，就会有团队成员不能得到周全的照顾了，所以Scrum原本提倡8人以内的小团队。其次，国内的团队最容易被大家接受的团建方式就是吃饭，而国内大部分大圆桌就是12人的，有一些大店有勉强能容纳15个人的大圆桌。吃饭的时候大家都坐在一桌上，很舒服。如果是超过15人的团队的时候， 人与人之间的微妙就开始涌现。如果一个大桌子，大家没得选，随便坐。如果是两个桌子，有一桌有领导，有一桌没有领导，有人早到了，怎么选择？如果团队的人都在一个桌子上，任何人说话，大家都能听见，很好沟通，而两桌的信息传递就有不平衡了。最后，要保持沟通的一致性团队成员就不能大于15人。
敏捷强调团队成员的共识，而随着人数的增加，沟通成本会直线增大。晨会的时候，15个人勉强还能围成一团，再多就没有办法实现了。所以综上所述，一个完备的Scrum团队，最好规模控制在15人以内。当然，能控制8个人的小团队是最好的，但是考虑到全栈工程师和复合型人才太少，所以一般很难做到。
【彩蛋】
上期我们提到一个问题：把Sprint比如一个集装箱，当一个集装箱装不下一头大象的时候，应该怎么办呢？很多同学选择了把大象砍成可以放进去集装箱的体积，然后互相讨论砍头还是砍腿，还是砍屁股呢？就像我们平日开需求评审会一样，大家习惯PK和对抗思维，一点都不在意砍完的大象被装进集装箱是否还有生命意义。其实正确的答案就是，装这头大象的儿子——小象。小象是具有生命意义的，而且如果可以，它最终会长成大象的。一头小象养成成本是很小的，可以减少团队试错的成本，你说这样的方法是否会好一些？
系列文章#
第一辑：我亲历的鹅厂敏捷转型
NO.4 为什么敏捷团队不要超过15人
NO.5 需求没做完可以发布嘛
NO.6 如何打造称手的武器
NO.7 QQ邮箱怎么成为行业第一的
NO.8 你爱上手机QQ么
NO.9 天天系列天天见哟
文章来源：微信公众号“老布谈敏捷”(ID：bootagile)
作者：薛军/Boots，现任：深圳市一起六企业管理有限公司创始人，腾讯大学外聘高级讲师，业问特聘腾讯之道讲师。曾任腾讯项目管理通道委员会会长，腾讯项目管理P4专家，敏捷教练，腾讯LBS总监
本文由@薛军 原创发布于博客园，未经许可禁止转载。
原文地址：https://www.cnblogs.com/bootsagile/p/9642279.html