小团队管理与大团队管理
（给PHP开发者加星标，提升PHP技能）
转自：liulun
www.cnblogs.com/liulun/p/7159705.html
我们公司和大部分传统软件公司一样，随着业务的发展和新领域的开拓，公司的管理风格越来越像华为，这是不是最佳的演进路线，我觉得值得探讨，以下是我的思考，希望跟大家讨论。
一个问题
前段时间跟一个创业的朋友聊天，说起他们最近在做的一个项目，这是一个教育行业的管理系统，业务非常复杂，牵涉到的决策人，需要对接的系统也非常多，最后问到他们做了多久完成这个项目，朋友告诉我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人的大团队来对待；
康威定律
任何组织在设计一套系统时，所交付的设计方案，在结构上都与该组织的组织结构（沟通结构）保持一致。——梅尔.康威
这个定律说明，组织的结构对系统的性质和质量有着深刻的影响；
如果构建系统的组织更加松耦合，其构建的系统则更倾向于模块化，因此耦合度也更低；
如果一个系统足够重要，要求有更松的耦合，更模块化的设计，系统也会反过来要求组织具备这样的特性，这就是反康威定律；
我这篇文章并没有提到大军团的优势，并不代表大军团没有优势，
相反，有很多项目非“大军团”根本就完不成，比如：卫星里跑的程序，控制原子弹起爆的程序，导弹的制导程序，都需要大军团来做！
然而这些程序毕竟是少数，而且不是我们身边的东西，大部分时候，我们还是需要小编队来做。
亚马逊提出“两个披萨团队”的概念，就是说亚马逊要求组织内部不应该有团队大到两个披萨不够吃。
归根结底，就算非常庞大的组织，也应该强调小团队的协作模式。
- EOF -
看完本文有收获？请分享给更多人
关注「PHP开发者」加星标，提升PHP技能
好文章，我在看❤️