[软件方法]阿布思考法打破创新思维限制

第4章 业务建模 之 业务序列图

我像是一颗棋子，来去全不由自己

《棋子》；词：潘丽玉，曲：杨明煌，唱：王靖雯；1994

上一章我们得到了待改进组织的业务用例图，本章我们将讨论业务建模中最繁重的工作——描述业务用例的实现，即业务流程，然后改进它，推导出待引入系统的用例。

4.1 描述业务流程的手段

描述业务流程的可选手段有文本、活动图和序列图，下面先比较一下它们的优劣。

4.4.1 文本

例如针对财务部“员工→报销”用例的实现，书写业务用例规约如下：

1. 员工把报销单交给财务主管

2. 财务主管确认报销单已经过员工领导审批

3. 财务主管审批报销单

4. 财务主管将审批好的报销单返还给员工

5. 员工把报销单交给会计

6. 会计复核报销单

7. 会计记录报销单

8. 会计把报销单交给出纳

9. 出纳付款

扩展：

2a. 报销单未经员工领导审批：

……

文本的缺点是不够生动，所以在描述业务流程时很少使用文本的方式。不过，描述系统用例（即系统需求）的流程时，文本是常用的，因为此时更注重精确，而且还要表达业务规则、性能等目前尚未被UML标准覆盖的内容。

4.1.2 活动图

用UML图形描述业务流程有两种选择：活动图和序列图。

活动图的前身流程图，应该是在开发人员中使用频率最高的图形了。流程图最早出现于1921年[Gilbreth 1921]，用于机械工程领域。在Goldstine和von Neumann将其引入计算机领域之后，流程图变得流行起来，主要用于在编写文本源代码之前表达跳转逻辑。不过，随着编程语言表达能力也越来越强，针对简单的分支、循环逻辑画一张图很多情况下已经变得没有必要。

活动图在流程图的基础上添加了分区（Partition，即UML1.x中的泳道）、分叉（Fork）、结合（Join）等元素，UML2.x进一步增加了Petri网的元素，表达能力更加丰富。

如果活动图用来表示组织内部的业务流程，那就是业务流程图。上面的报销业务流程用活动图可以表示如下：

图4-1 用活动图描述业务流程

4.1.3 序列图

UML2.x序列图的符号标识来自ITU（国际电信联盟）制定的消息序列图（MSC）标准[ITU-T Z.120]。Ivar Jacobson在“The Object Advantage”一书[Jacobson 1995]中将序列图用于描述业务流程，把业务流程看作是一系列业务对象之间为了完成业务用例而进行的协作。1997年Ivar Jacobson又出了UML版的“Software Reuse”[Jacobson 1997]，其中也有描述。

上面的报销业务流程用序列图可以表示如下：

图4-2 用序列图描述业务流程

4.1.4 序列图和活动图比较

本书所授方法采用序列图来描述业务流程。做出这个选择基于以下几点理由：

（1）活动图只关注人，序列图把人当作系统。

使用活动图描述业务流程时，建模人员往往只注意人或部门的活动，忽略了非人智能系统的责任。上一章已经提到，现在的业务流程中已经有很多领域逻辑是封装在业务实体而不是业务工人中。如果忽略非人智能系统，很多重要信息就丢掉了。

例如，图4-1的活动图未能表达出会计记录报销单和出纳记录付款信息都需要用到现有的电脑系统SCS这个事实，而图4-2的序列图表达出来了。虽然活动图可以稍作变通，将非人系统也单列为分区，但我见过的绝大多数活动图，分区的抬头只是描述人或部门。

（2）活动图表示动作，序列图强迫思考动作背后的目的。

对比图4-3和图4-4：

图4-3 活动图表示动作

图4-4 序列图强迫思考背后的目的

图4-4不但表达了非人系统的责任，同时也清晰地揭示出来营业员这个岗位对外暴露的责任是：受理申请，这也是市民对于营业员的期望。期望和承诺是用例和对象技术的关键思想。使用序列图来做业务建模，“对象协作以完成用例”的思想就可以统一地贯彻业务建模和系统建模的始终。

（3）活动图“灵活”，序列图不“灵活”。

不少人认为活动图胜过序列图的地方是它灵活，但这种灵活是一把双刃剑。活动图很灵活，它的控制流箭头可以指向任何地方，就像编码原始时代的Goto语句，所以活动图很容易画。不过，“很容易画”的活动图，也比较容易掩盖建模人员对业务流程认识不足或者业务流程本身存在缺陷的事实。

图4-5 活动图的灵活是把双刃剑

序列图通过alt、loop等结构化控制片断来描述业务流程，强迫建模人员用这种方式去思考，如图4-6。对于现状确实乱七八糟的流程，描述起来相对要困难，甚至需要按照场景分开画很多张序列图来表达，但这也揭示了业务流程的糟糕现状。

图4-6 带有结构块的序列图

本书选择用序列图来做业务建模，最主要原因还是理由（1）——把人脑系统和电脑系统平等看待。如果您使用活动图或其他方法做业务建模已经做得很好，而且能解决这个问题，就不一定要切换到序列图。毕竟在目前已有的业务流程建模资料中，活动图或类似活动图的手段（如BPMN）占绝大多数，积累了比序列图多得多的参考资料和模型。

这里展开说一个问题：多，不代表有价值。经常有开发人员问我，“潘老师，UML用得好的团队多不多？”我只能回答“不多”（参见第一章关于“冠军的心”的阐述）。于是提问者就释然了，哦，用得好的不多，看起来这个东西用处不大，我不学也没关系的。

围棋下得好的、足球踢得好的、脑外科手术做得好的、长得漂亮的女性…都不多，但是一旦突破门槛进入这个圈子，就会有很大的竞争优势。就拿编码来说，可能读者觉得会编码的人挺多的，周围的人大多都会。其实会编码的人数和会吃喝拉撒的人数相比少得可怜，编码编得好的就更少了，但不能由此推导出“编码没用”的结论，相反，正是因为编码有门槛，所以大多数程序员尽管买不起房，衣食无忧是做得到的。

会用活动图（或者再退一步，会用流程图）来建模业务流程的人已经算是少的了，更多的是随意而画的“草图”，更多的应该是什么都不会画或者懒得画，把脓包一遮了之。

UML提供了交互概述图（Interaction Overview diagram），采用活动图的形式将各个场景的序列图串起来，相当于结合了活动图和序列图的特点，如图4-7。不过，用序列图也可以把其他序列图串起来，所以交互概述图不是必要的。

4-7 交互概述图

4.2 业务序列图要点

4.2.1 消息代表责任分配而不是数据流动

我给图4-2的业务序列图加了一些注解，如图4-8所示。

图4-8 业务序列图主要元素

序列图最重要的要点是消息的含义。A指向B的消息，代表“A请求B做某事”，或者“A调用B做某事的服务”，做某事是B的一个责任。例如，图4-8中，指向财务主管的消息“审批报销单”映射了财务主管的“审批报销单”责任。注意，消息名称中不用带“请求”二字，消息箭头已经有请求的意思。

在序列图中，数据流仅仅作为消息的输入输出参数存在。如果不了解这一点，就容易把消息的方向当成数据流动的方向，不但消息名称没写对，还会出现成对的消息，如图4-9所示。

图4-9 错把消息当成数据流

4.2.2 抽象级别是系统之间的协作

业务建模的研究对象是组织，出现在业务序列图生命线上的对象，其最小颗粒是系统，包括人和非人系统。如果建模人员不把这一点时刻记在心中，打哪指哪，抽象级别随着兴之所至跳跃，就会使业务序列图中混入不该有的内容。

图4-10的业务序列图中，CRM系统的一个组件“客户表”露了出来，因为建模人员突然想到客户资料应该保存在数据库的“客户”表中。其实这个抽象级别不关心CRM系统中是不是使用关系数据库保存数据以及数据库中是不是有一个表叫“客户”。如果真的要考虑系统内部组件这个抽象级别，“分配销售专员”操作也会影响一些表，怎么不画出来？销售支持使用CRM系统记录资料时，大脑指挥，心脏提供能量，手指录入，大脑、心脏、手指怎么没画出来？因为当时的“灵感”没顾及，所以选择性忽略了。

图4-10 系统内部的组件露出来了

另外一种抽象级别跳跃错误如图4-11。要表达销售支持使用CRM系统记录客户资料，只需要在销售支持和CRM系统之间画一条消息“记录客户资料”就够了，这是这两个系统之间协作的目的。不过建模人员刚好想到记录客户资料的过程会有多次交互，于是把这些交互步骤画了出来。

图4-11 表达了过细的交互步骤

其实，图的左侧运营部和销售支持打交道时也可能有多次交互，如果按照图4-11右侧销售支持和CRM系统之间的交互的画法画出来，则如图4-12所示，为什么选择性忽略这部分交互呢？

图4-12 运营部和销售支持的协作也有多次交互

上面说的两种错误是把需求和分析的工作流的工作带入了业务建模。图4-10中提到的系统内部的组件，应该在分析和设计工作流中描述；图4-11中提到的交互步骤，应该在需求工作流中描述。

过早把不同抽象级别的知识混杂，大脑需要处理的逻辑就会从M+N+O+P增加到M*N*O*P。正确的做法是分开表达，这一点本书第8章还会进一步阐述。

还有一种抽象级别错误是：业务序列图的内容和业务用例图差不多。如图4-13，上部是担保公司的业务用例图，而下部的业务序列图直接把担保公司作为一个业务工人画出来了，根本没有剖析出担保公司内部各种人和非人智能系统之间的协作。出现这样的画法，原因很可能是建模人员根本不了解组织内部有哪些岗位，各自承担什么责任，只好把整个组织囫囵当成一个系统画出来。

图4-13 目标组织作为整体出现在业务序列图中

最后要提到的抽象级别错误是：把不具备任何智能的物体放到了业务序列图的生命线上。如图4-14所示。

图4-14 无智能的申请单被错误当成了业务实体

申请单只是一张纸，不具备智能，最多能作为消息参数传递，如图4-15所示。

图4-15 申请单只能作为消息参数

可能有的读者纳闷，我怎么记得看过的书里经常有序列图上出现订单、申请单对象？那是分析序列图。我们用对象的思想去构思我们所开发的系统的内部结构和行为，就得到了订单、申请单等假想的有生命的对象。如图4-16所示。

图4-16 分析序列图生命线上可以有申请单对象

4.2.3 只画核心域相关的系统

业务流程中涉及到的非人智能系统，远远比我们意识到的多，业务序列图上只能表现出其中一部分。例如，图4-11中，运营部请求销售支持处理客户资料时，有可能是通过微信联系的，那么，微信需不需要作为一个业务实体出现在业务序列图中？

大致的判断标准是：如果是核心域相关的系统，应该出现在业务序列图中，如果不是，可以不出现。如图4-17，工作人员制作文档，还是工作人员用Word制作文档？如果描述的是采购的流程，可能左侧就可以，如果描述的是制作文档相关的流程，可能应该画成右侧。具体问题还需要具体分析，所以以上用词是“大致”、“可能”。

      

图4-17 Word要不要画出来？

核心域/非核心域的概念，在后面的工作流中还会不断提到，此处先不详细讨论。有时很难判断也没关系，您想过这个问题，就已经比没想过要好了！可以先画出来，然后如果发现它跟改进无关，再把它删掉。例如图4-17先画出Word，后来发现工作人员用Word还是WPS制作文档，不影响采购流程的改进结果，再把它删掉。

4.2.4 把时间看作特殊的业务实体

业务序列图中，我们把时间看作特殊的业务实体。时间就像上帝造好挂在天上的一个大钟，向全世界各种系统发送时间消息，如图4-18所示。这样，就和后面需求工作流中映射系统用例的时间执行者一致了，同时也帮助理清什么情况下使用时间执行者的问题。

图4-18 把时间当作一个系统

注意：时间和定时器不是一个概念。时间是外系统，定时器是其他系统用来和时间打交道的边界类，如图4-19所示。世界上只有一个时间系统，但有无数的定时器。有的建模人员在识别系统用例时说“执行者是定时器”，这样说是错的，执行者是时间。

图4-19 时间和定时器的区别

4.2.5 为业务对象分配合适的责任

分配给业务对象的责任必须是该对象有能力承担的。在这一点上，我们平时的说话是含糊的，很容易造成误导。例如，“工作人员用Word写标书”这样的说法好像可以接受，但是如果按照说话的文字不假思索画出图4-20，就看出责任分配好像不对。

图4-20 不恰当的责任分配

Word无法承担写标书的责任，这个软件系统里应该没有任何一句代码提到“标书”的概念，只有“文档”、“段落”、“字体”等概念。当前编辑的文档到底是标书还是黄色小说，工作人员的大脑才知道，应该改为图4-21所示。

图4-21 恰当的责任分配

再对比一下图4-22和4-23中分别用算盘和计算器计算时的责任分工。严格来说，算盘不是智能系统，但为了比较，暂且把它放到生命线上。

图4-22 人用算盘计算

图4-23 人用计算器计算

4.3 【步骤】现状业务序列图

假如现在目标组织的业务流程发生，您亲临现场，把观察到的场景如实绘制成业务序列图，就得到了现状业务序列图。

这里最重要的要点就是“如实”。尽力描绘出真实的现状，接下来在此基础上改进，才有可能得到最符合现状需要的改进方案。在凭空想象的现状上改进，得到的必定是假的改进方案、假的系统需求。

黑格尔有一句经常被误解为“存在即合理”的名言——“凡是合乎理性的东西都是现实的；凡是现实的东西都是合乎理性的。”[黑 1820]现状之所以存在，必定有其存在的原因，毕竟大家都不傻！一定要在尊重现实背后的理性的前提下再去改变，贸然改变很可能得不到好结果。 鲁迅曾经长叹“即使搬动一张桌子，改装一个火炉，几乎也要血；”[鲁 1927]，但是从另一个角度想一想，桌子为什么摆在那里？火炉为什么是这个样子？不应该思考一下吗？

尽力描绘出真实的现状，说起来非常简单，做到却极其困难。为了克服困难，建模人员甚至应当在心里暗暗发誓来约束自己：如果不尽力去靠近真相，天打雷劈！

下面列出一些描述现状时经常犯的错误。

4.3.1 错误：把想象中的改进当成现状

现状真的就是现状的意思，意思绝不含糊。很多时候明明已经敲黑板强调了：

——今天是哪一年几月几号？

——****年*月*号

——好，把你的序列图名称的最后加上今天的日子，然后想想如果今天发生这个业务流程，会是什么样的？

即使如此，有的建模人员依然义无反顾地直接画出想象中改进以后的场景，而且自己还没有“是不是画错了”的感觉，被指出来后才恍然大悟。

背后的原因很可能是根本没有深入到组织流程中去做观察和访谈，对现状没有认识，只好想像一个改进后的场景来应付。

4.3.2 错误：把“现状”误解为“纯手工”

待引进系统就像给客户准备的一个礼物。三十年前人们走亲访友，带一包米、一只鸡、一筒饼干作为礼物是非常得体而且受欢迎的，现在大家武装到了牙齿，你还带这些礼物去，对方都不知道怎么说你好呢。

有的建模人员以为人做的事情才是本质的，所以他画的业务流程中，只有人，没有非人系统。业务流程中全是人，那是二十多年前的“现状”，那是先锋、安易、用友等应用软件先驱刚刚起步的年代。基于二十多年前的现状来改进，得到的系统岂不是要和二十年多前的软件一样？这样的软件怎么能适应现在的需要？

如图4-24所示，目标组织于2000年成立，在2010年之前，业务流程主要由人完成。2010年，引进一个软件系统，2014年，又引进一个软件系统，然后A开发团队从2014年开始介入目标组织的信息化工作。2016年，目标组织引进A开发团队开发的软件系统a1，后来，又引进了A开发团队开发的另一个软件系统a2。

图4-24 不同视角看到的组织流程变迁

真正的现状就是图中最下一行的场景。而把“现状”误解为“纯手工”，说的就是把2000年的情况当成现状。

4.3.3 错误：把“现状”误解为“本开发团队未参与之前”

还有一种有趣的错误。A开发团队里的建模人员把图4-24中2014年的情况当成现状，因为在2014年，A团队开始介入，所积累的业务流程资料是从2014年开始的，所以建模人员认为2014年是目标组织的起点——又犯了从自己角度看问题的错误。在A团队看来，只变了两次（0-1-2），在目标组织看来，变了23次（0-1-2……23）。

用第2章提到的“智子法”可以避免这样的错误，A团队的人全部完蛋了，系统是路上捡来的，哪里还有A团队什么事。

4.3.4 错误：把“现状”误解为“规范”

建模人员在建模业务流程时，照搬组织制定的规范，没有去观察实际工作中人们是如何做的，或者即使观察到了人们实际没有按照规范做，却依然按照规范建模。这样做，得到的业务流程是不真实的。上有政策，下有对策，人们在工作时往往会想出一些巧妙的方法，来规避不合理或对自己有损的规范，这些方法中的合理部分就值得计算机系统学习。如果视而不见，也就丧失了许多有价值的改进机会。

4.3.5 错误：“我是创新，没有现状！”

互联网创业公司的开发人员很容易犯这个错误，动不动就说“我做的是互联网创新，没有现状！"

第2章已经说过，老大的大脑就是战场，敌人已经挤得满满当当。老大的时间和金钱是有限的，要让老大赏脸接纳某个系统，必定要动现状某个地方的蛋糕。老大不会因为“好新鲜，没见过这样的东西”就欣然接纳，这个“新”东西必须表现出比现状的某个方面好才行。

创新没什么了不起和神秘的，所有需求工作都是创新。有的时候，创业者号称“创新”的东西，只是创业者自己没做过，觉得“新”而已，客户早就见过了。如果是这样，创业者找块豆腐撞死算了。

4.3.6 错误：“我做产品，没有现状！”

非定制系统的开发团队经常拿这句话做借口。A公司的流程和B公司的流程有差异，中国的流程和外国的流程有差异，画谁的现状好呢？

如果理解了第2章的内容，知道“做需求时把产品当项目做”的道理，就不会困惑了。“现状”指目标组织的现状，是具体而且有最佳答案的。

本书不提供练习题答案，请扫码或访问​​http://www.umlchina.com/book/quiz4_1.htm​​完成在线测试，做到全对，自然就知道答案了。

1. 适合用于描述业务用例的实现——业务流程的UML图有（本题可多选）  A) 活动图  B) 用例图  C) 序列图  D) 状态机图  E) 流程图  F) 依赖图

2. 以下序列图中消息正确的是：  A)  B)  C)  D)

3. 关于在业务建模中使用活动图和序列图，以下说法正确的是（本题可多选）  A) 当前建模人员做业务建模时，序列图使用最多，所以《软件方法》书中以序列图为主。  B) 序列图表示动作，活动图强迫思考动作背后的目的  C) 活动图背后是面向过程的思想，序列图背后是面向对象的思想  D) 活动图的“灵活”是优点也是缺点

4. 在业务流程中有这么一步：助理使用QQ邮箱系统将计划书发给经理。如果QQ邮箱系统在业务流程中有重要的地位，不得忽略，那么以下序列图责任分配合理的是：  A)  B)  C)  D)

5. 以下序列图存在错误的地方有（本题可多选）  A) ①  B) ②  C) ③  D) ④  E) ⑤  F) ⑥

6. 想做一款男女约会神器，提高上垒的成功率。建模人员在描述现状业务流程时犯难了，现状到底是写情书、酒吧勾搭还是用陌陌约？以下做法正确的是：  A) 每种现状都描述，分别改进  B) 因为是做产品，基本没有现状，不用描述现状业务流程  C) 先定位目标人群和老大，再描述现状  D) 写情书是最本质的，应该描述写情书

4.4 案例-现状业务序列图

根据愿景“减少助理在组织公开课时的工作量”，初步判断最值得改进的流程片段是发布公开课通知的片段，如图4-25所示。

图4-25 发布公开课通知的流程片段

4.5 工具操作-现状业务序列图

【步骤1】在UMLChina的业务用例图上右击参加公开课用例，从快捷菜单选择New Child Diagram|Add Diagram。

图4-26 添加图

【步骤2】在New Diagram对话框中，将Name改为发通知201706，在左侧的Select From列表选择UML Behavioral，在右侧的Diagram Types选择Sequence，单击OK按钮。

图4-27 空白序列图

【步骤3】双击业务建模|业务对象包下的业务对象类图。单击工具箱中的，单击类图空白处，在弹出的Class属性框，设置Name为助理，Stereotype选择business worker（如果列表中没有选项，则直接输入文本），单击确定。同上操作添加一个类，名称为时间，Stereotype为business entity。

图4-28 添加业务工人和业务实体

【步骤4】在Project Browser里双击新增加的发通知201706序列图，选择业务对象包下的时间，拖到序列图的最左侧，在弹出的对话框选择Lifeline。单击OK。把业务对象包下的助理，拖到：时间的左侧，在弹出的对话框选择Lifeline。

图4-29 放置实例

【步骤5】单击序列图上的：时间实例，按住右边出现的快捷箭头，拖放到：助理实例，松开。

图4-30 创建消息

【步骤6】双击：时间和：助理之间的消息，在Message Properties属性框上单击Operations按钮，在助理Features属性框，设置Name为筹划公开课，单击Close，单击OK。

图4-31 设置消息

【步骤7】同上操作，在类图中添加业务实体UMLChina系统2013，在序列图上添加生命线和消息如下：

图4-32 继续添加生命线和消息

【步骤8】单击序列图上的：助理生命线最下部，按住右边出现的快捷箭头，拉出然后返回自身，松开。

图4-33 绘制自反消息

【步骤9】将新建的自反消息映射到操作选择候选公开课时间。

图4-34 命名自反消息

【步骤10】同上操作，继续绘制序列图直至得到图4-35。

图4-35 继续绘制序列图

注意图4-35中，在自反消息上传公开课网页到官网的生命周期内，向：Windows发送了消息。这个操作通过单击向右的小箭头完成，如图4-36所示。

图4-36 在自反消息中向其他对象发送消息

【步骤11】单击工具箱里的，再单击创建公开课消息的左上方。调整新增的框的大小，把创建公开课消息以下的消息全部包住。双击框，在Combined Fragment属性框中，选择Type为opt，设置Condition为确认举办。单击OK。

图4-37 添加控制框

4.6 【业务建模步骤1-4】：改进业务序列图

绘制现状的业务序列图后，我们开始来思考：如果通过进一步信息化来改进现状，可以给现状带来什么样的改进？信息化给人类的工作和生活带来的改进，常见的有以下几种：

4.6.1 改进模式一：物流变成信息流

和信息的光电运输比起来，用其他手段运输的物的流转速度就显得太慢了，而且运输成本会随着距离的增加而明显增加。如果同类物的不同实例之间可以相互取代，那么可以提炼物中包含的部分或全部有价值的信息，在需要发生物流的地方，改为通过软件系统交换信息，需要物的时候再将信息变成物，这样可以大大增加流转速度和降低流转成本。如图4-38所示：

图4-38 改进模式一，物流变成信息流

例如，市民要了解新闻，可以去报摊买报纸看，但这会产生各种物流，如果把报纸中包含的有价值信息提炼出来，通过软件系统传送，各种物流就消失了。如图4-39所示

图4-39 物流变成信息流，改进示例

过去二三十年的信息化改进主要着力点就是物流变成信息流。这方面改进对人类社会已经产生了明显的影响。现钞用得越来越少，信件被电子邮件、短信、QQ和微信取代，照相胶卷已经绝迹，人们口中的“文件”默认的不再是纸质文件。

了解了改进一，我们在观察业务流程时，要注意观察各种物的流动，并提炼物背后承载的信息。注意，不要忘了还有人的流动，人可是一个几十公斤的物。例如，从图4-39的左侧，可以发现这么几个物流：市民从家里挪到报摊再挪回家里，钞票从家里挪到报摊，报纸从报摊挪到家里。

除了信息化起步较晚的领域之外，目前各领域在“物流变成信息流”方面留下的改进空间已经不多。随之而来要面对的是信息流转不通畅的问题。

4.6.2 改进模式二：改善信息流转

软件系统越来越多，而各个软件系统之间沟通不畅，导致一个人为了达到某个目的可能需要和多个软件系统打交道，如果把各软件系统之间的协调工作改为由一个软件系统来完成，人只需要和单个软件系统打交道，信息的流转就改进了。如图4-40所示。

图4-40 改进模式二，改善信息流转

例如图4-41，调度科为了出一份报表，不得不在多个业务实体之间疲于奔命（虽然可能只是鼠标在奔），在中间插入新系统之后，工作量减少了很多。如图4-42所示。

图4-41 改善信息流转例子——改进前

图4-42 改善信息流转例子——改进后

了解了改进二，我们在观察业务流程时，要注意观察信息流转不通畅的地方，特别是一些隐蔽的地方。很多人和人的协作中，可能隐藏了信息流转不畅的情况。例如图4-43，专员请求经理审核活动计划，计划是一份电子文件，不离开座位就可以传递，不存在改进一，但是如果更仔细观察，得到图4-44，就可以知道存在改进二。不过如果不影响最终的改进方案，可以不用画出下一个级别的细节，画出图4-43即可。

图4-43 人和人之间的协作

图4-44 人和人协作背后隐藏的改进二

4.6.3 改进模式三：封装领域逻辑

在业务流程中，有很多步骤是由人脑来判断和计算的，也就是说，领域逻辑封装在人脑中。相对于计算机，人脑存在成本高、状态不稳定、会徇私舞弊等问题。如果能够提炼人脑中封装的领域逻辑，改为封装到软件系统中，用软件系统代替人脑，业务流程就得到了改进。

封装领域逻辑的改进如图4-45所示。

图4-45 改进模式三，封装领域逻辑

例如图4-46左侧，思考和计算由销售员负责，组织需要雇用许多有一定经验的销售员，成本相当高。如果能够把销售员大脑中的经验提炼出来，封装到软件系统中，如图4-46右侧所示，组织的成本就降下来了。

图4-46 封装领域逻辑例子

了解了改进三，我们在观察业务流程时，要注意观察和揣摩人脑中的逻辑，特别是有经验的“老司机”大脑里的逻辑，这是十分重要的改进点。不过这有一定的难度，我看过许多人画的业务流程像白开水一样，科长审批，处长审批，局长审批，没有内心活动，好像这些人只是个审批机器。

目前面向大众的互联网（及移动互联网）系统如微信、Facebook、Twitter，完成的大多是改进一和改进二，系统内部封装的逻辑不复杂。经常可以看到这样的场面：稍有新意的互联网系统刚面世，很快就出现几十上百个功能几乎一模一样的模仿者，这些模仿者中有的甚至是几个大学生凑一凑就开发出来的。谁成谁败，决胜点根本不是系统本身的功能，而是谁能早点多点拿到投资来购买内容和大做宣传，风险投资人也声称“投资是投人不是投产品本身”。

说到这里，我要啰嗦几句。近年来，互联网公司的开发人员霸占了各种技术大会的讲台。他们在台上大谈互联网思维和敏捷，在台下听讲的是在电力、税务等行业钻研了十几二十年的研发负责人。乍一听，这TM不就是瞎搞，不就是二三十年前的作坊式开发嘛！不过别不服气，人家公司在美国上市圈了好多钱，而且自身也在盈利！这样的成功事实让台下的研发总监开始反思：人家“瞎搞”，赚这么多，我们一年辛辛苦苦，赚这么点，好，回去马上引进互联网思维，把我们的研发流程互联网化、敏捷化！

这样的反思犯了一个逻辑错误：把并存当作因果。“瞎搞”是事实，“成功”也是事实，但不能得出结论“因为瞎搞，所以成功”、“只要瞎搞，就能成功”或者“只有瞎搞，才能成功”。很可能该互联网公司的背景、人脉以及烧的钱才是公司成功的原因，至于公司里的软件开发团队采用什么开发方法，包括是站着、坐着还是倒立着开发，都不是主要影响因素。

有一天，张三喝醉酒后去买彩票，结果中奖两个亿。大家请张三上台介绍致富经验，张三介绍“我那天喝醉了酒去买彩票就中奖了”，台下听讲的彩民纷纷去喝醉买彩票，以为这样就能中奖，这就犯了同样的逻辑错误。张三之所以能中奖，背后肯定有原因，只不过这个原因很复杂，属于“上帝算法”，人类目前还算不清楚（否则借来算一下明天双色球多好），偶尔会归因为“祖上积德”之类，但应该不是喝醉了酒。

可惜，不少演讲人为了往自己脸上贴金，把并存混淆成了因果——“我们网站很成功，我们网站用PHP开发，所以PHP是最好的语言。”

中央纪委监察部网站、12306网站，访问量非常大，而且访问者忠诚度极高。到底用了什么方法和开发平台，能做出这么棒的网站？可惜，这些网站的研发负责人似乎比较低调，没有出来揽功，因为他们知道自己的贡献是多少。

可能有人要说“某某网站要应付这么多用户，背后技术门槛也不低”。我们再拿张三中奖的故事类比。张三中两亿大奖，必须纳四千万所得税。李四看到了张三中奖和纳税四千万的过程，于是预交了四千万给税务局再去买彩票，那么，李四的中奖概率会大大提高吗？

纳税是中奖带来的“快乐的痛苦”，不是中奖的原因。互联网公司的很多开发人员属于“纳税型”，是公司的成功带来了他，他却误以为自己带来了公司的成功。所以不要再拿“没有我们，就没法应付双11”来说事了，有几个网站因为用户太多倒闭的？倒是不少网站准备好了应付上亿用户，偏偏大家就是不用你。

专注于一个领域的行业软件，凝结了该行业的丰富领域知识，达到了改进三。这样的系统就能够靠软件本身的功能挣钱，它的开发团队介绍的经验值得借鉴。不过，开发这种系统的公司往往是“隐形冠军”，在它所处的领域大名鼎鼎，在大众媒体却无声无息。

不过，随着互联网跑马圈地的结束，互联网公司逐渐变成了行业巨头，领域逻辑需要越挖越深，改进三所占的比重越来越大。这方面的讨论会在第8章继续。

4.6.4 阿布思考法

张三断了一只手，一开始很痛苦，只剩下一只手以后的日子怎么过啊！过了些天，痛苦就慢慢淡了，因为他看了不少新闻，里面有车祸死人、火灾死人甚至躲猫猫死人，心里一比较就觉得自己很幸运，又开始快快乐乐地生活了。

人会调节自己适应现实，这是好事。如果没有这种自我调节的能力，人会一直沉溺在痛苦之中。不过，这种能力确实是捕获和探索需求的一个大障碍。例如，张三刚使用某个软件时痛苦不堪，谁做的软件，简直就是狗屎！用了一个月，他不但适应了这摊狗屎，还安慰自己，现在这个不景气的时节，有份工作做就不错了，人家想要来受这份累还没机会呢！这个时候如果需求人员去找他调研改进，他已经把痛苦忘得一干二净，麻木了，习惯了，而需求人员还以为形势一片大好呢！

如果面对痛苦的是一位有钱或有权的人，结果会不一样。让我们把这位有钱有权的人叫做“阿布”。阿布借用了中国人对俄罗斯大富豪罗曼·阿布拉莫维奇（Roman Abramovich）的称呼。2003年，罗曼·阿布拉莫维奇收购英格兰球会切尔西，招来教练穆里尼奥，改变了英超的格局，从此阿布广为人知。

阿布如果断了一只手，他不会像普通人一样善罢甘休。阿布会想：能不能移植一只手？如果肢体移植技术成熟，阿布拍出500万美元，会有“志愿者”乐意把自己的手奉上。如果肢体移植的技术还不成熟，阿布会投资成立一家肢体移植研究中心，招揽优秀医学专家来研究肢体再生和移植技术。再不济，阿布还可以找精密仪器专家帮他定制一只电子手。

学会像阿布一样思考，有助于克服普通人因资源受限而不敢展开想象的思维障碍。阿布思考法的分两步：

（1）假设有充足的资源去解决问题，得到一个完美的方案；

（2）用手上现有的资源去山寨这个完美方案。

如果有一个方案，花费完美方案1%的资源，能达到完美方案20％效果。这个方案已经是目前最好的方案了，因为它是在突破思维限制以后一步步往后退得来的。

小时候有一个让我印象很深的辩论：慈禧太后幸福还是现代的工人幸福？认为工人幸福的那一方的辩解理由之一是“工人回到家有电视看，慈禧太后有电视看吗？”事实上，慈禧太后虽然没有我们今天的“电视”看，但她有权有势，想看什么戏，只要通过太监传召，各种戏班名角马上入宫开演，而且是3D的、超大屏幕的现场直播。可惜的是，这种生活太昂贵，全国只有她老人家一个人享受，普通人怎么办呢，看山寨版——2D的小电视呗！

许多改善人类现代生活的伟大创新，其实就是用廉价的替代方案来山寨过去富豪和高官的生活，然后让它为平民服务。既然如此，我们就可以推理，将来平民的生活就是现在富豪高官的生活的山寨版。如果善于观察现在富豪高官的生活，想办法山寨后卖给平民，就占到了创新的先机。