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

← 返回《软件方法》

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

4.1 描述业务流程的手段 #

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

4.1.1 文本 #

例如针对财务部“员工→报销”用例的实现，书写业务用例规约如下： 1．员工把报销单交给财务主管 2．财务主管确认报销单已经过员工领导审批 3．财务主管审批报销单 4．财务主管将审批好的报销单返还给员工 5．员工把报销单交给会计 6．会计复核报销单 7．会计记录报销单 8．会计把报销单交给出纳 9．出纳付款 扩展： 2a．报销单未经员工领导审批：

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

4.1.2 活动图 #

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

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

活动图在流程图的基础上添加了分区（Partition，即UML1.x中的泳 道）、分叉（Fork）、结合（Join）等元素，UML2.x进一步增加了 Petri网的元素，表达能力更加丰富。 如果活动图用来表示组织内部的业务流程，那就是业务流程图。

4.1.3 序列图 #

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

上面的报销业务流程可以用序列图表示，如图4-2所示。

图4-2 用序列图描述业务流程
@startuml
actor "员工" as 员工
actor "财务主管" as 财务主管
actor "会计" as 会计
actor "SCS" as SCS
actor "出纳" as 出纳
员工 -> 财务主管 : 审批报销单(报销单)
财务主管 -> 财务主管 : 确认报销单已经员工领导审批()
财务主管 -> 财务主管 : 执行审批()
财务主管 -> 财务主管 : 返还给员工()
员工 -> 会计 : 复核报销单(报销单)
会计 -> 会计 : 记录报销单()
会计 -> SCS : 付款()
SCS -> 出纳 : 记录付款信息()
会计 --> 员工 : (返回)
@enduml

4.1.4 序列图和活动图比较 #

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

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

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

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

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

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

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

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

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

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

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

围棋下得好的、足球踢得好的、脑外科手术做得好的、身材长得好 的……都不多，但是一旦突破门槛进入这个圈子，就会有很大的竞争 优势。就拿编码来说，可能读者觉得会编码的人挺多的，周围的人大 多都会。其实会编码的人数和会吃喝拉撒的人数相比少得可怜，编码 编得好的就更少了，但不能由此推导出“编码没用”的结论，相反，正 是因为编码有门槛，所以大多数程序员尽管买房不容易，衣食无忧是 做得到的。 会用活动图（或者再退一步，会用流程图）来建模业务流程的人已经 算是少的了，更多的是随意画的“草图”，更普遍的应该是什么都不会 画或者懒得画，把“脓包”一遮了之。

UML提供了交互概述图（Interaction Overview Diagram），采用活动图 的形式将各个场景的序列图串起来，相当于结合了活动图和序列图的 特点。不过，用序列图通过交互引用也可以把多张序列图串起来，交互概述图不是必要的。

4.2 业务序列图要点 #

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

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

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

图4-9 错把消息当成数据流
@startuml
actor "员工" as 员工
actor "财务主管" as 财务主管
员工 -> 财务主管 : 把报销单交给财务()
note right of 财务主管
  ❌ 错误：消息名称应为动词+对象，消息箭头已经有请求的意思
end note
财务主管 -> 财务主管 : 确认报销单已经员工领导审批()
财务主管 -> 财务主管 : 执行审批()
财务主管 -> 员工 : 返还给员工()
note right of 员工
  ❌ 错误：箭头表示责任分配，审批是财务主管的责任
end note
@enduml

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

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

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

图4-10 系统内部的组件露出来了
@startuml
actor "运营部" as 运营部
actor "销售支持" as 销售支持
participant "CRM系统" as CRM系统
participant "客户表" as 客户表
actor "销售专员" as 销售专员
actor "客户" as 客户
运营部 -> 销售支持 : 处理客户资料()
销售支持 -> CRM系统 : 记录客户资料()
CRM系统 -> 客户表 : 新增客户()
客户表 -> 客户表 : 分配销售专员()
客户表 -> 销售专员 : 提供客户资料()
销售专员 -> 客户 : 联系客户()
note right of 客户表
  ⚠️ 业务建模级别，不应出现系统内部的组件
end note
@enduml

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

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

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

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

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

@startuml
' 图4-13：目标组织作为整体出现在业务序列图中
actor "企业" as 企业
actor "银行" as 银行
rectangle "担保公司" {
    (担保贷款)
}
企业 --> (担保贷款)
(担保贷款) --> 银行
@enduml
@startuml
' 图4-13：目标组织作为整体出现在业务序列图中（续）——错误示例
actor "企业" as 企业
actor "银行" as 银行
actor "担保公司" as 担保公司
企业 -> 担保公司 : 受理担保申请()
担保公司 -> 担保公司 : 审批担保申请()
担保公司 -> 担保公司 : 制作资料()
担保公司 -> 银行 : 提供贷款()
银行 -> 银行 : 审批贷款()
note right of 担保公司
  ❌ 错误：根据图4-13“担保公司”是研究对象，在业务序列图工作流中，应该拆解担保公司的内部流程
end note
@enduml

最后要提到的抽象级别错误是：把不具备任何智能的物体放到了业务 序列图的生命线上， 无智能的申请单被错误当成了业务实体 申请单只是一张纸，不具备智能，最多能作为消息参数传递。

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

4.2.3 只画核心域相关的系统 #

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

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

图4-17 Word要不要画出来
@startuml
' 工作人员自调用：制作文档
actor "工作人员" as 工作人员
工作人员 -> 工作人员 : 制作文档()
@enduml
@startuml
' 工作人员与 Word 交互：制作文档
actor "工作人员" as 工作人员
participant "Word" as Word
工作人员 -> Word : 制作文档()
@enduml

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A：今天是哪一年几月几号？

B：**年月号

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

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

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

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

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

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

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

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

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

还有一种有趣的错误。A开发团队里的建模人员把4中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章的内容，知道“做需求时把产品当项目做”的道理，就 不会困惑了。“现状”指目标组织的现状，是具体而且有最佳答案的。

4.5 【步骤】改进业务序列图 #

得到现状业务序列图后，接下来就要思考信息化可以给现状带来什么 样的改进。信息化给人类的工作和生活带来的改进，常见的模式有以 下几种。

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

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

例如，市民要了解新闻，可以去报摊买报纸看，但这会产生各种物 流，如果把报纸中包含的有价值信息提炼出来，通过软件系统传送， 各种物流就消失了。 过去二三十年的信息化改进主要着力点就是物流变成信息流。这方面 改进对人类社会已经产生了明显的影响。现钞用得越来越少，信件被 电子邮件、短信、QQ和微信取代，照相胶卷已经绝迹，人们口中 的“文件”默认的不再是纸质文件。

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

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

4.5.2 改进模式二：改善信息流转 #

软件系统越来越多，而各个软件系统之间沟通不畅，导致一个人为了 达到某个目的可能需要和多个软件系统打交道，如果把各软件系统之 间的协调工作改为由一个软件系统来完成，人只需要和单个软件系统 打交道，信息的流转就改进了。 调度科为了出一份报表，不得不在多个业务实体之间 疲于奔命（虽然可能只是鼠标在奔），在中间插入新系统之后，工作 量减少了很多。

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

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

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

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

图4-47 封装领域逻辑例子
@startuml
' 原始流程：顾客协助销售员下单
actor "顾客" as 顾客 `BusinessActor`
actor "销售员" as 销售员
顾客 -> 销售员 : 协助下单()
销售员 -> 销售员 : 寻找合适的供应商()
销售员 -> 销售员 : 计算总价()
@enduml
@startuml
' 优化后流程：顾客直接下单（系统封装逻辑）
actor "顾客" as 顾客 `BusinessActor`
participant "订单系统" as 订单系统
顾客 -> 订单系统 : 下单()
订单系统 -> 订单系统 : 寻找合适的供应商()
订单系统 -> 订单系统 : 计算总价()
@enduml

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

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

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

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

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

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

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

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

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

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

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

4.5.4 阿布思考法 #

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

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

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

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

在软件开发团队中，当有人提出新的想法时，经常会被马上否定“这太 难了，这做不了”，最终得到一个平庸的、毫无竞争力的系统。学会像 阿布一样思考，有助于克服普通人因资源受限而不敢展开想象的思维 障碍。阿布思考法分两步：

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

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

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

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

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

财富和权力强烈刺激着周围的“马屁精”削尖脑袋不停地创新，以便让 富豪高官过得舒服一点。富豪自不必说，权力的威力往往超越常人想 象。有个新闻，一个正处级干部被周围的人侍候得舒 舒服服，什么都不用操心照样坐飞机。IT公司的产品经理们何苦在办 公室里头脑风暴闭门造车呢？“马屁精”们已经创新过了。去调研然后 山寨，卖给初次坐飞机的老太太即可。

如何做一家优秀的网上商店？互相盯着其他网店竞争对手都添加了什 么新功能，彼此搞模仿秀就可以了吗？不妨用阿布思考法思考一下， 阿布们最喜欢去哪里购物？纽约，苏黎世，还是米兰？去调研阿布们 爱逛的商店，看看它们的顶级服务有哪些特色，想办法在网店中山 寨。

如何做一个创新的会议管理软件？不要光盯着现有的会议管理软件， 不妨思考一下，服务最周到、组织最得力的会议是什么会议？在中 国，应该是五年一次的中国共产党全国代表大会吧？之所以服务周到 组织得力，未必是靠电脑系统，而是靠经验丰富的人。这些人的经验 如果能在会议管理软件中山寨一二，会不会成为亮点？

不去观察和调研，有时很难想象另一个阶层的人是如何生活的，就像 过去老农民的“头脑风暴”——“毛主席这么大的官，屋里肯定挂满了烧 鸡和油条！”。

调研阿布们的生活未必要亲临现场（去一趟纽约或人民大会堂有一定 代价），看时尚杂志或者网上查资料也是调研。总之，不要闭门造车 就是了。

阿布思考法还可以借助他人的想象力。科幻小说和玄幻小说是很好的 素材。古代神话中的“千里眼”“顺风耳”“嫦娥奔月”“猴毛变猴”等想象 在现代已经实现了，我们还可以想象“一筋斗十万八千里”是什么？虫 洞？“天上一日地上一年”是什么？《时间回旋》里的时间梯度？

阿布思考法中的山寨未必要模仿得多像，99%是山寨，1%也是山寨。 最简单的山寨就是意淫了，过去皇上后宫佳丽三千，今天单身程序员 硬盘里也有东瀛佳丽三千。