工作流模式-工作流资源模式43种
版权声明：工作流模式版权归 Workflow Patterns 组 织 ( http://www.workflowpatterns.com ) 所 有 。 经 Workflow Patterns授权，中文简体版由辛鹏和荣浩翻译。未经译者书面许可，不得将该中文简体版用于商业目的。
组织结构涉及两个基本要求：一方面要把某个创造价值的活动拆分成不同的活动，另一方面又要将各项活动协调整合起来，以便实现最终目标。
在附录A里，我们讨论了工作流控制模式，即组织结构的第一个基本要求，强调对业务流程进行建模，将商业目标的实现根据组织所进行的工作和现有的技术体系拆分成一系列的活动。这里将接着介绍工作流的资源模式，活动协调的本质其实是组织内部资源的协调，即满足组织机构的第二个基本要求。
活动的执行需要资源，资源的协调对业务流程执行的效率非常重要，对顾客而言，流程执行的时间越短则越有效率。
什么是资源呢？
人是最重要的资源，除了人之外，还有其他的非人力资源，如机器、设备、计算机等。资源最根本的特征是：它能够执行特定的活动。
一个资源只能执行有限种类的活动。反过来，一个活动通常也只能被有限种类的资源所执行，这涉及资源的分组。组织对资源的分组具有多种形式，最常见的是部门和角色：部门体现资源在组织中的位置，角色体现资源的业务职能。对跨国跨地域的组织而言，还有地域机构的划分，此外还有临时组，例如以交付为核心的软件开发公司里的项目组。
为保证流程中每个活动都由合适的资源执行，我们在活动建模时定义分配规则，该规则说明执行该活动资源所需要符合的前提条件和约束。分配规则可以直接指定到特定资源（直接分配到具体的人执行），也可以是多个资源分组的交集（例如销售部的经理），还可能依赖于活动/流程实例本身属性（例如对于北京地区提交的货物订单会交由北京配送中心进行处理），此外，还有其他一些考虑，例如为安全考虑，银行任何职员不能执行同一流程实例中两个连续的活动，会计学里称之为职能分离。我们会在后面的资源模式里详细讨论这些情况。
在工作流系统里，活动在运行期被映射为工作项（work item），活动的执行被映射为工作项的执行。一般情况下，一个活动在一个流程实例中只对应一个工作项，但是存在一个活动需要多人完成的情况，这个时候一个活动就会对应着多个工作项。工作项是工作流系统中最小的工作单元，其代表着一个单一资源对某一活动的执行。工作流系统里，资源与工作项的交互通过工作项管理器进行管理，即我们通常所见的工作项列表（任务列表），我们通过这一列表拾取工作、处理工作以及管理工作的状态。
工作项的生命周期
工作项的生命周期具有8个状态，分别是创建（Created）、提供给一个资源拾取（Offered Single Resource）、提供给多个资源拾取（Offered Multiple Resources）、指派给一个资源负责执行（Allocated）、执行（Started）、完成（Completed）、失败（Failed）和挂起（Suspended），如图B-1所示。
图B-1 工作项的生命周期
工作项被系统创建完毕后即处于创建状态，接下来系统会选取资源来执行该工作项。有两种状态：一种是被提供状态，一种是被指派状态，这两者的区别在于对资源来说一个是可选的一个是必须的。如果系统提供一个工作项给资源执行，这仅仅意味着资源符合执行该工作的前提条件，资源不必为该工作负责，即资源可以选择执行该工作也可以选择拒绝，资源只是该工作的合适候选者；而如果系统指派一个工作项给资源执行，则意味着资源必须为该工作负责，该工作必须由该资源执行。因为一个工作项只能由一个资源来执行，所以如果是指派的话，那么只能指定一个资源；而提供，则可以提供给一个资源也可以提供给多个资源来候选。工作项管理器提供两种列表来区分这两种状态，分别是可拾取列表和待办列表，一旦资源对可拾取列表里的工作项进行拾取，工作项即进入到资源的待办列表，状态成为被指派状态。
工作项进入被指派状态意味着执行该工作的资源已确定，那么接下来就可以由资源开始执行该工作，执行的过程中可以将工作暂时挂起中断处理，后续可以再恢复对该工作的执行。如果工作成功完成，则工作项成为完成状态；如果工作因为各种原因没有成功完成，则工作项置为失败状态。
工作流资源模式的分类
工作流资源模式共有43种，根据工作项所处的不同阶段以及状态变迁，分为7组，即创建模式、推模式、拉模式、折回模式、自动开始模式、可见性模式和多资源模式，如图B-2所示。
- 创建模式位于工作项生命周期的创建阶段，作为流程模型的一部分在流程定义期指定活动的分配规则，限定执行该活动的资源范围；
- 推模式将创建完毕的工作项与满足分配规则的资源进行匹配，将工作项推送给资源，源本身不做出选择；
- 拉模式则是资源把工作项与自身进行匹配，考察其能够执行的工作项并选择执行，资源是主动的；
- 折回模式对应着由于各种原因所导致的工作项状态的反复和回退；
- 自动开始模式提供一种系统驱动工作项执行的方式，表明工作项的高优先级，需要马上开始执行；
- 可见性模式讨论各种不同资源对工作项的可见性，与管理权限相关；
- 多资源模式讨论一个资源执行多个工作项和多个资源执行同一个工作项的特殊情况。
图B-2 工作流资源模式的分类
分组是协调组织内部工作的一种不可或缺的手段，其最重要的作用就是建立起一套普遍的监督体系，每个单位都会指定一名管理者，由其对该单位的所有行为负责，这些管理者又会相互联系，从而建立起组织的权力体系；其次，分组通常要求单位里的人员共享相同的资源，如硬件机器；最后，分组可以鼓励同一单位内人员的相互调节（即通过非正式的简单沟通实现对工作的协调），因为大家在同一个地点工作，又共用公用设施，如厕所，使得大家彼此接近，促进了经常性的非正式接触。
分组带来的最大问题就是：促进了组内协调，却牺牲了组外协调。步兵瑞科就曾愤愤地抱怨：他们就知道在天上飞，我们却在下面送死。（《银河舰队》）作为开发人员的我们也曾经抱怨过：他们就知道提需求，反正也不用自己开发。
组织分组的标准
那么，组织分组的标准有哪些呢？有以下4个：
- 工作流相依性；
- 工作方法相依性；
- 工作规模相依；
- 社会相依性。
工作流相依性
许多针对特定操作活动之间关系的研究，都着重指出了这样一个结论：对操作活动的分组应该反映出工作流的自然相依性。例如，图B-3所示是一位作者对纺织厂中连续生产工序“自然”和“不自然”的看法。以工作流相依性为基础的分组，单位成员会有一种领土完整的感觉，他们支配着一个定义明确的工作流程，工作中所出现的大多数问题，都可以通过彼此的相互调节而得到轻易的解决。相反，如果一个定义明确的工作流程分解到若干不同单位来完成，那么协调起来就困难了。组织要求各单位之间能够相互合作，可实际上，单位之间很难进行良好的合作，所以，一旦出现问题，必须呈交给远离工作流程的上级管理者来解决，而这些上级管理者由于远离实际的工作流程，往往会根据下级汇报做出决策，于是决策的有效性可想而知（参见明茨伯格的《卓有成效的组织》）。
图B-3 根据工作流对纺织厂的“自然”与“不自然”分组
那么，根据工作流相依性分组的最优解和最差解分别是怎样的呢？我们以软件开发流程来进行说明。如果一个单位的职能能够涵盖整个完整的工作流程，则是最优解。在这种情况下，工作中的大部分问题都能在单位内得到解决。如图B-4所示，开发流程中的大部分工作都能在一个团队内完成，这个团队包含了BA、开发人员、测试人员等多种角色的成员，所以也被称为全功能团队或闭环团队。
图B-4 工作流相依性分组最优解
由工作流相依性重新思考组织分组由来已久。1990 年，迈克尔·哈默在《哈佛商业评论》上发表了题为“再造：不是自动化改造而是推倒重来”的文章，文中提出的再造思想开创了一场新的管理革命。以此为标志，形成了新的业务流程理念，并伴随着对传统企业金字塔式组织理念和管理模式的反思，新的理念强调企业以业务流程为中心进行运作、打破传统的部门隔阂、增加客户价值和企业效益（降低成本）。以业务流程为中心取代职能分工，成为管理的首要原则，围绕流程建立起来的组织具有更高的敏捷性、效率和效益，呈现出扁平化、网络化的特征。
然而，重新思考图B-4所示的全功能团队我们会发现，在很多情况下，在最低层级组建上图所示的全功能团队并不现实（什么是最低层级？意思是该单位不会再有下级单位），出于沟通效率的考虑，一个单位的成员不能够无限扩大，在传统的管理书籍中（法约尔），这个约束甚至被建议为5人。在很多制造型企业里，这个人数实际上是大大超出这个限制的，原因就在于标准化。
然而，在知识密集型企业里，因为并没有一致的标准能够遵循，单位成员之间必须面对面沟通以协调彼此的工作，那么单位规模必须足够小，小到便于所有成员能够做到适宜、频繁和非正式的沟通。所以，对于一个软件项目而言，一个小于10人的全功能团队是最适合的，一旦团队规模超过20人，那么就必须进行再分组。对很多软件开发而言，他们需要的人数远超20人，那么这种最低层级上的全功能团队就不再适用。
如果工作流程上的各个单位构成顺序依赖的关系，则是次优解。在这种情况下，每个单位仅仅对其上一个单位产生依赖，单位之间的协调较少。如图B-5所示，可以看出这是一个典型的以职能进行分组的组织，这样的分组至少看上去并不坏，但是现实却是：这是一个相当没效率的分组。原因就在于该分组基于一个重要的假设：开发流程中的活动是可以分阶段完成的即瀑布开发模型。现实中，这个假设却是完全不成立的，这些活动联系的如此之紧密，以致于在这些单位之间不得不时时发生大量的协调。于是该分组实际是图B-6的样子，最差解！
图B-5 工作流相依性分组次优解
如果工作流程上的各个活动需要跨越多个单位进行反复协调沟通，那么则是最差解，称之为交互式相依，如图B-6所示。在我们观察过的一个组织里边，测试人员发现软件缺陷后的第一反应不是走过仅仅一屏风之隔的开发小组里进行沟通，而是先填写在线的缺陷跟踪系统，然后再打开即时消息工具，给开发人员发消息：有缺陷，缺陷号是xxx。组织在进行分组时，必须寻求将协调和沟通的成本降至最低。
图B-6 工作流相依性分组最差解
工作方法相依性
即使用相同工作方法的人员分到一个单位，通常也就是职能分组。这种分组的好处在于能够激发方法的互相交流，也就是专业性，同类专家分到一起之后，他们能够互相交流，提高各自的专业水平。在现在公司里，经常能够看到不同团队成员之间的非正式交流，这里，其实是公司整体的文化氛围为这种交流提供了便利。实际分组时，需要在工作流相依性和工作方法相依性间做出权衡。
规模相依性
第三个标准与经济规模有关。考虑这样一个例子，软件的测试需要真实的硬件环境进行模拟，而这些硬件比较昂贵，那么一个最经济的方式就是成立专门的测试部，统一购买一批硬件，统一对所有的软件进行上线前测试。同理，由于DBA比较昂贵，公司不可能为每个团队都配备一名，所以DBA不属于任何团队，其是共享的。
社会相依性
第四个标准与具体的工作没有关系，与人的社会性有关系。如果领导没有头晕，他是绝对不可能将两个水火不容的人放置到一个单位内的（帝王除外，那叫帝王术）。以上就是组织进行分组的4种标准。归纳一下：如果工作流相依性意义重大而又难以纳入标准的话，那么组织就应该尝试以市场（项目）为基础进行分组，这样便于相互调节和直接监督；如果工作流不规则，标准化能够涵盖工作流相依性，如果方法和规模相依性意义重大，那么组织应该积极寻求专业化，以职能进行分组。
最后，我们讨论一下大规模软件团队的分组.在上面我们提到，一旦人员规模超过20人，那么最低层级上的全功能团队就不再适用，就有必要进行再分组。如何进行再分组呢？图B-7所示是某IT企业的多层级分组，实际上最重要的是开发部门的按特性分组，每个开发小组都必须能够独立交付产品的一个特性。注意，这里是交付，既然是交付那么就不仅仅包含开发一个活动，还需要包括需求分析与测试，这样，从某种意义上，该开发小组实际构成了全功能团队，实际中，每个开发小组都包括了系统分析人员、开发人员与测试人员。
B-7 某IT企业的多层级分组
开发部门按照特性交付分为多个开发小组后，整个产品由一个个模块构成，新的问题出现，就是系统的集成问题，这里的集成问题实际反映出各个开发小组之间的协调问题。此时，一个独立的测试部门和持续集成就是必须的了，从某种意义上理解，测试部门实际上着重解决的是各个模块间的相互影响以及系统作为一个整体的完整测试，从持续集成的角度考虑，此时最重要的自动化测试应该应用在各个模块之间交互的部分。
小结
在本章里，我们讨论了工作流的43种资源模式，这些模式分为7类，分别是创建模式、推模 式、拉模式、折回模式、自动开始模式、可见性模式和多资源模式。
- 创建模式在系统创建工作项时生效，其位于工作项生命周期的创建阶段，创建模式作为流程 模型的组成部分在流程定义期、在活动节点的定义里进行定义，与资源关联，用来限定可执行该 活动的资源范围。系统根据创建模式限定的资源范围生成工作项。
- 接下来，系统需要将工作项推送给相关的资源进行执行，这个推送的过程即是推模式所包含 的内容。工作流系统通过工作项管理器即不同类型的工作项列表与用户进行交互，这里的推送可 以理解为系统将生成的工作项推送至相应资源的工作项列表里。
- 推模式的主语是系统，由系统将工作项推送至资源的工作项列表，那么，接下来的主动权交 由单个资源本身，由其拉动工作项的执行，这是拉模式所包含的内容。
- 实际工作中，工作的执行状态不可能总是与预想相符的，总会出现各种各样的情况，例如重 新分配、重做、挂起等。折回模式对应着这些情况，折回代表着工作项状态的反复、回退。
- 自动开始模式提供了一种系统驱动工作项执行的方式，系统直接驱动工作项执行表明了该工 作项的高优先级，需要马上开始执行。
- 可见性模式讨论各种不同资源对工作项的可见性，工作项自身作为资源与权限相关。
- 多资源模式讨论一个资源执行多个工作项和多个资源执行同一个工作项的情况。
从这些模式的讨论可以看出，这些模式关注的是组织内部资源的协调，关注通过合理分配工 作和调配工作的执行为组织带来最高的执行效率。但组织内部资源协调所包含的内容远远超出这 些模式，如何让组织内所有人目标一致向着一个方向努力，如何将最合适的人放到最合适的岗位， 如何建设闭环团队避免跨团队的沟通成本，这些都是实际工作中我们所要不断思考的。
人，永远 是管理中最重要的因素。
