剛開始讀這本書時，我很驚訝，程序員都已經在學習業務建模了，而我作為業務分析人員如果都不懂業務建模，真是自行慚穢。
這本書我理解為是從軟件開發人員的角度出發，主要聚焦在兩方面的技能：需求和設計。鼓勵開發人員不要僅僅停留在編碼工作，可以試著從純粹的技術思維轉變到業務思維，在做設計之前進行業務建模，才能在激烈的競爭中獲得優勢。
雖然本書可能是寫給開發人員看的，但從我的角度，這本書實在是有很多“干貨”，幫助我理清了很多之前覺得模糊的概念。
接下來慢慢梳理一下這些概念，進入業務建模的思維模式。
利潤=需求-設計
作者在第一章先拋出了一個新穎的公式“利潤=需求-設計”。可以怎么理解呢？傳統的銷售利潤的公式是“利潤=收入-成本”。而在軟件開發中，需求工作解決的就是“產品好賣”的問題，要賣出好價錢；而設計工作則致力于解決“降低成本”的問題，軟件的制造成本要低。這樣最終軟件產品才能有高的利潤。
這個公式是為了讓開發人員明白，需求和設計在開發中其實扮演者不同的角色，所以一定要分開。同時也是明確了業務建模和需求的重要性。
如果需求和設計不分，利潤就會縮水。
把需求直接映射為設計，只會產生重復代碼。
人體需要許多功能，但功能并不能對應內部子系統的設計。比如人體需要跑步、跳舞、搬運等功能，而做設計時，最終的產物是將人體設計成呼吸子系統、消化子系統等等來支持這些功能。如果把需求直接變成設計，那跑步的呼吸系統和跳舞的呼吸系統就是重復代碼了。
相反，也不能直接從設計推導需求。
比如，一個搬運工有心肝脾肺，他找工作的時候也不可能說“老板，我有心管理功能，請我吧”。
總之，拿到需求之后，要先經過分析再做設計。開發人員之間經常提到的“編碼的藝術”，不是在講編碼的技能，其實就是分析的技能。
愿景
讓開發人員介紹現在手頭上正在開發的項目時，他們通常會說，這個系統有哪些功能巴拉巴拉。當被問到為什么要做這個系統時，卻不知道怎么回答了。也就是說，在他們的意識里，這只是一個可以工作的軟件，可是我們真正要回答的是，這是一個可以賣的軟件嗎？賣給誰？賣點在哪里？這，就是兩種不同的思維。
這一點其實我現在作為業務分析人員也有一樣的弊病，所以，一定要盡快將思維轉變過來。
轉變的第一步，就是要不斷的問自己這個項目或產品的愿景是什么？也就是，為什么要開發這個項目？第二步，產品的涉眾是誰？影響到誰的利益？
一個軟件產品的需求是永遠做不完的，上萬條的需求要先做哪些是需要排序的，而排序就是由以上兩點因素決定。
業務建模
第一步，選定要改進的組織，明確目標人群，這里的組織就是我們要研究的對象。我們要做一個銀行業務受理系統，這個時候我們要進行業務建模了，需要研究的組織是誰？——銀行。
第二步，尋找業務執行者。業務執行者就是在組織之外和組織進行交互的人群或者其他組織。銀行的業務執行者是誰？——儲戶，企業、人民銀行等等。
什么是用例呢？
用例就是業務執行者和組織交互達到的，組織能夠提供的價值。要注意這里的價值，很重要。怎樣才算是有價值的？就是要達到執行者的期望和組織的承諾的平衡點。比如，患者是執行者，組織是醫院，而掛號并不能算為一個用例。因為患者到醫院掛號后，他所期望的服務不能就此結束了，這并不是他對醫院的期望，而且，也不是醫院對患者的承諾。
什么是業務流程？
業務流程就是業務用例的實現。先去明確業務用例對改進業務流程有非常大的幫助——先歸納組織對外提供什么價值，再思考如何更好地優化組織內部流程來實現這些價值。這就是一種很好的思路。
怎么去識別業務用例？
主要還是從業務執行者的角度出發，思考業務執行者和組織打交道的目的，基本上能將所有的用例找出。另外一種方式也可以補漏，觀察組織內部的活動，一直問為什么，再向外推到組織外部的某個業務執行者。
為什么要思考業務用例？
業務用例不是思考系統提供什么“功能”，而是購買了這個軟件或系統后，對于組織本來就有的“功能”會帶來一點點幫助。比如，銀行的“存款”業務，是銀行本來就有的功能。有了存款辦理系統后，能夠提升存款的辦理速度、準確度，客戶滿意度，所以，還有什么理由不買這個系統呢。
總之，思考用例的過程，就是發現價值的過程。如果我們能不斷通過用例思維來思考一個組織或者系統的需求，就能訓練出越來越強大的發現價值的能力。所以，其實不論是什么職業什么行業，都很需要這種思維能力，因為，發現價值的能力是終身受益的。
