关于管理<二>：团队合作的十种模型
在上一篇中我们提到了，作为团队的Leader，要做好三件事：
- 你需要找到团队的目标与方向，并朝着这个方向去努力。
- 你需要把团队给组织起来。
- 你需要想办法利用诸如人格魅力等手段，来让组织起来的团队跟着你走。
我们这一篇讲的是如何组织好团队。我们利用十种模型来介绍团队组织的十种形式。其实下面的十种模型，也是我们在软件开发中最常用到的十种模型。
导航目录
团队合作的十种模型
1. 主从模型
主从模型顾名思义就是一个大佬带着一个小弟的合作模型。在这种模型里，Master（大佬）发起所有的事件，小弟只要按部就班的根据大佬的吩咐去做就好了，所以这个合作模型里对小弟的要求比较低。但他也有几个明显的缺点：
- 对Master的要求比较高。这一点很好理解，小弟做什么完全由Master说了算，大佬必须掌控小弟的工作情况才能整个团队小组运转的很好。
- 主机瘫痪则从机也瘫痪，容易“单点故障”。当大佬因为某些原因请假不在时，小弟可能就无所事事，战斗力接近于0了。
- 缺乏积累。大佬因为觉得所有的知识、经验只要自己知道就行了，不需要贡献给其他人，即便记录成文案，也没有谁会去看，所以所有的知识、经验都积累在大佬的脑海里。但日久天长之后很多细节都会忘记，很多有价值的东西在需要的时候就难以想起。大佬一旦离职，对于整个团队来说就是重新开始。
- 容易让主机缺乏对工作量的客观认识。误差是因为小弟每次面临的问题不一样。对于小弟会的东西，小弟可能很快就能搞出来，对于小弟不会的东西，可能要折腾很久才能搞出来。大佬可能会觉得什么都简单，所以评估工作量的时候就会产生误差。
这个模型常见于一些大佬的助理、一些规模小业务相对比较独立的团队，以及一些技术超强的Leader的团队。
2. 点对点模型
点对点模型就是在团队中的两个或者多个人当中，这些成员经验、技能相似，重合度比较高，可替代性也比较强。这样的团队相对稳定性比较好，各方之间的配合也会比较好。因为在团队中，每个成员的角色是对等的，可以灵活的替代，所以每个人都能担当起全部的事情来。每个人在团队合作中，既可以是服务方也可以是需求方。但这个模型也有几个比较明显的缺点：
- 要求两个角色知识技能相当。前文已经提到。
- 存在人力资源浪费的情况。因为团队之间很多事情都是靠商量着来，因此在大量的同质项目的处理上会效率低下。另外两个或多个人干着一个人可能就能干的活，人力可能存在浪费的情况。
- 团队容易有“风气特别好”跟“风气特别差”两种极端。因为团队成员能力相当，所以有的团队的成员可能就会特别争强好胜风气特别好，但有的团队可能就有“凭什么他不做”这样的消极情绪。
一些例子是公司的职能部门，安装组、行政、售后返修组。他们成员大多干着一些相似的工作，遵循着点对点模型。另外一些需要严格确保交付时间的项目，我们可能会投入两倍的人力来确保项目一定能按照时间节点准时完成，这时我们可能就要按照点对点模型来组织。另外在一些对交付时间要求极端苛刻的项目中，我们还曾经尝试过两班倒的案例（A工作12个小时之后交给B继续做12个小时），在这个过程中每个人干的都是相同类型的事情，遵循的就是点对点模型。
3. 代理模型
在代理模型中，一般是有一个人专门负责内部跟外界的沟通对接。外部的项目到了这个团队之后，由“代理”将任务分发给下面的每一个人。当然了对于一般的任务也可能没有“任务拆解/分发”的过程，仅仅只做任务转达，类似于互联网中的“路由器”。在代理模型中，下属的工作体验会比较好，因为外界的任务会被代理人转成易于沟通的、好理解的需求。而且接口人单一，直观上看起来流程上会比较简单。但这些好处只是对于员工的工作体验方面的。这个模型的缺点有：
- 对代理实时性要求高。作为下面的员工跟外界沟通的唯一渠道，代理人必须时刻在线，否则下属很可能因为一个问题没有搞清楚而在那里一直等待没法进行下一步。
- 沟通效率低。因为沟通必须经过代理人中转一次。
- 容易产生沟通理解偏差。
这个模型常常在一些需要统一出口的岗位上，比如一些公司的NPI工程师（负责对接工厂发放生产资料），或者一些文控专员专门负责文件外发的岗位。另外这个模型也常常在一些团队上面看到，比如一些技术上不能完全胜任的Leader，他能做的就是分派任务，这个时候他就可能变成代理人的角色。另外在一些对下属一直放心不下的Leader中也能看到代理模型的影子。
4. C/S模型
是Client-Server模型的简称。这个模型来自于客户端跟服务器交互的过程。客户端跟用户直接打交道。当客户端遇到数据需要请求或处理的时候就提交给Server去处理，Server处理完之后再返回给客户端。这种模型工作起来有不少好处，比如客户端的工作彼此相互独立，客户端以及服务器的规模大小都很灵活，部署起来会很简单。另外Server做的事情相对比较专注，所以做事效率会比较高。另外因为所有的客户端都会依赖于Server，所以客户端提交给Server的内容格式都会比较统一，也便于后期的统一管理。
其实在团队中这种模型大量存在。一般来说存在两种情况。第一种情况，Server是一个老专家。在团队中作为技术顾问或者业务顾问的角色。当Client们在工作中遇到各种问题时，这个时候就可以提交给Server去解决。老专家解决之后又把结果告知Client。第二种情况，Server可能是一个资历不深的助理工程师。在团队中他作为所有Client的助理。当Client遇到自己不想做的杂事的时候，就可以找Server帮忙处理搞定。
这种模型缺点也有：
- 沟通成本大，开发成本高，难以标准化。因为Server看似会处理同质类型的问题，但因为Client端每个人的做事方法、预处理的程度、沟通接口与方式都不同，事情难以从源端进行标准化，因此会带来比较高的沟通成本。
- Client工作仍然繁杂，需等待Server响应。Client作为发起方，要处理除了Server能处理的专业事情以外的所有杂事。多个Client会公用Server的能力，当Server比较繁忙的时候Client需要等待。
- 信息难以完整传递到Server端。Server接收到的往往是经过Client预处理之后的事情。对于整个公司要做的事情，Server往往是没有很好的知情的。
这种模型在我司的软件组应用较多。另外几乎所有的通过系统提单的流程，不出意外的话都是CS模型的流程。
5. 总线模型
在这个模型中，所有的人围绕着一根总线进行沟通。在现实生活中，这个总线可能是某个“微信群”，也可能是某个邮件群组。每个人接收自己工作任务都是通过这个总线，输出工作交付物也是通过这个总线。每个人干什么，完全靠参与者的自觉与良心，具体怎么做，也完全没有什么管控。我们时常看到一些简单的没有很好的管理的临时团队里面，所有人把事情做完之后就把自己的文件往群里一丢。妥妥的总线模型。它的好处就是扩展灵活，我3个人可以遵循总线模型，20个人也可以遵循总线模型。另外它对统一资源管理的要求不高，对管理者的要求也不高。但需要团队的每个成员具有高度的责任心与业界良心，才能把一件事情做得相对比较好。
这种模型的缺点有：
- 信息量大。因为团队的每个人都会获得整个项目的所有信息，包括其他人的中间产物。信息庞杂。
- 流程混杂，对主观能动性要求大。因为没有什么规范的、固定的流程，所以对这里面每个人的主观能动性要求比较高。群里xxx发了一份文件，这个时候每个人就要想到自己需要借着这个文件干什么。
- 角色混乱，交付质量不高。因为缺乏统一的调度与管理，流程混乱，产出质量不高也在情理之中。
这个模型常见于一些缺乏责任心的Leader的团队中。另外我看在公司里，在某个群里评审某个文件的时候就像是这种模型。某个人把待评审的文件往群里一丢，可能也不说什么。有责任心的人可能七嘴八舌点评几句改进意见，没有责任心的人可能就假装没看到。
6. 管道-过滤器模型
管道过滤器模型其实是在总线模型基础上发展起来的。如果我们对总线模型中的每个角色的职责加以定义，明确好每个人干什么，那就变成了管道过滤器模型。在这个模型中，主管发放任务的方式还是“往总线里丢需求”。但因为每个角色负责哪一部分已经有了定义，所以每个角色在收到需求文件时，只需要关注自己应该关注的部分就好了。
这种模型中的每个成员各取所需，所以可以并发工作。每个人的工作也是松耦合，可扩展性也比较好。另外就是团队中的每个成员都可以得到完整的项目信息，对项目的认同度会比较高一些。但这个模型也有一些缺点：
- 信息量偏大。每个人可能需要看一些本来不属于自己看的部分。会造成一些任务目标上的偏差。
- 难以进行错误处理。其实这也是并行执行的项目团队的通病，一旦项目进行过程中出现了某些异常，收回之前发派的并发任务再重新进行错误处理将会是一项大工程。
- 难以联调。每个人的工作拼凑在一起就是整个工作。但是谁来负责拼凑？每个人在负责自己的这一份工作的时候，能否从如何整合的角度去做出最佳质量的交付？
关于管道过滤器模型，最常见的是公司的项目来了之后的多个算法功能的并行开发。
7. 黑板模型
黑板模型又叫“数据共享模型”或者“库+实例化模型”。整个团队的运作依赖于一个库（也就是我们所说的“黑板”）。有一部分人专门负责库的维护与更新，另外一部分人专门负责从库中取出自己需要的部分加以实例化，去满足客户项目的要求。这两部分人之间没有直接的交互，各司其职。他们工作的输入输出通过库来偶联到一起。因为库的存在，他们使用了统一的数据接口，沟通需求量也比较少。更重要的一点就是，因为团队的工作离不开持续不断的对“黑板”的投入，黑板的体量会随着团队的发展越来越大，团队的知识、经验、技能、方法都能够得到很好的积累与沉淀。但这个模型仍然也有一些缺点：
- 对资源存放方式有统一性的要求。所有的黑板（库）的贡献源头必须统一遵守相同的格式，来保证入库的资源的一致性。
- 需要有同步/加锁机制来保证完整性与一致性。黑板上的内容是不断的动态变化的，我们需要有机制来保证完整性与一致性，处理好并发访问、数据完整性等问题。
这个模型在我们硬件设计当中，物料库/标准电路库+实例化开发人员的工作模型中就可以看到。另外在一些融合相关的算法团队中，雷达方案库+实例化开发人员也是遵循着这样的工作模型。
8. 分层模型
分层模型又叫“流水线模型”，主要是因为合作环节中的每个环节都环环相扣，形成一个类似工厂流水线的结构，因此也叫流水线模型。在这个模型中，模型中的每个环节都只需要跟它的上下两层交互，所以交互接口非常简单。另外像很多CPU中的体系架构一样，流水线模型中任务的拆解会非常细致，工作的效率很高。
它的缺点是：
- 并非所有系统都可以这么做，有的系统分层方法困难。懂计算机体系架构的人都知道，要把一个任务分成四份，而且要确保Layer1、Layer2、Layer3、Layer4这四层所花费的时间几乎一模一样，是有多难。
- 信息传输需要经过多个层次才能到达。除了第一层之外，其他层得到的信息都是间接信息，信息经过转发之后其完整性与真实性都值得质疑。
- 难以调试。一旦整个输出物除了问题，那么问题的原因出在哪个地方将会变得难以调试。
- 异常的发生常会引起灾难性的效率降低。流水线模型效率高的原因是因为Layer1、Layer2、Layer3、Layer4四层可以并行处理，但当某个任务出现了跳转时，Layer1、Layer2、Layer3、Layer4中正在进行的所有任务都需要清空重新进行。倘若一个任务经常出现跳转，那么流水线模型的效率甚至可能比单个人的效率还要低。
这里面典型的一些模型是一些公司的嵌入式开发团队，本身就已经是遵循分层开发的原则。另外在公司的一些成体系的流程中，也会遵循流水线原则。
9. MVC模型
MVC分别是指的Model、Visualization、Processing的意思，是指的一个团队中分成三类人：一类人作为Visualization，负责团队的对外接口；一类人作为Processing，负责团队的对内交互与内部资源调动；一类人作为Model，负责核心的技术架构的构建。在这种模型中，因为对外的接口有专门的人负责，同时内部的技术核心架构也有专门的人负责，所以不管对内还是对外，都呈现出一种相对比较稳定的状态。因为有专门对外对接的团队，所以对外界的变更响应速度会比较快。因为核心部分可以沉淀下来，所以当外界变更时，可以只改动一小部分即可满足客户的要求（可能只需要动接口部分）。
这个模型的弱点是增加了系统架构的复杂性，另外如果一个系统的输入输出节点非常多，这个架构没有能从根本上解决实际问题，因为在这种情况下MVC架构中负责Visualization的任务量也会非常大，这个模型能不能很好的执行是持疑的。
最典型的应用MVC模型的是华为的铁三角。在这个模型中，华为的客户支持团队分成了三个角色：客户经理、解决方案专家以及交付专家。客户经理作为Visualization，负责对外接口；解决方案专家作为Model，负责核心技术的开发与应用；交付专家作为Controller，负责对内资源的协调与交互。这三个角色互相制约互相监督互相成就，最后造就了一个又一个从用户角度出去帮助用户真心的解决问题的团队。
10. 解释器模型
第十个模型叫解释器模型。在这个模型中，我们有一个自动化的工具帮助我们解决工作中的问题。这个自动化的工具可能是自动化的代码生成器，也可能是自动化的测试工具。在这样的团队中，有人专门负责自动化工具的开发，有人专门负责针对具体的项目进行实例化的开发（这里包括客户需求的导入以及自动化工具的配置），最终的交付物由工具自动生成。
这个模型的缺点是调试测试比较复杂，而且需要Leader具有非凡的眼光与魄力。而且开发代价比较大，不能很快的适应市场需求的变化。
但它仍然是一个非常好的架构，因为在这样的成熟的体系中，每个人的能力、效率都被发挥到了极致，积极性一般也非常高，交付物的质量也会非常好，团队的凝聚力可想而知。
在我们公司，这样的架构主要存在于仿真测试组中，对于自动化仿真测试平台的开发与应用。另外还在嵌入式AUTOSAR团队中对于AUTOSAR CP代码自动生成器的工作模型中。
团队合作模型的发展与现状
1. 每个职能小组的发展脉络
如下图所示。如果一个职能小组刚开始只有一个人。当他招了第二个人之后，团队合作的模型就已经开始建立了起来。这个时候招的第二个人存在多种情况。
如果引进的是相同业务的同事，如果招的这个人水平不如自己，那么一般情况下是主从模型，自己分派一部分任务给小弟做。如果招的这个人水平跟自己差不多，那么一般情况下是点对点模型，自己做的事情跟对方做的事情商量着来。如果招的这个人业务水平比自己高，如果刚好自己又想偷点懒，那么这个时候一般会是代理模型，自己把所有的任务都交给对方去做。如果招的这个人是技术专家或者业务专家，以顾问的形式存在，那么这个时候一般是CS模型，自己遇到问题的时候会由这个老专家来专门负责解决。
如果引进的是不同业务的同事，那又有两种情况。如果一开始就已经规定了比较好的流程，那么团队一开始往往是按照分层模型去组织。久而久之之后，分层组织里面负责内部核心模块开发的部分找到了套路，对他们自己的工作进行了总结归纳并形成了相对比较固定的核心模块，这个时候就变成MVC模型。当分层组织里面的负责对外对接的部分也做了很多项目找到了套路之后，可能会开发一些项目的自动代码生成器，这样新的项目来了之后团队就可以瞬间完成新项目的开发。这个时候团队组织形式就变成了解释器模型。
当然了如果一开始团队没有很好的组织，那么这个时候很有可能是总线模型。在这个模型中，每个人都靠着自己的主观能动性与责任心，甚至是良心去工作。但时间长了肯定不行，一些人会主动提出来对这里面涉及到的流程进行规范化，对每个人的职责进行明确，这个时候就变成了管道过滤器模型。而如果这个时候有人专门负责建立库并开始把库维护起来，这个时候就变成了黑板模型。
所以在引进相同业务的同事的时候，各种模型其实没有明显的优劣。但在引进不同业务的同事的时候，各个模型之间其实是有比较明显的优劣之分的。
2. 每个团队合作模型的利弊
我们这里对每个团队合作模型从21个维度进行主观打分，可以得到下面的评分表。
需要注意的是，表中的数字全部都是主观评分。1-10，1代表最差，10代表最好。如“适用的最小人数”，1表示适用的最小人数很大，10表示适用的最小人数很小。我们又把主观评分进行了颜色渲染，越接近绿色表示越接近10分，表示越好；越接近红色表示这一项的指标越差。
有了这个评分表之后，我们便可以一眼得知很多团队组织上的奥秘。
- 横向去看，没有任何一种团队合作模型是全能的。每个团队合作模型或多或少的都有绿色的也有红色的。所有模型的平均得分都很相近，一些比较先进的模型，得分也并不高（如MVC模型、黑板模型、解释器模型），而一些很常见的模型，平均得分反而较高。
- 横向去看，如果我们知道了自己团队的合作模型，那么就可以很容易知道当前团队的组织优势是什么，组织上的问题点有哪些。
- 横向去看，如果我们想要解决一个问题，那么可能会需要更换合作模型。但我们必须也要同时看到，我们更换了一个合作模型之后，之前的问题虽然解决了，但可能会同时带来一些其他的新问题，而且带来的新问题的数量往往要比解决的问题的数量要多。
- 纵向去看，虽然我们最后一列写了每个团队合作模型的平均得分，但实际上每个维度的权重是不一样的，有的权重可能因为在特定的环境因素下变得特别重，这都是要额外考虑的。
我们再次强调一遍，这里是对每种合作模型在不同评价维度上的打分，10分代表最好，1分代表最差。因为这里是主观打分，所以使用这个模型时，也允许每个人对这个打分进行修正，形成自己的团队合作模型评估矩阵。