小团队与大团队管理

咱们公司和大部分传统软件公司同样，随着业务的发展和新领域的开拓，公司的管理风格愈来愈像华为，这是否是最佳的演进路线，我以为值得探讨，如下是个人思考，但愿跟你们讨论。

一个问题

前段时间跟一个创业的朋友聊天，提及他们最近在作的一个项目，这是一个教育行业的管理系统，业务很是复杂，牵涉到的决策人，须要对接的系统也很是多，最后问到他们作了多久完成这个项目，朋友告诉我2个多月，6我的，其中还括一个美工，一个项目经理；剩下的都是开发人员，没有测试，没有前端开发；朋友问我，若是这个项目给大家作，大家须要作多久；我想了想说，这个项目若是交给咱们作，顺利的话，至少要半年。

为何差别这么大呢？

咱们一个一个环节来分析一下，朋友的团队跟客户沟通需求的时候，功能性需求只用一个原型草图，非功能性需求就一个excel表格；若是咱们公司作的话，至少要作需求调研报告，需求规格说明书；这个阶段的负责人甚至不会画原型，要到设计阶段才有人能画原型；

到设计阶段，朋友的团队几乎没有什么技术设计，业务按模块给开发人员分一下，各人设计好本身的数据库模型，汇总起来给项目经理看一下，没问题就进入开发阶段了，界面设计花的时间比较久，跟客户反复确认了两三次；若是咱们公司作的话，至少要产出原型设计（低保真描述功能的设计稿，高保真描述界面的设计稿），概要设计，详细设计（技术设计、架构设计、网络设计）等等，并且几乎每一个设计都要经历评审环节，组织评审就要协调人员，要等你们都有时间的时候再作评审，这都是损耗；

到开发测试阶段，朋友的团队几个开发人员从前端到后端，从开发到测试，都是这几我的作；若是咱们公司来作的话，后台开发人员不作前端（不作复杂的前端页面，普通的前端工做仍是要作的），质量保证要测试人员保证，测试把BUG提交到BUG管理工具，开发再去BUG管理工具查阅属于本身的BUG，修改完成以后，再关闭BUG，测试再作回归测试；这些流程看起来琐碎，但却损耗了大量的资源；

验收上线阶段，朋友的团队全部人都铺在项目现场，有问题，当场解决；咱们公司要收集问题，让测试工程师验证问题，再由开发解决，解决以后再验证，再发布版本给现场的实施工程师，实施工程师再更新上线，给客户验证。

这个问题很明显：规模大的团队和规模小的团队工做方式的差别很是大，组织资源的方式也有明显的区别；咱们抽象一下，把这两种模式称为：大军团模式和小编队模式，再看这两种模式的具体区别：

大军团模式

    以前有一种理论，要完成一项超大规模的工程，每每须要成百上千人，有组织有纪律的协做才能完成；

    这样就须要制定一系列的规章、制度、流程、KPI来约束这些人，

    把这些人变成一个庞大机器的零部件，保证结果的达成，避免产生差错；

    这是一种很是常见的大组织的运做模式，

    不但在软件行业广泛存在（华为、惠普、IBM），

    在造桥、修路、航天、汽车等工业领域也十分常见，

    这种模式很是“稳”，他能保证目标的稳定达成，而且能使目标达成的过程清晰、可控。

小编队模式  

    第三次工业革命（信息技术革命）以来，小编队的运做模式发展愈来愈好，我司IPCC产品的核心：开源语音通讯软件FreeSwitch，核心开发者也不过6我的；（说这个开源软件养活了半个呼叫中心行业的开发者都不足为过）； 这种例子在软件行业不胜枚举，好比：git源码管理系统、linux操做系统、JavaScript语言等等。

    甚至有些产品是一我的在短期内完成的，这就是英雄；

    有不少大规模的公司，好比谷歌、Facebook、国内的百度也在内部推行小编队的运做模式；

    这种模式很是“快”，他能保证目标的快速达成，而且能使目标达成的效率很是高；

大军团的不足

效率低下

大军团强调集体的智慧，

个体想推进一项事务向正确的方向推动十分困难，

个体的决策每每会受到质疑或排斥

诸如：流程、规范、计划、考核、文档、评审、调研等词

都是为了保证目标的稳定达成所衍生出来的东西，

它们都是团队快速前进的束缚和绊脚石！

阻碍创新

大军团鼓励墨守成规、照章办事的氛围，

大军团强调分工，把员工看做螺丝钉，但愿员工各司其职，不是职责范围内的事务尽可能不要碰，由于你不专业，你可能会出错，大军团最惧怕出错；

只有这样才能使目标达成的过程清晰可控；

然而创新却须要不拘一格的思想，须要独立自主的工做空间，须要组织具有容错性，这和大军团的工做方式是格格不入的；

资源浪费

为了使目标的达成过程清晰可控；

大军团制定了不少流程和制度来约束个体的行为；

他把每一项事务都拆分红不少环节；

又给每一个环节制定了不少关卡；

并且每一个环节都要留下数据，使过程有迹可寻；

由于大军团要作到每项事务均可以复盘，产生问题以后要能够追溯问题根源；

这样确实保证了目标达成过程的清晰可控，但却浪费了大量的资源；        

小编队的优点

小编队也适合作大项目

有不少很庞大复杂的软件系统，都是以小编队的方式完成的；

好比操做系统linux，大数据分析系统hadoop，咱们这个行业的freeSwitch等；

若是一个项目大到必定的规模，须要不一样角色的人参与，那么也应该是有更多的小编队来作这一块事情；甚至更极端的作法，就是一个项目在建设之初，就考虑到会有不少小编队或我的参与到项目建设过程当中，预留了多人、多团队协做的支撑工具，好比说nodejs的NPM，go语言和rust语言也有相应的规划；

小编队有很强的执行力

小编队不会说这个事情须要作个评审；

小编队不会说这个事情安排的资源不够，须要协调更多的资源；

小编队会把这个事情当成本身的事情，不会像大军团同样，把这个事情当成你们的事情来对待；

咱们来看个图：

 （图片遗失，暂不补充）

小编队有很强的创新力

软件行业不像建筑行业，90%以上的优秀软件一开始都是我的或者小编队创造出来的；不多见一个优秀软件是一个大规模的组织创造出来的。 

一个案例

张小龙曾经说过一段话：

好的工具就不该该黏人，应该帮助用户很是高效率完成任务，而不是说用完了还要拿到手里玩一下子、多用一下子，那不是一个很高效的表现。可是对这样的一些想法的话，我特别但愿它可以根植到你们意识里，时刻想一下什么是咱们作的对用户有价值的事情；

假设你是马化腾，你会怎么给张小龙定KPI呢？考核微信的日活吗？……

不管你制定什么KPI，都会致使团队去围绕着那个KPI去完成任务；

KPI考核准则里有一项原则就是“可度量”，当你提出一项纯数据目标的时候，团队就会围绕着那个数字去工做。而偏离了作好产品的初心。

一个团队工做的目的不该该是完成KPI，工做的目的应该是作好产品，完成KPI只不过是作好产品这件事情的副产物，就像一我的好好工做的目的不该该是为了赚钱，他好好工做的副产物是赚了不少钱；

因此你制定了一系列的kpi考核制度，只能致使员工工做的动机更不纯粹。

最后

一个组织只要发展良好，老是会吸引更多的资源，因此组织规模的扩大是无可避免的，但若是一个组织规模已经超过500人了，那么你应该把他看做是50~100个小团队来对待，而不是把他看成一个500人的大团队来对待；

 ------------------------------

2017-07-13完成以上内容

2017-07-30增补如下内容

康威定律

任何组织在设计一套系统时，所交付的设计方案，在结构上都与该组织的组织结构（沟通结构）保持一致。——梅尔.康威

这个定律说明，组织的结构对系统的性质和质量有着深入的影响；

若是构建系统的组织更加松耦合，其构建的系统则更倾向于模块化，所以耦合度也更低；

若是一个系统足够重要，要求有更松的耦合，更模块化的设计，系统也会反过来要求组织具有这样的特性，这就是反康威定律；

 

我这篇文章并无提到大军团的优点，并不表明大军团没有优点，

相反，有不少项目非“大军团”根本就完不成，好比：卫星里跑的程序，控制原子弹起爆的程序，导弹的制导程序，都须要大军团来作！

然而这些程序毕竟是少数，并且不是咱们身边的东西，大部分时候，咱们仍是须要小编队来作。

亚马逊提出“两个披萨团队”的概念，就是说亚马逊要求组织内部不该该有团队大到两个披萨不够吃。

归根结底，就算很是庞大的组织，也应该强调小团队的协做模式。

 

转自：http://www.javashuo.com/article/p-zjxvcjhm-dp.html