大厂都不用UML？记一次酣畅淋漓的微信对话
关于UML要不要学可谓争议不断，观点颇为对立。有人说有用，有人说没用；有人说我就是一线公司产品经理，UML根本没用，别听他瞎说。
下面的内容是我和网友王文艺对UML的讨论，沟通的酣畅淋漓。这些内容有利于大家理解UML的价值、澄清一些误区。
内容略有删改，还原度90%，主要是修改描述问题和错字，去掉不适合公开说的话。
01 如何看待UML的几本书?
王文艺：请问你怎么看UMLChina的潘加宇写的《软件方法》一书？
擎苍：潘加宇的书虽豆瓣达到8.5分，但写的很差。潘的书的问题在于他没有搞清楚概念，以及提出这个概念的目的和要解决的问题，从而把一些基础东西解释错了。张恂老师批过此书，说“只达到了业余研究UML水平”，是这么回事。
王文艺：《火球UML》一书，你怎么看？
擎苍：火球这本书还可以，浅显易懂，知识讲解到位，最后举的考勤系统案例挺不错的，这个案例还曾经是今日头条的产品经理的考题。但这本书不是完全给产品经理看的书。
擎苍 ：潘加宇的书知道的人少，深入研究UML的产品经理也少，请问你怎么提到了这两本书？
王文艺：这两本书我都反复看了几遍，你的书我还没看。
擎苍：我在公众号上推了《大象UML》，《火球UML》和张恂的《统一用例方法》。实用性上，《大象UML》的电力案例需要看（用于实战），《火球UML》的基础讲解和考勤案例要看（用于实战），张恂独创的用例表达方法要看（用于编写简洁产品文档），但不能全抄。
擎苍 ：再要深入就是我朋友圈说的两本书了：UML发明人的书、北大教授和院士合著的书。大概翻一下就可以，有启迪、长见识，知道思考的高度在哪里；但更抽象、更思辨，不容易读懂。
王文艺：谢谢
擎苍 ：
02 BPMN和UML
王文艺：BPMN和UML的区别，你是怎么看的？
擎苍：是部分替代关系。UML是首选，简单些，成系统和应用广。
王文艺：不少人都说是替代关系，了解其一即可，而我不这样想。初期接触项目和需求时，我还是建议使用BPMN图进行全局性描述，而后分解模块需求时采用UML的部分图进行分析。
王文艺：当然不懂BPMN也是可以进行全局描述的，毕竟各种图也只是表达方式之一，小项目确实不需要太多图。
王文艺：分析推敲优化一个需求的过程，是反复比对实例和抽象的过程，基于对实例的理解，去不断修正抽象图，而我一般用BPMN来表达实例，用UML来表达抽象。
擎苍 ：拿大系统为例，BPMN的应用偏重研发侧，UML的应用更中性一些。而UML其实也可以混合用，即活动，状态，对象等表达混在一起，从而起到类似BPMN的作用。
擎苍 ：UML混合用少，一来不方便分层思考，也就是把问题归类设计；二来产品经理这样做必要性降低，且使用难度加大，更加抽象与宏观。
王文艺：嗯，是的，你这样的说法也对，这个可能是不同的人对图的熟练应用程度不同导致的差异。
王文艺：设计产品一种方法是从全局开始设计，一种是从局部开始设计（如用UML的“用例"），再不断延伸。如较大系统，两类设计方法应交叉运用，不断细化，不断宏观。
03 用户故事和UML
擎苍：其实即使阿里这样的公司，有的部门也过于重视用户故事，而忽略UML，这样做并不合适。这个问题我和阿里专家讨论过，他认可。
王文艺：同一个用户故事，可以抽象出完全不同的UML图。而需求分析的过程，就是反复比对优化用户故事与UML图的过程，这个过程耗时低效，很难让外部感知到直接价值，而实际中，往往是抽象分析的阶段，特别是用例分析阶段往往要让位于原型等。
王文艺：用户故事的场景描述非常丰富，原型非常精美；而用例分析和抽象的流程分析，这个往往是薄弱环节，甚至是事后再补。主要还是因为这个过程目前很难让外部感知到直接的价值。
擎苍：用户故事和用例是偏等价关系，在张恂老师的书上有详细的分析，在我的书上也有说明。
简单地说用户故事是简化的用例，是含有设计方法和步骤的一整套内容（可见用户故事发明人的书），可以认为是故事驱动的整套产品设计方法。
用例图只规定了画法，可以认为就是一本语法书，但却有一些问题的语法书——北大教授和院士合著的书中对用例有批评，我的书中有引用。
擎苍 ：常见的用例使用误区有：① 就画图而忽略其分析方法，如其先外后内，化繁为简（把大系统先抽象成一些用例）的分析方法；② 用例的包含扩展关系（这是UML自身问题）。
而用例更好的用法应是用Xmind或用例描述表，而不必画用例图。我的书修改了用例的问题，并引入了更结构化的表达。
王文艺：是的 
04 为什么大厂UML也用的少？
，我本人用UML和BPMN工作了十多年了！ 
三步绘制大厂状态图（1）（改自《图解产品》）
— 新书推荐 —
了解本书点击《图解产品》值得入手吗？