前言

每一个初入行的产品经理，都梦想像乔布斯、张小龙一样改变世界。但是现实却如下图

你满怀期待的去跟业务聊需求，发现根本是鸡同鸭讲。
到了方案设计的时候，B端产品的逻辑盘根错节，脑子一团乱麻根本梳理不清楚。
需求评审时，那更是社死现场，开发测试听得一头雾水，直呼你的文档太差根本看不懂。
……

等到好不容易需求聊明白了，方案也设计好了，上线后却发现
1个小需求，开发张⼝要10PD开发，因为底层关联调整点太多，耦合太重
好不容易开发完上线了，却上线就报BUG了，只因流程分⽀缺少闭环，异常场景没有覆盖到
赶紧加班修BUG，结果BUG修好了，主流程给弄挂了
……

出现这些问题，大部分都是因为缺少复杂系统建模的思维和方法。
而UML是一套能有效解决上述问题的方法论。

什么是UML

UML：Unified Modeling Language 统⼀建模语⾔
1997年，由OMG组织（Object Management Group 对象管理组织）发布，是为⾯向对象的系统进⾏可视化说明的统⼀建模语⾔

用例图

用例图简介

梳理用例图的步骤

用例图梳理的TIPS

1. 针对B端业务系统，在《组织架构及岗位权责》《业务SOP流程》⾥藏着梳理「业务⽤例图」所需的关键信息
2. 通过对「业务⽤例图」进⼀步抽象归纳，可以推演出「系统⽤例图」。「系统⽤例图」进⼀步推演就是系统功能架构
3. ⽤例图和流程图梳理完成后，可以相互校准，保证业务全流程全场景都有覆盖，避免遗漏边缘case

用例图的常见问题

1. 1张⽤例图搞定1套系统
   复杂B端系统涉及的⽤户⻆⾊众多，⽤例繁多，1张⽤例图是难以介绍清楚。
   建议⽤⾦字塔原理⽅式，先输出粗颗粒度的⽤例图，逐级拆分细化。
2. 系统边界模糊不清
   复杂B端系统上下游多，边界划分不清楚会导致范围不断蔓延项⽬失控。
   例如 CRM售后环节，哪些⽤例是由CRM承接，哪些是财务系统承接，需要将边界标识清晰
3. 「步骤」当做「⽤例」
   「⽤例」有明确⽬标和产出结果的，「步骤」则是⼀个具体的执⾏动作。
   举例：登录系统是⼀个⽤例。但是输⼊⽤户名-输⼊密码-密码校验及错误提示，这些是步骤不是⽤例。

活动图

活动图简介

梳理活动图的步骤

梳理活动图的TIPS

1. 先主⼲再分⽀，最后补充异常分⽀流程，避免⼀开始就陷⼊细节导致梳理进度停滞。
2. 控制活动数量，⼀个流程图不要超过20个活动。如果超出，可以合并为1个⼦流程。针对⼦流程，再拆出来图。
3. 尽量保持从上往下、从左往右的顺序，活动之间居中或⽔平对⻬，连线不要交叉，让图更容易阅读。
4. 梳理完⼀定要全局review⼀遍，检查各个分⽀是否都有出⼝，流程是否闭环，是否存在循环嵌套等情况

活动图常见问题

1. 完全照搬业务流程
   业务流程并⼀定合理，尤其是将流程线上化后。所以产品经理⼀定要基于业务实际情
   况，进⾏⼆次梳理及优化。

2. 1张活动图搞定1套系统
   复杂B端系统⽀持的业务场景众多，1张活动图太粗会导致关键细节展示不出来；太细太复杂，⽤户⽆法理解。
   建议⾦字塔原理⽅式，先输出核⼼主活动图，再拆分细化⼦活动图。

3. 活动流程不MECE
   复杂业务流程，如果存在某条分⽀⽆后续动作、⽆法结束或相互冲突，这些落到系统实现时都会出现BUG。活动图更加清晰直观，梳理完⼀定要再次review。

状态机图

状态机图简介

梳理状态机图的步骤

梳理状态机图的TIPS

1. 先主⼲再分⽀，最后补充异常状态，避免⼀开始就陷⼊细节导致梳理进度停滞。
2. 控制状态数量，基于应⽤场景和⽬标来梳理。不需要的状态尽量去除，让结构更简单。
3. 梳理完⼀定要结合流程图，进⾏全局review⼀遍。检查各个分⽀是否都有出⼝，状态MECE

状态机图常见问题

1. 颗粒度不合理 01
   状态颗粒度⼀定要考虑业务⽬标、应⽤场景和后续业务扩展
   举例：电商订单状态如果只有已下单、已⽀付、已取消这3个状态，那如果⽤户要看哪些订单已
   发货就⽆法简单实现。如果拆分成 已下单-已⽀付-已传⾄仓库-仓库已收单……对⽤户来说太细，没有意义。
2. 状态不MECE 02
   对象的状态贯穿整个⽣命周期的，如果不闭环or不MECE会导致产品BUG。
   举例：电商订单状态如果没有已取消的状态，那⽤户取消订单后这个订单接下来会如何流转，
   就会出现异常。如果订单同时有2个状态，⽐如同时存在已取消和已发货2种状态，到底物流如何处理就会有问题。
3. 名称不易理解 03
   名称太晦涩不好理解，会增加⽤户的理解和使⽤成本。
   举例：电商订单状态⾥【待确认】的状态，那是正向下单待确认，还是逆向退单待确认？
   所以状态名称⼀定要简单清晰，可以梳理完后找⼏个⽤户测试下他们是否能快速并正确理解。

活动图和状态机图的区别

04 类图及E-R图

类图简介

ER图简介

梳理类图/ER图的步骤

梳理类图/ER图的TIPS

1. 通过⽤例图和业务活动图，能快速识别找出核⼼实体和核⼼属性。
2. 在抽象实体和关系时，务必要梳理清楚业务现状，并且充分考虑未来业务发展。
3. 梳理「实体关系和关联基数」时，⼀定要充分考虑业务管控逻辑和数据分析需求，避免设计不合理，后续⽆法分析。

类图/ER 图 - 常⻅问题

1. 错把「属性」当做「实体」
   Badcase：下图将员⼯和管理员分别拆分为了2个实体但管理员只不过是员⼯中⻆⾊⽐较特殊的⼀种，普通员⼯和管理员除了身份⻆⾊不⼀样，其他属性基本都相同。单独拆分后会导致数据冗余
2. 实体抽象不合理 
   实体抽象要符合【单⼀职责原则】，即⼀个实体只负责⼀个功能职责
   Badcase：绩效管理系统中实体抽象成为了1个实体【绩效评价】。但⼀个员⼯有1个⾃评，多个360评价。只有⾃评之后，才能进⾏TL评价……如果只抽象出1个实体，这个控制逻辑就会相对复杂，后续的统计也会很混乱
3. 基数关系不合理 
   Badcase：财务预算系统限制「付款记录」和「预算科⽬」是多对1关系，即1笔付款唯⼀对应1个预算科⽬。但实际的业务场景，⼀个总包合同内可能既有咨询费、⼜有软件费，应该归属不同预算科⽬。

    产品设计如盖房⼦，数据建模是打地基。结构不合理，地基不牢固，结果将会是灾难性。