⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 https://www.cnblogs.com/liulun/p/7159705.html 「liulun」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

艿艿：欢迎胖友，在留言说说你的看法？

我们公司和大部分传统软件公司一样，随着业务的发展和新领域的开拓，公司的管理风格越来越像华为，这是不是最佳的演进路线，我觉得值得探讨，以下是我的思考，希望跟大家讨论。

一个问题

前段时间跟一个创业的朋友聊天，说起他们最近在做的一个项目，这是一个教育行业的管理系统，业务非常复杂，牵涉到的决策人，需要对接的系统也非常多，最后问到他们做了多久完成这个项目，朋友告诉我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增补以下内容

** 康威定律**

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

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

如果构建系统的组织更加松耦合，其构建的系统则更倾向于模块化，因此耦合度也更低；

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

我这篇文章并没有提到大军团的优势，并不代表大军团没有优势，

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

然而这些程序毕竟是少数，而且不是我们身边的东西，大部分时候，我们还是需要小编队来做。

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

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

芋道源码 —— 纯源码解析博客

小团队？大团队？优缺点对比