项目管理学习总结（20）——小团队管理与大团队管理

古城微笑少年丶 2023-06-23 02:56 23阅读 0赞

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

# 一个问题 #

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

### 康威定律 ###

任何组织在设计一套系统时，所交付的设计方案，在结构上都与该组织的组织结构（沟通结构）保持一致。——梅尔.康威。这个定律说明，组织的结构对系统的性质和质量有着深刻的影响；如果构建系统的组织更加松耦合，其构建的系统则更倾向于模块化，因此耦合度也更低；如果一个系统足够重要，要求有更松的耦合，更模块化的设计，系统也会反过来要求组织具备这样的特性，这就是反康威定律；

我这篇文章并没有提到大军团的优势，并不代表大军团没有优势，相反，有很多项目非“大军团”根本就完不成，比如：卫星里跑的程序，控制原子弹起爆的程序，导弹的制导程序，都需要大军团来做！然而这些程序毕竟是少数，而且不是我们身边的东西，大部分时候，我们还是需要小编队来做。亚马逊提出“两个披萨团队”的概念，就是说亚马逊要求组织内部不应该有团队大到两个披萨不够吃。归根结底，就算非常庞大的组织，也应该强调小团队的协作模式。