玩B技术 技术怎么玩？

大家好,今天小编来为大家解答以下的问题，关于玩B技术，技术怎么玩?这个很多人还不知道，现在让我们一起来看看吧！

2023年9月9—10日，人人都是产品经理联合腾讯大讲堂举办的【2023产品经理大会·北京站】完美落幕。和度软件CEO、软件地图创始人程杰老师，为我们带来《B端数字化产品的敏捷设计建模技术与实战方法》为题的分享，本文为演讲内容实录。目前大会回放已上架，戳此购买，即可收看回放：https://996.pm/7gX2B

今天我分享的主题是“B端数字化产品的敏捷设计建模技术与实战方法”，主要分四个维度进行：

一、问题与分析

这幅图是软件工程当中的一张经典图片，它反映了软件工程里各个环节的沟通失真问题。而沟通失真会给软件工程带来很多问题，比如返工多、加班多；变更多、应对慢；用户认可难，实施难、上线难、验收难；包括预算超支严重，甲乙双方都觉得有所亏损，合作濒于崩溃。

实际上，当我们跳出软件工程行业，会发现，其他的工程行业在设计环节都会输出规范化、结构化的设计图纸，但是软件工程到现在为止还是使用非结构化的设计文档。很讽刺的一点，即创造AI的软件工程实际上是很“落后”的。

所以，软件工程沟通失真的根本原因在于：设计环节没有输出可以“降低沟通成本、驱动工程全流程、降低系统性风险”的结构化、可视化的设计模型。各个环节当中的沟通失真问题，实际上是设计环节出了问题。

但其实软件工程行业是有设计建模技术的。2002年OMG提出了MDA（模型驱动的软件开发架构），但大家并没有将其投入使用，原因在于：

UML建模慢，跟不上开发节奏；UML图例繁杂，阅读效率低，沟通成本高；需求发生变更后，CIM/PIM/PSM三个模型都改吗？还是只改部分？前者面临效率问题，后者则面临着一致性问题。

所以可以得出一个结论——软件工程行业亟需一套实用的软件设计建模技术与系统，解决以“大量实际软件工程仍在使用非结构化设计文档”为表征的行业性设计不规范、设计不可视、设计质量低的问题，及其引起的软件开发与运维过程中的“沟通失真”与大量浪费。

二、研发与应用

基于以上分析，我们做了一个自研项目，叫软件地图，我们希望研发出一套实用的软件设计建模技术和系统，应满足以下要求：

项目各方对于设计模型都能够读懂、理解，而且阅读效率高；设计建模快、变更快，设计模型可详可略、灵活可控，能适应开发节奏；设计规范性和质量大幅提升，可以快速、充分地评审设计，大幅降低项目风险；由设计模型可以自动生成程序源码、测试用例，大幅降低开发成本；可支撑大型项目协同化设计建模；学习快、上手快。

总结一点，即：快，才实用。

整体项目于2020年10月份启动，21年9月份，我们上线了第一版，10月份的时候，软件地图就已经应用到一个千万级的软件定制化开发项目当中。23年2月份，我们发布了第二版应用，并在3月份应用到在线系统运维当中；6月份则发布了第三版。

主要功能如图所示，包括了新型制图功能、模板库、全流程设计建模功能，等等。目的即降低沟通成本，提升可视化功能与自动化功能。

这里分享一个案例。

2021年，我们需要为一家服装外贸龙头企业搭建全流程的数字化运营平台，即服装ERP。这个项目属于从0到1式的全定制开发，业务逻辑非常复杂，包括2800+系统功能、1000+用户界面、600+数据表、对接66个外部系统接口，对软件设计能力有很大挑战，一不小心即会陷入设计黑洞。在当时，我带领20多个人，分为7个开发小组，使用软件地图在线协同设计建模，并取得了显著成果：

提升了设计规范性、质量和效率，降低了沟通成本；自动生成了服务端程序50%的源码；程序员每人每天平均产出300行有效源码（不含自动生成的代码），高效保障项目成功交付。

而从案例可以看出，当设计质量提高、沟通成本下降，效益也就有所提升。

再分享一个案例，当时，全球最大的针织服装制造集团需要应用软件地图，对十多个在线核心业务系统进行逆向建模，理清各系统复杂逻辑，构建在线软件设计图纸，大幅提高运维效率，降低迭代升级风险，最终获得了收益：

为什么运用了软件地图之后，设计效率、运维效率可以得到大幅提升，开发成本和BUG率可以被大幅降低？这里涉及了一个核心技术——敏捷设计建模技术。接下来讲讲原因所在。

三、技术与愿景

我们的模型结构涵盖了几个方面，包括业务模型、产品模型、程序模型：

业务模型：包括业务架构、业务流程、业务对象；产品模型：包括数据表、系统功能、用户界面、接口等；程序模型：包括子系统、API、DTO。

第一个核心技术，即业务模型中心驱动（BCD），它解决了MDA三个阶段性模型的问题。而在分析与设计的过程当中，始终只有一个模型，这个模型集成了业务模型、产品模型跟程序模型；并且始终以业务模型为中心，迭代式驱动构建产品模型和程序模型。业务模型不会被抛弃，而是会迭代出结构化的业务逻辑，即数据能力——算法，并被其他模型所调用。如此，相较于MDA，BCD可以大幅提升建模效率、一致性、集成性和变更敏捷性。

如何理解？即在分析、设计与开发过程中，使用了一个大的相同结构，避免异构现象的发生，也降低或避免结构转换之间的沟通失真与损耗。我们要求产品经理一开始就使用MVC设计框架，也方便了后续和研发团队之间的沟通。

那么我们是如何开展的呢？从需求开始（需求包括现状流程以及基于现状流程的系统需求），我们分析得出过程中的业务对象（B端需求分析一定要分析出业务对象），随后分析得出处理业务对象的能力，即数据结构+数据能力。由数据能力，则可以推出系统功能。而在考虑系统功能的用例设计时，必然会涉及到输入输出界面，由此驱动开发界面。在界面的详细数据项得到用户确认后，再结合业务对象的数据结构，即可合起来，共同构成数据表以及表字段。最后，数据能力会演化为服务端的API，界面中的算法则演化为用户端的API。

第二个核心技术，即可视化动态树。传统的图元组装式建模技术是有较大弊端的：

阅读效率低；没有显性的阅读路径，图源多了以后，图很凌乱，有效承载的信息量大大受限；再者，表达颗粒度固化，无法在一张图当中按需切换，查看全局和细节；建模效率低：调整图元位置、大小，都相对费时。

所以，我们所有的模型构建统一使用树状图建模，即所有的模型都是思维导图式的，预定义了100多种具有特定语义和样式的模型节点，实现了模型的结构化、可视化。此外，树状图本身是可聚合、可发散的，符合人类的阅读和理解习惯。而建模时无需要布局对齐、调整大小、可快速键盘操作等优势，则大幅提升了建模效率。某种程度上，我们其实是做了一个为软件工程而定制的思维导图。

第三个核心技术，即业务组件模板，即我们可以一键生成围绕业务对象的设计制品，包括数据表、系统功能、界面原型等等。而设计同学此时只需要明确分析得出的业务单据需匹配什么模板，之后一键生成好即可。这大大提升了设计效率与设计规范度，实现了模板化。

第四个核心技术，绿色的模型转换技术。模型最终要转换成程序源码，同时底层软件包由用户单位自行设定，即用户对生成的程序源码完全自主可控。

总结可得，软件地图在多维度上取得了“敏捷化、实用化”的突破，和UML相比，软件地图在阅读效率、设计信息集成度、设计效率、建模效率、变更效率等各方面都取得了很大突破。

我们希望通过敏捷化、实用化的软件设计建模技术和工具促进软件工程在分析和设计这两个上游阶段的数字化转型，在源头上解决沟通难、返工多、预算高、风险高、运维压力大和应变慢等普遍存在的软件工程问题。

另外，我们希望可以链接大模型平台，通过“软件设计模型+编程大模型”，构建“数字化设计+AI编程”新型软件工程模式，优化软件工程成本结构，大幅降低软件工程成本，大幅缩短软件工程交期，大幅提升软件工程质量。

同时，我们还希望助力千行百业数字化转型，构建开源设计社区。

其一，通过软件逻辑的结构化、可视化和模板化，合作构建各行业应用软件设计模板库，大幅提升各行业数字化转型落地速度和质量，大幅降低成本和风险，大幅减少数字化烂尾工程和豆腐渣工程，促进更多企业数字化转型“敢转、愿转、转好”。

其二，通过大幅降低软件设计的能力门槛，在千行百业中普及推广软件设计能力，为各企业及机构培养数字化人才，加速业务与IT融合。

其三，推动ERP等重点开源设计项目，对标GITHUB，构建开源设计社区。

四、实战方法

我们将软件全栈设计过程进行了定义，包括八大过程——需求分析、业务蓝图设计、人机交互设计、系统接口设计、数据库设计、算法设计、程序设计和测试设计；和产品经理更密切相关的可能是前三个部分，后面将详细讲述。

同时我们也定义了各个过程的产出物，以及在线系统逆向建模过程。

1.需求分析

关于需求分析，我们定义了5个活动，包括：构建业务地图、分析现状业务流程、梳理系统需求、分析业务对象和确认业务需求。

首先，建立需求分析的框架，防止用户单位“飘”出去。这个框架可以称之为业务地图。什么是业务地图？即多层级的业务模块以及下面挂载的业务流程。

接着，绘制流程图。我们需要进一步划分，构建流程内的结构。可以按照工作岗位和业务事件划分业务作业，然后按先后顺序、因果关系，串接业务作业，这就构成了业务流程图。

注意，这是现状业务流程图，现状业务流程需要快速构建，而后描述每一个业务作业的场景和数据处理。这里有一个观点，即理解了业务数据，才算是真正理解了业务场景。一定要花时间研究业务数据。我们可以将所有业务数据列出来，其后将样本数据全部放置其上，后续于此基础上梳理系统需求，这个时候，梳理的每个系统需求都要落到一个业务作业当中去。

同时注意，千万不要照搬业务人员所讲的话，一定要做分类与归纳。

最终，需求分析一定要分析出业务作业处理的业务对象。在B端场景下，业务对象可能是业务单据，而业务单据承载着系统需求，我们需要将系统需求落地到业务对象的管理场景与应用场景，根据样本数据与系统需求，分析业务对象的数据结构。

2.业务蓝图设计

业务蓝图设计包括5个动作：设计核心数据逻辑、定义数据能力、设计功能地图、设计目标业务流程、确认业务蓝图。这里重点要理解核心数据逻辑：

核心数据逻辑=数据结构+数据状态+数据演变

核心数据逻辑是业务模型的核心，是整个系统的地基，即便不是开发同学，也需要在抽象层次上理解数据逻辑，否则就只能被开发同学反复“折磨”。所以，核心数据逻辑为整个设计过程提供了可行性逻辑内核，驱动后续设计，并持续迭代。另外需注意，B端数字化产品设计，切忌“界面原型驱动”。

首先，设计核心数据逻辑的第一步是构建业务对象的数据结构与数据关系，我们需要定义构成业务对象的数据元素。数据元素的颗粒度非常重要，但不需要到非常明细的数据字段。而某个数据元素与业务对象或上级元素的关系只有两种类型：最多1份或最多N份。

这个数据结构不需要像“类”那样复杂，只需要弄清楚其包含关系即可，比如这个款式档案应该由哪几份数据构成，可能有一份正式版数据、一份变更版数据，最多再有一份快照版数据。至于这些数据将会被存储在哪些表格中，则是自然而然的事情。

接着，我们需要按需定义业务对象每个数据元素的状态参数。

最终，我们便得到了数据演变图，在这里，数据演变图设计了业务对象及其数据元素的生命周期，由若干{数据能力+其产生的数据变化}二元节点组构成，表达了业务对象的核心逻辑。

综合以上，我便可以在抽象层次上将数据演变展示出来，既不需要编程，也没有数据表的设计，仅仅是数据结构+概要算法。

基于上述设计得出的数据演变，随后，我们逐个定义数据演变图中的数据能力，规范化定义数据能力的名称和代码（随后我们会在这一基础上生成API）。

接着便是定义系统功能，结合多层级的功能模块，以业务架构为基础，横向扩展通用功能模块和基础功能模块，纵向扩展到业务对象级模块。

随后，基于新的系统功能设计目标业务流程。目标业务流程可以理解为强制性的作业规范，它的要求会更为严谨。

在业务流程设计好了之后，我们需要更加细致地设计业务作业，说明在什么场景中执行该业务作业以及主要执行步骤、执行过程需要使用哪些系统功能、注意事项，等等。

在目标业务流程得到用户单位认可，且业务流程是构建在可行性的数据逻辑的基础之上时，我们便可进入到人机交互设计了。

3.人机交互设计

总共包括5个动作——设计功能用例、设计界面地图、制作界面原型、设计集成用例、确认系统原型。

首先，功能用例可能如图所示，包含了用户操作和系统相应的序列。

接着，设计界面地图，大致步骤如下：

1）设计界面架构（多层级界面入口）

2）定义用户界面&设计界面要素

界面要素是下阶段制作界面原型的界面关键元素，包括：

数据控件及其事件、事件中的界面流转与模式转化；界面事件、事件中的界面流转与模式转化。

3）生成界面地图

下一个动作便是制作界面原型。注意，每个界面可能有多个模式，如果原型缺失界面模式，将导致原型确认失效，这也是后续发生设计变更的重要原因之一。

接着，设计集成用例，即集成多个相关功能用例，在系统响应后面设置集成界面事件、界面模式等。集成用例是重要的设计产出物，因为它可以进行仿真演示，与客户确认系统原型，并在系统上线后培训用户。此外，它还可以导出PRD、测试用例、产品操作手册。

最终，便是确认系统原型，按集成用例预设路径确定性地与客户确认。

除了上面所说的三个过程，此外还有：

系统接口设计，包括：定义外联系统、设计接口地图、设计外联接口参数、设计接口功能参数、确认系统接口。

数据库设计，包括：定义数据库、设计数据地图、设计数据标准、设计数据表、生成数据库。

如图所示，这个数据地图清晰地标识出了数据模块、模块当中的业务对象和相应的数据表，点击之后，即可查看数据表详情。

算法设计，包括设计数据能力算法、设计用户界面算法、设计接口功能算法、设计定时功能算法。

程序设计，包括设计子系统、设计程序地图、设计DTO、设计API、生成程序源码。

如图所示，在子系统中，我们会设计程序模块以及相应的类。在形成程序地图、设计API后，最终，则可以生成程序源码，而这些程序源码，都为低价值编程代码。

测试设计，包括配置API测试环境、生成API测试脚本、设计集成用例、生成集成测试用例。

从前面所讲的内容来看，是不是觉得有些复杂？因为设计已经走向细颗粒度的结构化，而这必然带来较大的工作量。这个时候，我们需要提供业务组件模板库，以提高设计效率，降低设计门槛。模板里面包含：

基础组件：数据字典、组织管理、用户管理、权限管理、文件管理等；通用组件：按有无状态、单/多岗管理、单/多版、单/多层、界面模式等划分；专用组件：按行业、应用划分，例如：银行、电力、制造业ERP、制造业MES等。

我们一直在说“不要重复造轮子”，但实际上“重复造轮子”的事情一直在发生，是因为我们将业务组件固化在了代码级别。基于这点，我们的处理策略便是将其抽象至设计图纸层级，这样子改起来快，看起来也更清楚、明白。

我们也希望可以建立一个开源设计社区，里面有大量的模板、参考资料和资源，方便大家查找。

大会直播回放

目前大会回放已上架，戳此购买，即可收看回放：https://996.pm/7gX2B

本文为【2023年产品经理大会·北京站】现场分享整理内容，由人人都是产品经理运营@Norah整理发布。未经许可，禁止转载，谢谢合作。

题图来自大会现场

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。

好了，文章到此结束，希望可以帮助到大家。