刚开始读这本书时，我很惊讶，程序员都已经在学习业务建模了，而我作为业务分析人员如果都不懂业务建模，真是自行惭秽。
这本书我理解为是从软件开发人员的角度出发，主要聚焦在两方面的技能：需求和设计。鼓励开发人员不要仅仅停留在编码工作，可以试着从纯粹的技术思维转变到业务思维，在做设计之前进行业务建模，才能在激烈的竞争中获得优势。
虽然本书可能是写给开发人员看的，但从我的角度，这本书实在是有很多“干货”，帮助我理清了很多之前觉得模糊的概念。
接下来慢慢梳理一下这些概念，进入业务建模的思维模式。
利润=需求-设计
作者在第一章先抛出了一个新颖的公式“利润=需求-设计”。可以怎么理解呢？传统的销售利润的公式是“利润=收入-成本”。而在软件开发中，需求工作解决的就是“产品好卖”的问题，要卖出好价钱；而设计工作则致力于解决“降低成本”的问题，软件的制造成本要低。这样最终软件产品才能有高的利润。
这个公式是为了让开发人员明白，需求和设计在开发中其实扮演者不同的角色，所以一定要分开。同时也是明确了业务建模和需求的重要性。
如果需求和设计不分，利润就会缩水。
把需求直接映射为设计，只会产生重复代码。
人体需要许多功能，但功能并不能对应内部子系统的设计。比如人体需要跑步、跳舞、搬运等功能，而做设计时，最终的产物是将人体设计成呼吸子系统、消化子系统等等来支持这些功能。如果把需求直接变成设计，那跑步的呼吸系统和跳舞的呼吸系统就是重复代码了。
相反，也不能直接从设计推导需求。
比如，一个搬运工有心肝脾肺，他找工作的时候也不可能说“老板，我有心管理功能，请我吧”。
总之，拿到需求之后，要先经过分析再做设计。开发人员之间经常提到的“编码的艺术”，不是在讲编码的技能，其实就是分析的技能。
愿景
让开发人员介绍现在手头上正在开发的项目时，他们通常会说，这个系统有哪些功能巴拉巴拉。当被问到为什么要做这个系统时，却不知道怎么回答了。也就是说，在他们的意识里，这只是一个可以工作的软件，可是我们真正要回答的是，这是一个可以卖的软件吗？卖给谁？卖点在哪里？这，就是两种不同的思维。
这一点其实我现在作为业务分析人员也有一样的弊病，所以，一定要尽快将思维转变过来。
转变的第一步，就是要不断的问自己这个项目或产品的愿景是什么？也就是，为什么要开发这个项目？第二步，产品的涉众是谁？影响到谁的利益？
一个软件产品的需求是永远做不完的，上万条的需求要先做哪些是需要排序的，而排序就是由以上两点因素决定。
业务建模
第一步，选定要改进的组织，明确目标人群，这里的组织就是我们要研究的对象。我们要做一个银行业务受理系统，这个时候我们要进行业务建模了，需要研究的组织是谁？——银行。
第二步，寻找业务执行者。业务执行者就是在组织之外和组织进行交互的人群或者其他组织。银行的业务执行者是谁？——储户，企业、人民银行等等。
什么是用例呢？
用例就是业务执行者和组织交互达到的，组织能够提供的价值。要注意这里的价值，很重要。怎样才算是有价值的？就是要达到执行者的期望和组织的承诺的平衡点。比如，患者是执行者，组织是医院，而挂号并不能算为一个用例。因为患者到医院挂号后，他所期望的服务不能就此结束了，这并不是他对医院的期望，而且，也不是医院对患者的承诺。
什么是业务流程？
业务流程就是业务用例的实现。先去明确业务用例对改进业务流程有非常大的帮助——先归纳组织对外提供什么价值，再思考如何更好地优化组织内部流程来实现这些价值。这就是一种很好的思路。
怎么去识别业务用例？
主要还是从业务执行者的角度出发，思考业务执行者和组织打交道的目的，基本上能将所有的用例找出。另外一种方式也可以补漏，观察组织内部的活动，一直问为什么，再向外推到组织外部的某个业务执行者。
为什么要思考业务用例？
业务用例不是思考系统提供什么“功能”，而是购买了这个软件或系统后，对于组织本来就有的“功能”会带来一点点帮助。比如，银行的“存款”业务，是银行本来就有的功能。有了存款办理系统后，能够提升存款的办理速度、准确度，客户满意度，所以，还有什么理由不买这个系统呢。
总之，思考用例的过程，就是发现价值的过程。如果我们能不断通过用例思维来思考一个组织或者系统的需求，就能训练出越来越强大的发现价值的能力。所以，其实不论是什么职业什么行业，都很需要这种思维能力，因为，发现价值的能力是终身受益的。
