再谈全功能团队与组织分组

全功能团队与组织分组

任务之间的数据交互如此之频繁，以致于在日常的开发工作中我不得不经常站起身，走到BA和QA面前，说，你好，有个问题需要问一下。于是，公司很明智的，将我们划分到一个团队里，并称之为全功能团队。

 

其实，全功能团队的划分非常自然，在组织分组里，其对应着一个重要的标准：工作流相依性，亦即按照工作流程来进行分组。在具体讨论这个问题之前，我们先从另外一个问题开始：为什么组织需要分组？

 

啊哈，组织分组是为了方便画出各种漂亮的组织结构图，满足领导审美上的需要。

 

很抱歉，不是。

 

恩，对了，是为了让领导搞清楚到底都有些谁在为他干活，免得隔个几年都要搞一次机构精简。

 

也不是。

 

分组是协调组织内部工作的一种不可或缺的手段。其最重要的作用就是建立起一套普遍的监督体系，每个单位都会指定一名管理者，由其对该单位的所有行为负责，这 些管理者又会相互联系，从而建立起组织的权力体系；其次，分组通常要求单位里的人员共享相同的资源，例如硬件机器；最后，分组可以鼓励同一单位内人员的相 互调节（即通过非正式的简单沟通实现对工作的协调），因为大家在同一个地点工作，又共用公用设施，例如厕所，使得大家彼此接近，促进了经常性的非正式接 触。

 

分组带来的最大问题就是：促进了组内协调，却牺牲了组外协调。步兵瑞科就曾愤愤地抱怨：他们就知道在天上飞，我们却在下面送死。（银河舰队）程序员的我也曾经抱怨过：他们就知道提需求，反正也不用自己开发。

 

那么，组织分组的标准有哪些呢？有四个：工作流相依性、工作方法相依性、工作规模相依性和社会相依性。

 

工作流相依性。许多针对特定操作任务之间关系的研究，都着重指出了这样一个结论：对操作任务的分组应该反映出工作流的自然相依性。例如，图6-15是 一位作者对纺织厂中连续生产工序“自然”和“不自然”的看法。以工作流相依性为基础的分组，单位成员会有一种领土完整的感觉，他们支配着一个定义明确的工 作流程，工作中所出现的大多数问题，都可以通过彼此的相互调节而得到轻易的解决。相反，如果一个定义明确的工作流程分解到若干不同单位来完成，那么协调起 来就困难了。组织要求各单位之间能够相互合作，可实际上，单位之间很难进行良好的合作，所以，一旦出现问题，必须呈交给远离工作流程的上级管理者来解决， 而这些上级管理者由于远离实际的工作流程，往往会根据下级汇报做出决策，于是决策的有效性可想而知。（明茨伯格-卓有成效的组织）

 

图 6-15根据工作流对纺织厂的“自然”与“不自然”分组

那么，根据工作流相依性分组的最优解和最差解分别是怎样的呢？我们以软件开发流程来进行说明：

 

图 6-16工作流相依性分组最优解

如果一个单位的职能能够涵盖整个完整的工作流程，则是最优解。在这种情况下，工作中的大部分问题都能在单位内得到解决。如图6-16所示，即开发流程中的大部分工作都能在一个团队内完成，因为这个团队包含了BA、开发人员、测试人员等多种角色的成员，所以也被称为全功能团队。

 

实际上，由工作流相依性重新思考组织分组由来已久。1990 年迈克尔 · 哈默在《哈佛商业评论》上发表了题为《再造：不是自动化改造而是推倒重来》的文章，文中提出的再造思想开创了一场新的管理革命。 1993 年迈克尔 · 哈默和詹姆斯 · 钱皮在其著作《企业再 造：企业革命的宣言 》一书中，首次提出了业务流程再造 (BPR ： Business Process Reengineering) 概念，并将其定义为：对企业业务流程进行根本性的再思考和彻底性的再设计，以取得企业在成本、质量、服务和速度等衡量企业绩效的关键指标上取得显著性的进展。

 

以此为标志，形成了新的业务流程理念，并伴随着对传统企业金字塔式组织理念和管理模式的反思，新的理念强调企业以业务流程为中心进行运作、打破传统的部门隔 阂、增加客户价值和企业效益（降低成本）。以业务流程为中心取代职能分工，成为管理的首要原则，围绕流程建立起来的组织具有更高的敏捷性、效率和效益，呈 现出扁平化、网络化的特征。

 

然而重新思考图6-16所示的全功能团队，你会发现，在很多情况下，在最低层级组建上图所示的全功能团队并不现实（什么是最低层级？意思是该单位不会再有下级单位），出于沟通效率的考虑，一个单位的成员不能够无限扩大，在传统的管理书籍中（法约尔），这个约束甚至被建议为5人。 在很多制造型企业里，这个人数实际上是大大超出这个限制的，原因就在于标准化。然而，在知识密集型企业里，因为并没有一致的标准能够遵循，单位成员之间必 须面对面沟通以协调彼此的工作，那么单位规模必须足够小，小到便于所有成员能够做到适宜、频繁和非正式的沟通。所以，对于一个软件项目而言，一个小于10人的全功能团队是最适合的，一旦团队规模超过20人，那么就必须进行再分组。对很多软件开发而言，他们需要的人数远超20人，那么这种最低层级上的全功能团队就不再适用。

 

图 6-17工作流相依性分组次优解

如果工作流程上的各个单位构成顺序依赖的关系，则是次优解。在这种情况下，每个单位仅仅对其上一个单位产生依赖，单位之间的协调较少。如图6-17所 示，可以看出这是一个典型的以职能进行分组的组织，这样的分组至少看上去并不坏，但是现实却是：这是一个相当没效率的分组。原因就在于该分组基于一个重要 的假设：开发流程中的任务是可以分阶段完成的即瀑布开发模型。现实中，这个假设却是完全不成立的，这些任务联系的如此之紧密，以致于在这些单位之间不得不 时时发生大量的协调。于是该分组实际是下图6-18的样子，最差解！

 

图 6-18工作流相依性分组最差解

如 果工作流程上的各个任务需要跨越多个单位进行反复协调沟通，那么则是最差解，称之为交互式相依。在我观察过的一个组织里边，测试人员发现软件缺陷后的第一 反应不是走过仅仅一屏风之隔的开发小组里进行沟通，而是先填写在线的缺陷跟踪系统，然后再打开即时消息工具，给开发人员发消息：有缺陷，缺陷号是xxx。组织在进行分组时，必须寻求将协调和沟通的成本降至最低。

 

工作方法相依性。即 使用相同工作方法的人员分到一个单位，通常也就是职能分组。这种分组的好处在于能够激发方法的互相交流，也就是专业性，同类专家分到一起之后，他们能够互 相交流，提高各自的专业水平。在现在公司里，经常能够看到不同团队成员之间的非正式交流，这里，其实是公司整体的文化氛围为这种交流提供了便利。实际分组 时，需要在工作流相依性和工作方法相依性间做出权衡。

 

规模相依性。第三个标准与经济规模有关。考虑这样一个例子，软件的测试需要真实的硬件环境进行模拟，而这些硬件比较昂贵，那么一个最经济的方式就是成立专门的测试部，统一购买一批硬件，统一对所有的软件进行上线前测试。同理，由于DBA比较昂贵，公司不可能为每个团队都配备一名，所以DBA不属于任何团队，其是共享的。

 

社会相依性。第四个标准与具体的工作没有关系，与人的社会性有关系。如果领导没有头晕，他是绝对不可能将两个水火不容的人放置到一个单位内的（帝王除外，那叫帝王术）。

 

以上就是组织进行分组的四种标准。归纳一下：如果工作流相依性意义重大而又难以纳入标准的话，那么组织就应该尝试以市场（项目）为基础进行分组，这样便于相 互调节和直接监督；如果工作流不规则，标准化能够涵盖工作流相依性，如果方法和规模相依性意义重大，那么组织应该积极寻求专业化，以职能进行分组。

 

最后，我们讨论一下大规模软件团队的分组，在上面我们提到，一旦人员规模超过20人，那么最低层级上的全功能团队就不再适用，就有必要进行再分组。如何进行再分组呢？图6-19是某IT企业的多层级分组，实际上最重要的是开发部门的按特性分组，每个开发小组都必须能够独立交付产品的一个特性。注意，这里是交付，既然是交付那么就不仅仅包含开发一个任务，还需要包括需求分析与测试，这样，从某种意义上，该开发小组实际构成了全功能团队，实际中，每个开发小组都包括了系统分析人员、开发人员与测试人员。

 

开 发部门按照特性交付分为多个开发小组后，整个产品由一个个模块构成，新的问题出现，就是系统的集成问题，这里的集成问题实际反映出各个开发小组之间的协调 问题。此时，一个独立的测试部门和持续集成就是必须的了，从某种意义上理解，测试部门实际上着重解决的是各个模块间的相互影响以及系统作为一个整体的完整测试，从持续集成的角度考虑，此时最重要的自动化测试应该应用在各个模块之间交互的部分。

 

图 6-19某IT企业的多层级分组

 

一个放之四海皆准，说了也会被人打的说法就是低耦合高内聚。依赖是客观存在的，没有依赖的东西就是没有用的东西。关键是怎么样把相关联的东西分组到一起，达到低耦合高内聚的目的。

强！我想了想，其实写代码和组织分组很多地方的原则是相同的。比如说，减少依赖，特别是循环依赖，完整职责等等。

其实就是：
一个负责保管账户的部门（a部门）
一个负责保管密码的部门（b部门）
在某些时候，我们需要一个全能部门（账户、密码都知道的部门）
而某些时候，为安全性需要分开（a部门、与b部门协调工作）

最后还是可以解释成，易经八卦学说，色即是空，空即是色。

低耦合高内聚，其背后的原因之一是降低变化带来的范围和风险，一般是将系统（软件或组织）中（潜在）容易变化的部分封装起来，并且使对其依赖的部分通过相对稳定的接口来进行通信。而在整个组织中，着眼点一般会放在SOC上。

非常赞同，对于最低层级的组织分组来说，我认为应该是原则。