是时候认真对待软件方法了：剥丝抽茧，利润等于需求减去设计

来源｜阿里开发者公众号

作者｜聪安

“系统性地输出式学习”，最大的受益者是自己，其次是“只字不差阅读”和“只字不差理解”的你。为什么：“利润 = 需求 - 设计”

• 先说需求：一种是“假需求”，一种是“有需求”。假需求做得多，企业成本增加。有需求并非一定是核心价值，通过软件方法的分析思路和工具从“有需求”中找到“真需求”，提升软件好卖带来营收增长（价值需求带来营收）。
• 再说设计：指的是用一系列软件方法分析业务流程和规则，产出需求分析，做好架构设计，提升软件系统的维护性和扩展性，进而提升软件生命周期各个环节的效率和质量，降低成本（好的设计降低成本）。
  

1.背景是什么？

不知道你有没有发现，当下软件行业的工程师在业务抽象与抽象、领域建模、架构设计等能力上似乎并没有因为业务快速发展，及技术框架、中间件、分布式等技术发展成熟，带来相关的能力的积累和沉淀，反而在退步或消失，甚至很多参加工作几年的同学都未曾使用过软件方法中的一些方法。而软件方法随着企业规模变大，重要性其实应该被逐步提升才对，但实际恰恰相反，越来越不重视，而且需求越来越多，设计越来越丢失，系统扩展性和维护性越来越差，用户产品越来越复杂。记得刚参加工作头几年，项目一旦立项，架构设计会作为重要且紧急的关键里程碑工作，经历几轮评审和修改才进入开发，而且在旁边听前辈讨论和评审也是受益匪浅，浓浓的技术氛围推着自己也去学习。但是随着互联网快速发展及敏捷迭代的流行，人们渐渐忽视了软件方法（敏捷迭代并未要求忽视设计，而是在执行时因为人的原因不再重视，慢慢地不再谈及软件方法）。而且，平时经常听到重构系统，但是每年都在重构，这是进步，还是退步，我认为是退步，这值得我们反思。能力的退步、氛围的缺失和无效的重构，是总结本文的背景，希望在不久的将来越来越多的工程师熟练掌握软件方法中的相关方法和工具。

2.什么是软件方法？

来自百度百科的定义，软件方法是指在软件开发过程中，从软件需求分析、软件设计、软件编码、软件维护等环节中，采用适合的方法解决软件开发中的问题，实现高效的开发，以满足用户的需求。我自己对“软件方法”理解，从业务到软件开发的一系列分析方法和工具，帮助我们将复杂的业务知识、架构知识转变为团队中人人能够理解和上手的统一语言，并借助诸如UML工具产出具体的设计图。从而更加系统化、规范化地进行软件开发，确保软件系统的可维护性、可靠性和可扩展性。但是，软件方法长成啥样？比如你学会了设计原则和设计模式，可以说你掌握了设计方法；比如你学会了为业务构建领域模型，可以说你学会了领域建模方法；比如你学会了通过业务用例和业务时序定义组织提供的价值和组织内如何协同，可以说你掌握了业务建模方法。设计方法、领域建模方法、业务建模方法等方法的融会贯通，组成一个完整的软件方法。大部分人可以较好掌握设计方法，但是掌握业务建模和领域建模方法的人比较少。

3.为什么软件方法被忽视？

因为软件方法中最核心的能力，比如业务建模和领域建模能力，看起来对完成代码开发好像没有帮助，同时掌握它又有一定的挑战，导致没有得到足够多的人重视。当然还有另外2个原因：

• 只重技术不重业务，只是用代码实现业务系统，并未考虑业务扩展性、维护性等。
• 业务和领域建模是种手艺，但凡手艺都需要在实践中不断经历磨炼。
  

4.软件方法的重要性？

一个好的软件产品，离不开对业务的理解和抽象，作为技术人员，先要对业务充分理解，并将业务知识做抽象，才能将业务理解和抽象转换成更好的软件设计，这是技术人员能力发展非常重要的步骤及好的软件系统的前置条件。而且软件方法技能的熟练度提升，会带来团队和个人整体交付质量和效率的提高，个人的价值和影响力也会越来越好，职业发展路径越清晰。本文篇幅有些长，但是相比阅读各类书籍，然后理解和吸收，会大大节省很多时间，况且通过自己的总结输出，对于一些书中难以理解的部分做了改进，帮助更好的理解。可能阅读本文需要一些软件方法的基础知识，才能更好理解和吸收，甚至提出反馈建议。最后，希望文本对大家有帮助，当然，若想真的有帮助，需要运用好“只字不差阅读”和“只字不差理解”。若总结中有错误或不合理的地方，欢迎留评指出，不胜感激。

一、软件方法概要

产品和研发在进入具体开发之前，我认为需要思考清楚如下3个问题：（1）首先，需要了解需求会不会变化；（2）其次，无论需求变与不变，要知道提升“好卖”和“降本”的方法；（3）最后，实践建模方法挖掘被研究组织提供的价值，降低实现成本。

1. 需求会不会变化

人类或组织相关需求从过去到现代大部分不会发生变化，在将来大概率也不会变化，比如存/取钱、吃饭、看病、出行、看戏等。但是随着技术发展和资源逐渐充裕，很多需求会不断出现或发生演进，比如买东西不要出门、看戏到看电影/短视频、吃饭点菜时希望不要等待。无论需求变与不变，实现需求的方式会随着技术发展而逐步变化，这是毋庸置疑的。比如，以“取钱买商品”需求为例，这个需求从古代到现在都没有发生变化，只是需求的实现方式变得更高效了。10几年前，我们要从家里先坐车去银行取完钱，然后坐车去商场买东西，最后从商场拿着商品坐车回家，一天下来将人肉这个大的物流不断挪动，人累效率又低。现在可以直接在淘宝上买商品，然后网上支付，最后由物流公司把货物寄到你家里，人肉这个物流可以做到足不出户。而且，随着技术发展，原先因为资源和技术受限，很多需求没法得以实现，或者需求体现方式单一。采用建模思维，可以更高效和高质量挖掘出需求的价值，进而通过付出心血和努力获得竞争优势和成本降低。比如，以“餐馆点菜”需求为例，从古代到移动互联网之前，你每次去餐馆吃饭，服务员会给你拿一张菜单过来，然后你边点他边写，遇到人多的时候，服务员根本来不及招呼你，你要过好久才能完成点菜，上菜就更慢了。但是随着互联网普及及智能手机的出现，基于二维码扫码点餐大大提升了餐馆效率及降低了人力成本，也提升食客的消费体验。

2. 提升“好卖”和“降本”的建模方法

任何一家企业都不得不重视的公式：“利润 = 收入 - 成本”。作为软件行业的产品和技术人员来说，我们演进下公式：“利润 = 需求 - 设计”。通过挖掘需求价值提升产品好卖，做好软件工程的设计降低成本，进而提升利润。建模技能的有效运用会决定需求的价值、决定软件工程设计的质量。但是，什么是建模？建模的本质：总结经验的过程，将经验总结为方法和工具。以人的大脑为例，通过学习、做项目积累经验、听分享、做交流等动作完成大量的信息输入之后，大脑会完成一轮建模，并总结出一些方法和模型，变成大脑的模型之一，模型越多个人能力越强，然后在下次自己遇到类似问题时，能够基于模型给出更好的方法。放在软件开发上，建模是软件生命周期各个阶段的模型组合，包括业务建模、需求分析、领域建模和软件设计。每一个建模技能细节的提升，能够更好挖掘到产品价值或降低研发成本，提升产品“卖相”，及提升架构的质量属性（如扩展性、可维护性、安全性等），这些都会带来“利润”提升。

3. 实践建模方法挖掘价值和降低成本

以“人”系统为例，人会走路，吃饭，说话，跳跃，还会拉马车、搬砖、讲笑话等，但是我们人这套系统并没有走路子系统、吃饭子系统、说话子系统、跳跃子系统。反而是呼吸子系统、消化子系统、神经子系统、血液循环子系统。人体的每个子系统互相协同完成走路、吃饭、说话、跳跃等外在功能表现，并为其他组织提供价值，比如为房地产提供搬砖价值，为小朋友讲三国演义（凯叔讲故事）。从上面的例子我们可以学习到，实现产品不仅仅是简单的把外在功能表现当中需求，然后变成一个个子系统。合理的方式是：研究组织对外提供的价值、为了实现组织对外提供的价值，组织内需要开发什么系统、不同的系统如何协作及用什么样的技术实现更好的产品体验和性能表现。以下以银行为例，按顺序践行建模的4个方法，因为无银行经验，银行系统的实际情况肯定和下图有出入。



通过表格进一步理解上图中的业务建模、需求分析、领域建模和软件设计的职责。

按照业务建模、需求分析、领域建模和软件设计对组织进行建模分析，可以强迫我们高质量思考，产出高质量的设计降低开发成本和维护成本，进而产出“更好卖”的产品。

二、业务建模

业务建模核心是找到“被研究的组织”向“其他组织”提供的价值，一般称其他组织为用户/客户，但用户/客户过于泛化。当然，在面向社媒/股东等，可以说我们有多少用户，但是产品和技术在讨论具体的需求细节时，需要从泛化到具体。

如何从泛化到具体，核心是用老大和涉众来替代其他组织。老大是为软件付费的人（或是最核心的用户），涉众是除老大之外相关的人，或者老大就是涉众里最重要的人。软件开发时优先满足老大需求，然后是满足涉众需求。

比如银行的涉众是家里有储蓄的人和有贷款需求的企业，银行通过一定的利息吸纳涉众的储蓄，然后以更高的利息贷款给企业，这就是银行的商业模式，各种涉众的需求都得到了满足。

业务建模采用最核心的2个模型，分别是业务用例和业务时序。

业务用例表示被研究组织对外提供的价值，业务时序表示被研究组织内部各个系统如何相互协作实现组织对外价值的提供。

还是以“软件方法-概要”中的银行为研究对象（银行每个人都用过，以它为例更容易理解），来更详细描述银行业务用例和业务时序。

1. 业务用例

业务用例要素：业务执行者和业务用例。

业务用例画法：用照相机对准被研究的组织，谁和这个组织有交互，谁就是业务执行者。如下示例，拿着照相机在组织边界处拍照（比如大门），谁和组织有交互，谁“可能”是业务执行者。为什么说可能呢？原因有些和组织有交互并不一定是业务执行者，比如来问路的人，乘凉的人，在组织内工作的人等。

以银行为例，储户来银行存款，企业来银行贷款，储户和企业都是银行这个组织的业务执行者。但是银行里的职工虽然也来银行，但他们只是银行这个组织里的业务工人，并不是业务执行者。但是，如果研究的组织是银行里的某个子系统，比如点钞机，这个点钞机的业务执行者可能是银行职员。

如下图，围绕钱流通的商业模式，古代和现代的需求没有发生变化，都有存款，取款，转账和贷款需求。变化的地方在于名字不同，古时叫钱庄和商人，现在叫银行和企业。

但是，随着技术发展和资源不断涌现，组织的价值在不断演进，比如现在银行相比古代的钱庄，除了基本存取款之外，还可以为企业和个人提供诸如理财、外汇、信用卡、期权等银行组织对外提供的价值。

2. 业务时序

业务时序画法：业务时序中包括业务工人和业务实体，通过业务工人和业务时序的相互协同合作，完成被研究组织对外价值的提供。业务工人（圆圈中有个小人）和业务实体（圆圈+下划线）表示方式见下图。要特别注意，业务实体的抽象级别要一致，比如系统和表结构都出现在业务实体中，肯定出现了抽象级别不一致的情况。

以“银行取款业务用例”为例，先画出银行早期的业务时序图，然后画“点钞机"出现的改进业务时序图、最后画"ATM取款机"出现的改进业务时序图。通过业务时序的不断修改（但是业务用例一直没有改变，还是银行组织对外提供取款价值），来感受业务时序在改善组织问题、提升用户价值体验研究上的价值。

2.1 柜台取款

小时候家境不富裕，有点钱妈妈会把钱拿到信用社存款赚点利息，信用社的柜员拿到钱之后要反复数几遍，有时候会拿出一张钞票对着灯光反复瞧几遍，辨别是否真假。同时家里需要用钱的时候，妈妈又会去信用社取款，当柜员把钱给到妈妈的时候，妈妈要反复数几遍，而且最担心是怕有假钞。

那个时候消费没现在这么方便，存/取款频率也没现在这么高，效率并非那时候的核心问题，反而钞票的数量和真假是那时的核心问题。





2.2 点钞机出现

于是善于研究组织问题的人发现，钞票数量出错带来的影响：要么是储户损失，要么是银行损失。同时钞票要是辨别真假出错，银行大概率会损失更严重，因为假钞会流行。

那么，不出意外也就出意外了，有人研究出了点钞机，一次性解决当时核心问题的：钞票数量和钞票真假，储户和银行再也不用担心了，银行的价值和信任感被加强。于是业务时序图有了如下变化。



2.3 ATM取款机出现

随着银行卡的普及和软件技术的发展，基于存折存/取款逐渐淡出了历史舞台，上图中的“1：服务台填写取款单”和“2.5打印存折上的取款金额”在今天已经逐渐消失，取而代之的是基于银行卡的存取款操作。

同时，随着互联网的发展，人们的消费频率越来越高，存取款的频率也越来越高，意味着银行排队的人越来越多，于是善于研究组织问题的人发现，能不能通过终端解决银行柜台不够的问题，进而为储户带来更好的体验。甚至还可以将终端安装在离储户近的地方，不用来银行就可以完成取款或存款。于是业务序列图又有了变化。



银行组织的“取款用例”虽然经历了3个阶段的业务时序变化，但是对储户提供的价值没有发生变化，而且储户的体验越来越好，社会效率也越来越高。如果某家银行没有跟上业务时序中描述的变化，业务萎缩不会意外。

截止这里，可以看出业务建模中的业务用例和业务时序是一种工具，帮助我们找准组织对外提供的价值，而且价值非常稳定不会轻易发生变化，同时帮助我们找准组织内部需要改善的问题和流程，通过数字化、人工智能、终端等方法进行改善，为用户（老大和涉众）创造更好的价值，持续不断带来用户体验的变化。

三、需求分析

在“2.3 ATM取款机出现”章节中提到，因为消费频次变高，来银行排队存/取款的人越来越多，用户存/取款体验越来越差，所以研究组织在存/取款的体验时，提出了存/取款终端设备：“ATM取款机”，进而改进了业务时序图。所以我们需求的研究范围来自“2.3 ATM全款机出现”章节改进后的业务时序图。

需求分析分为系统用例和系统用例规约。以下以ATM取款机为研究对象，分析系统用例和系统用例规约。

1. 系统用例

系统用例包括系统执行者和系统，系统执行者是系统的使用者，比如ATM取款机是系统，储户是系统执行者。

先理解系统执行者和系统：

• 系统必须能够独立对外提供服务，可以是数据服务，也可以是行为服务，比如“2.3 ATM取款机出现”中的风控系统独立对外提供取款风控安全监测，短信系统独立对外提供短信通知服务。
• 系统边界是责任边界，比如“2.3 ATM取款机出现”中的风控系统、短信系统的责任完全不一样，分别提供自己职责范围内的服务。
• 系统执行者和系统要有交互，比如研究的系统是售票系统，系统执行者是售票员。如果研究的系统是12316 APP，系统执行者就不是售票员了，而是旅客。
• 系统执行者有主执行者和辅执行者，辅执行者是被动参与，比如“2.3 ATM取款机出现”章节中的储蓄系统是ATM取款机的辅执行者。
• 系统执行者不一定是人，也可以是系统或时间，比如定时器可以是系统执行者，本质上是驱动系统运行。

识别系统执行者和系统用例方法比较简单，如果业务时序图画的非常标准和详细，系统执行者和系统用例都可以来自业务时序图中。以“2.3 ATM取款机出现”的业务时序图为例，给出ATM取款机的系统用例。

因为“2.3 ATM取款机出现”只是画了取款业务时序，实际还可能包括查询余额、转账、存款等业务时序流程。所以完整的ATM取款机系统用例如下：

上一篇： 一团乱麻的Excel利润图表，让老板快要抓狂啦！

下一篇： 不懂财务做利润分析？轻松掌握，三步教你玩转利润表分析