这个月看了谭云杰编写的《大象-Thinking in UML（第二版）》，有些启发，这篇文章来聊聊产品工作中有没有必要学习UML
先说说这本书，是在朋友强烈安利下看的，他说看完后码需求文档有一种要触到G点的感觉：）
我那么正经的人，肯定…嗯，饶有兴趣，所以借来看了下，约定7月底还书。
毕竟，书非借不能读，这个道理都懂。
1. 客观的评价下这本书，三星（不建议购买）
· 优点：
1. 将UML讲解的很透彻，不局限于如何画UML，而是着重讲解运用UML思考方式，这个也是给我收获最大的地方；
2. 将UML结合实际case讲解，不难理解；
· 缺点（从阅读者是产品的角度评价）：
1. 太太太啰嗦…容易看到睡着，526页的书，可以精简到150页内。如果购买，推荐重点看第三章和第四章（讲解UML怎么画），第九章和第十章（讲解UML怎么用）；
2. 内容抓不到重点，太多口语化内容，也没有对重点内容标粗。例如小标题经常是第一个讨论，第二个讨论，缺乏对标题的总结，看着累；
3. 实际面对的读者人群是程序员，所以其中大量的使用了编程相关的术语，例如类，对象，组件，接口，通信协议，实际不是很适合产品在没有技术基础的情况下阅读。书后面的接口设计，数据库设计产品同学可以不看；
2. 产品需不需要学UML
问这个问题，原因是在知乎上看到太多的争论，现在的UML学来到底还有没有价值，研发不用，老板不看，团队不用，实际根本接触不到，感谢没必要学啊
瞎说什么大实话啊）
说说我个人观点答案，这个问题就是小马过河的问题，应该分开看，结合自己的实际背景。
如果是B端产品，建议详细学；如果是C端产品，简单看看，知道怎么画图就好。
· C端产品-学会画图
我刚入行的时候做的就是C端产品，产品主要功能是面向用户提供挂号服务，还算幸运，这款应用的Android端，iOS端，微信端，PC网页端，小程序，管理后台我都接触过，但即使是接触了那么多端，使用到UML的频率很低很低。
不过UML中的静态用例图，动态的时序图，状态图，活动图，在理清需求的时候还是很有帮助，简单学习下，一天内就能学会。
例如在理解微信登录是原理时，一张时序图很清晰的讲解了每个节点发生的事情。
· B端产品-详细学
为什么转型到B端，需要详细学习？
两个原因
1） 从0到1的过程多了
转型AI产品后，产品的客户不再是C端客户，而是为企业级用户提供基于AI能力的解决方案
随着市场需求的变动，需要不断的推陈出新，做出新产品满足用户需求，甚至不少的纯定制化的。
从0到1的过程多了，每款新产品都需要去了解企业客户的需求，UML是不错的方式。
2） 产品方案整体更为复杂
C端产品中，产品经理考虑更多的是页面跳转逻辑，体验细节，页面用语，可能改动一个消息button，对页面的转化率就是几倍的提升。
但是到了B端，需要考虑更多的是如何在满足客户海量需求的情况下，如何将定制化的需求尽量的做的可复用；如何使得产品模块化，能更快拆分组合；产品方案如何打矩阵在市场中更具有竞争力等等，较少再去抠页面的细节。
B端更重视业务逻辑，但是不同行业，不同客户的业务逻辑是不同的，梳理这些各行各业客户累积的几年的业务逻辑，不是一件简单的事情。
这时候UML的抽象能力，能让你从海量的需求中抽离出来，以更高的视野去看待整体。
3. B端产品工作中如何运用UML
3.1 UML的常用类型
UML中，产品常用的就4类
1）用例图-分析业务需求
2）活动图-分析流程
3）状态图-分析状态变化
4）时序图-分析流程，更专注时间节点
其中活动图和状态图，现在基本用Visio图来画，画UML的主要是用例图和时序图，学会这四种也就差不多了。
这也是书中第三第四章详细讲的内容，网上教如何画UML的太多，这里不展开讲
但UML不仅仅是画图工具，更重要的是学会用UML是理念来思考
3.2 和客户交流获取业务需求
从UML思想学到的是，在和客户讨论的时候，要和系统中不同的涉众进行访谈，获取不同涉众的期望（业务需求）
访谈中，先聊总体，对业务框架有了清晰的认识，找出业务需求，再深入到每个业务需求去细聊，避免一开始就陷入到海量的业务细节中，没有整体的框架。
书中提供了对涉众（和产品有关系的群众）进行访谈的方式，可以借鉴
1. 你对于系统的期望
涉众可能会提及具体的细节，但访谈应该先从业务需求入手，再逐层细化，所以要有意识的引导用户，在客户说完后，要思考可能的业务需求，用自己的话将概括的用户需求复述给用户，让用户确认
2. 打算在系统内做什么事情
粗粒度的了解业务需求，业务范围，类型，具体的业务细节不需要探讨先
3. 这些事情的目的是什么
为什么做某个具体的业务需求，为了谁，背景？
4. 做完这些事情之后，期望的结果是什么
某个业务需求实现后，会发生什么事情，有没有后续的工作
获取到这些材料后，可以编辑成一个个的用户简档，其实就是用户画像
过去我们强调要站在用户的角度去思考，一秒钟变小白
但没那么简单啊。。。用用户建档的方式，实际就是用了5W1H的方式去还原场景，形成一个简单的用户画像
有了这些用户画像，以人的角度去思考业务需求，容易带入身份，也不容易漏
3.3 将业务需求分解为细化为产品需求
基于收集到的用户简档案，如何一步步的细分为产品的需求，将书中第九章“需求获取”部分整理如下
1）梳理业务需求（用例图）
从业务目标的角度来划分边界，与该业务目标有关系的用例放在这个边界以内，再从涉众中找到主角（只有和系统直接交互的涉众才是主角），梳理出业务需求
如此反复的界定边界，找到主角，梳理用例，直到边界不能再分为止，找出所有的业务需求
例如 图书馆的电子化借阅系统
从方便借阅书籍的目标出发
划分边界，那么图书管理员就是在业务边界内，属于业务工人，仅从读者的角度出发，找出读者的4个业务需求
如果业务的目标变为 方便管理图书馆内部书籍，再划分边界
那么这时候这个用例里，就只有图书馆工作人员，他们成了主角，也是4个业务需求。读者和这个系统无关，不在用例内。
2）业务建模（活动图，时序图）
将拿到的一个个业务需求，通过活动图和时序图的方式分析，形成系统需求
3）细化业务规则
将拿到的全局规则，交互规则和字段规则，补充到系统需求中
4）补充非功能性需求
最后，再考虑系统的可靠性、可用性、有效性、移植性等
通过同用户访谈 --> 细化产品需求两大步，就能在混沌的用户话语中，提炼出一套完整的 用户需求。
4. 最后，讲讲做B端产品的感想
做B端产品3个月了，刚入职的时候，正好赶上公司的一个S级项目，从0到1完整的走了下来
感慨这三个月，B端产品和C端产品真的差别太大
C端产品要求你专注，认真打磨产品，流量为王，转化为王；
B端产品则要求在宏观的大局上，能全局思考。客户需求，边界，项目排期，研发进度管控，实施部署，都要考虑，产品能在市场上有竞争力，能打下单子，能赢得客户才是最重要的。
从0到1的过程，也让我有机会将过往的产品知识都一一用上，挖个坑吧，之后抽空写一篇从0到1的经验分享。
大学时看企业间销售商战的故事，刀刀见血，攻城拔寨的感觉，看的我热血沸腾。
现在亲身经历下来，特别是和BAT竞争并且胜利的时候，这种感觉真的贼爽。
但同时，这段时间也没少出差和客户面谈调研需求，甚至要当天早上5,6点飞上海，晚上1,2点飞回来，真的是累并快乐着：）
另外，这段时间接触到了形形色色色色色色的人，因为出差，有机会观察到不同公司员工的工作状态，同他们交流聊天，越接触越觉得，啊，世界，真大啊！
#推荐书籍#
觉得《大象-Thinking in UML》太啰嗦了，书籍整体逻辑不清晰，推荐看另一本UML教学书籍
《火球-UML大战需求分析》（点击可下载）
