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

　　先说需求：一种是“假需求”，一种是“有需求”。假需求做得多，企业成本增加。有需求并非一定是核心价值，通过软件方法的分析思路和工具从“有需求”中找到“真需求”，提升软件好卖带来营收增长（价值需求带来营收）。

　　再说设计：指的是用一系列软件方法分析业务流程和规则，产出需求分析，做好架构设计，提升软件系统的维护性和扩展性，进而提升软件生命周期各个环节的效率和质量，降低成本（好的设计降低成本）。

　　不知道你有没有发现，当下软件行业的工程师在业务抽象与抽象、领域建模、架构设计等能力上似乎并没有因为业务快速发展，及技术框架、中间件、分布式等技术发展成熟，带来相关的能力的积累和沉淀，反而在退步或消失，甚至很多参加工作几年的同学都未曾使用过软件方法中的一些方法。

　　而软件方法随着企业规模变大，重要性其实应该被逐步提升才对，但实际恰恰相反，越来越不重视，而且需求越来越多，设计越来越丢失，系统扩展性和维护性越来越差，用户产品越来越复杂。

　　记得刚参加工作头几年，项目一旦立项，架构设计会作为重要且紧急的关键里程碑工作，经历几轮评审和修改才进入开发，而且在旁边听前辈讨论和评审也是受益匪浅，浓浓的技术氛围推着自己也去学习。但是随着互联网快速发展及敏捷迭代的流行，人们渐渐忽视了软件方法（敏捷迭代并未要求忽视设计，而是在执行时因为人的原因不再重视，慢慢地不再谈及软件方法）。而且，平时经常听到重构系统，但是每年都在重构，这是进步，还是退步，我认为是退步，这值得我们反思。

　　能力的退步、氛围的缺失和无效的重构，是总结本文的背景，希望在不久的将来越来越多的工程师熟练掌握软件方法中的相关方法和工具。

　　来自百度百科的定义，软件方法是指在软件开发过程中，从软件需求分析、软件设计、软件编码、软件维护等环节中，采用适合的方法解决软件开发中的问题，实现高效的开发，以满足用户的需求。

　　我自己对“软件方法”理解，从业务到软件开发的一系列分析方法和工具，帮助我们将复杂的业务知识、架构知识转变为团队中人人能够理解和上手的统一语言，并借助诸如UML工具产出具体的设计图。从而更加系统化、规范化地进行软件开发，确保软件系统的可维护性、可靠性和可扩展性。

　　比如你学会了设计原则和设计模式，可以说你掌握了设计方法；比如你学会了为业务构建领域模型，可以说你学会了领域建模方法；比如你学会了通过业务用例和业务时序定义组织提供的价值和组织内如何协同，可以说你掌握了业务建模方法。

　　设计方法、领域建模方法、业务建模方法等方法的融会贯通，组成一个完整的软件方法。大部分人可以较好掌握设计方法，但是掌握业务建模和领域建模方法的人比较少。

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

　　一个好的软件产品，离不开对业务的理解和抽象，作为技术人员，先要对业务充分理解，并将业务知识做抽象，才能将业务理解和抽象转换成更好的软件设计，这是技术人员能力发展非常重要的步骤及好的软件系统的前置条件。

　　而且软件方法技能的熟练度提升，会带来团队和个人整体交付质量和效率的提高，个人的价值和影响力也会越来越好，职业发展路径越清晰。

　　本文篇幅有些长，但是相比阅读各类书籍，然后理解和吸收，会大大节省很多时间，况且通过自己的总结输出，对于一些书中难以理解的部分做了改进，帮助更好的理解。可能阅读本文需要一些软件方法的基础知识，才能更好理解和吸收，甚至提出反馈建议。

　　最后，希望文本对大家有帮助，当然，若想真的有帮助，需要运用好“只字不差阅读”和“只字不差理解”。若总结中有错误或不合理的地方，欢迎留评指出，不胜感激。

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

　　人类或组织相关需求从过去到现代大部分不会发生变化，在将来大概率也不会变化，比如存/取钱、吃饭、看病、出行、看戏等。但是随着技术发展和资源逐渐充裕，很多需求会不断出现或发生演进，比如买东西不要出门、看戏到看电影/短视频、吃饭点菜时希望不要等待。无论需求变与不变，实现需求的方式会随着技术发展而逐步变化，这是毋庸置疑的。

　　比如，以“取钱买商品”需求为例，这个需求从古代到现在都没有发生变化，只是需求的实现方式变得更高效了。10几年前，我们要从家里先坐车去银行取完钱，然后坐车去商场买东西，最后从商场拿着商品坐车回家，一天下来将人肉这个大的物流不断挪动，人累效率又低。现在可以直接在淘宝上买商品，然后网上支付，最后由物流公司把货物寄到你家里，人肉这个物流可以做到足不出户。

　　而且，随着技术发展，原先因为资源和技术受限，很多需求没法得以实现，或者需求体现方式单一。采用建模思维，可以更高效和高质量挖掘出需求的价值，进而通过付出心血和努力获得竞争优势和成本降低。

　　比如，以“餐馆点菜”需求为例，从古代到移动互联网之前，你每次去餐馆吃饭，服务员会给你拿一张菜单过来，然后你边点他边写，遇到人多的时候，服务员根本来不及招呼你，你要过好久才能完成点菜，上菜就更慢了。但是随着互联网普及及智能手机的出现，基于二维码扫码点餐大大提升了餐馆效率及降低了人力成本，也提升食客的消费体验。

　　任何一家企业都不得不重视的公式：“利润 = 收入 - 成本”。作为软件行业的产品和技术人员来说，我们演进下公式：“利润 = 需求 - 设计”。通过挖掘需求价值提升产品好卖，做好软件工程的设计降低成本，进而提升利润。

　　以人的大脑为例，通过学习、做项目积累经验、听分享、做交流等动作完成大量的信息输入之后，大脑会完成一轮建模，并总结出一些方法和模型，变成大脑的模型之一，模型越多个人能力越强，然后在下次自己遇到类似问题时，能够基于模型给出更好的方法。

　　放在软件开发上，建模是软件生命周期各个阶段的模型组合，包括业务建模、需求分析、领域建模和软件设计。每一个建模技能细节的提升，能够更好挖掘到产品价值或降低研发成本，提升产品“卖相”，及提升架构的质量属性（如扩展性、可维护性、安全性等），这些都会带来“利润”提升。

　　以“人”系统为例，人会走路，吃饭，说话，跳跃，还会拉马车、搬砖、讲笑话等，但是我们人这套系统并没有走路子系统、吃饭子系统、说话子系统、跳跃子系统。反而是呼吸子系统、消化子系统、神经子系统、血液循环子系统。的每个子系统互相协同完成走路、吃饭、说话、跳跃等外在功能表现，并为其他组织提供价值，比如为房地产提供搬砖价值，为小朋友讲三国演义（凯叔讲故事）。

　　从上面的例子我们可以学习到，实现产品不仅仅是简单的把外在功能表现当中需求，然后变成一个个子系统。合理的方式是：研究组织对外提供的价值、为了实现组织对外提供的价值，组织内需要开发什么系统、不同的系统如何协作及用什么样的技术实现更好的产品体验和性能表现。

　　以下以银行为例，按顺序践行建模的4个方法，因为无银行经验，银行系统的实际情况肯定和下图有出入。

　　组织要解决什么问题，为其他组织提供什么价值，提升好卖。比如上图，通过“银行”组织，为“人”这个组织提供资金存款，取款，转账价值，带来资金安全、利息收入、便捷价值。但是每次取款都需要坐车去银行、取号、等待柜员叫号，不是特别方便和灵活（要解决的问题）。

　　为了解决组织问题，待开发系统需要提供什么功能和性能。比如上图，客户去银行柜台通过“柜员”取款效率较低，为了提升组织对外的便捷价值，需要研究组织中的人肉系统“柜员”，创造“ATM取款机”自动化系统来替换柜员这个人肉系统，提升取款效率。同时因为在ATM取款机上取款，安全要求更高，相应的风控系统也是研究的系统。

　　为了提供功能，系统内部应该有什么样的核心机制。比如上图，ATM取款机要提供取款功能，通过分析领域模型（领域关系和职责）、状态机（对象生命周期建模）和系统时序图（描述协作）研究清楚待改进的系统。

　　为了实现好卖的产品，如何用选定的技术实现。比如上图，大的维度包括概要设计和详细设计，概要设计和详细设计内又分别包含具体的设计细节，比如概要设计中有物理架构，逻辑架构等；详细设计中有数据库设计，接口设计等。

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

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

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

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

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

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

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

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

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

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

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

　　以“银行取款业务用例”为例，先画出银行早期的业务时序图，然后画“点钞机出现的改进业务时序图、最后画ATM取款机出现的改进业务时序图。通过业务时序的不断修改（但是业务用例一直没有改变，还是银行组织对外提供取款价值。