此博客现在位于 http://i.tigeryaya.cn/。
您会在 30 秒内自动重定向，或者您也可以点击此处。

如果您是供稿订阅者，请更新对 http://i.tigeryaya.cn/feeds/posts/default 的供稿订阅。

据国际组织预报今年地球将进入地球地震年 所以在这里给朋友们推荐一种地震预报的方法是：把一块磁铁用绳子挂在高处，下面正对地板砖或一个铁盆，磁铁上粘一块大铁块。地震前地球磁场发生剧烈变化，磁铁会失去磁性。铁块掉下来，落在地上或盆上，发出响声。此法在房屋没有晃动前就会提前预警。提前时间10分钟至几十秒。如果掉下来了，必发生大震。有什么QQ群的尽量转发一下，让更多的人知道，也许你的传播在以后会救许多人的性命

个人或组织分析诊断之事 本身也有诊断效能高低的分别 也占精力时间这还不能说是工欲善其事必先利其器 应该说成庙算朝议
其组织经营的优秀评价标准应是形而上的方法论 其成果是形而下的组织绩效

杭州省市的大佬同志迟早出事�

春燥 疲劳 人老*

From: hao rong
Date: Sun, 28 Mar 2010 03:15:32 -0700 (PDT)
Subject: 乱语全功能团队与组织分组
To: agilechina@googlegroups.com

*全功能团队与组织分组*
* *

任务之间的数据交互如此之频繁，以致于在日常的开发工作中我不得不经常站起身，走到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企业的多层级分组*

Gmail会在72天之后被封闭。这个事情的可能性为64%。我相信这个可能。

维基百科创始人与国新办在2007年的交流，结果是wikipedia在中国的访问恢复基本稳定，虽然它似乎并没有设置中国服务器。