”图解”产品：产品经理业务设计与UML建模

过时+简单。同时也说明一个问题，其实打工人做的事情基本上都不是什么很难度高的一件事情。早期的产品经理就是这样的水平啊。且我也不认为微信是一个很复杂的产品，就是这么简单的产品确是用户最多的产品。 所以需要自信，从心底的认为自己做的东西有价值。因为不是越复杂才叫越有价值。

认真地看完了这本书，对于产品同行们来说，可以快速浏览阅读。 这本书主要介绍了一个模型，包含四层九要素： 定方向（产品战略、解决方案）、 搭框架（功能框架、非功能框架）、 做细节（业务流程、业务操作、信息结构） 画界面（信息设计、交互设计） 个人觉得比较有用的部分是介绍功能框架，业务流程，业务操作，信息结构这几个部份，作者分别介绍了uml的几种图：用例图、业务流程图、状态图、类图等，并详细介绍了这几种图该怎么画，这些是可以在书中学习到的。 对于自己来说，给自己启发的几个点： 1、要从用户需求出发，站在用户的角度思考问题，而不是一开始就从系统角度，应该要做哪些功能； 2、在信息结构这块，要梳理类的属性，类之间的数量和关键关系，这对信息的呈现来讲有重要关系；

本书最有用的内容就在最前1-2章介绍的产品设计结构。后面的UML纯从结构化思维来看，有没有无足轻重。其次，UML最初出现是为了，设计能转换为开发语言减少工作量，后续慢慢脱离实际迭代要求的场景就慢慢退出舞台了。

本书更适合B端产品经理 主要讲了4层9要素 产品战略和解决方法 产品框架：功能类，非功能类 业务流程 界面设计 提到了UML

太差了，和书的主题都不匹配，讲了些不相关的。

产品经理一方面要梳理线下业务流程，明确用户到底想要什么（用户需求），另一方面要为产品开发团队给出产品需求，明确待开发的产品如何支持用户的需求，这之间的桥梁就是“业务模型”。 不同的业务构造出的“业务模型”本身是千差万别的，但“构造技术”相通，基本都来自UML，大部分的产品经理也有了解或使用这种技术，说明UML在产品设计中是一种有用的工具，但为什么大部分产品经理使用不起来呢？放在需求文档中，并没有对文档的完整度、清晰度、准确度做出贡献，更像是一种点缀。 我自己的感受是标准的UML过于概念化，而且实际上更偏向于一种软件编码设计的工具，对产品经理群体不是很友善。关于产品经理如何使用UML的资料，也都是碎片化的文章。 对于我而言，本书可以看做是写给业务产品经理日常工作手册。其中印象深刻的，有如何使用UML设计产品用例、业务流程、产品信息结构的最佳实践，也有常见的非功能需求列表，很有指导价值。除了这些“术”，也给出一个“道”，以业务为中心的四层九要素设计框架（和《用户体验要素》中以用户体验为中心的五层十要素设计框架类似）。 还有一点，这本书的编写和思维方式也值得学习，以“演绎”的方式，从作者设定的业务设计框架和定义出发，逐步推演出一部关于业务类产品设计方法的“大厦”，和我们产品经理追求写出一个高质量的需求文档一样，本身就具有较好的完整性、清晰性和准确性。也可以跟随作者的思路和知识“地图”，再次扩展。 最后，我真正做产品策划这小半年以来，体会到产品设计不是纸上谈兵，仍然是一门实践性极强的岗位，需要将学习到的知识真正应用到产品设计中，才能成为自己的知识与智慧。

在书的最后，作者强调了 UML 和用户故事之间的关系部分。致谢部分也提到了张恂老师。这让我想起了一段往事。 几年前我曾经和张在知乎上有几次争论。我的观点是，产品经理最重要的是市场和品牌管理，以及用故事界定产品。建模交给架构师和技术团队。Scrum 过程对产品经理的要求是做好客户代表，重点是验证模型，而不是即写故事又做模型。否则你让在研发部门的业务架构师、需求分析师干什么呢？你如果越俎代庖，怎么发挥架构师和工程师用uml建模的专业性价值呢？你又怎么确定产品经理的uml建模的准确性呢？ 为什么会有这个争议，就是因为互联网的爆发将产品经理岗位职责泛化了。 所谓产品经理，就是产品的管理者。而产品是企业用来出售营利的商业单元。产品经理要解决的核心问题是：做什么，卖给谁，怎么卖。这三个问题中，第一个问题是产品形态问题，第二个问题是市场问题，第三个问题是营销问题。因此，市场营销和领域知识是产品经理的核心技能。但反观互联网产品经理，把重点都放到了领域知识上，甚至深入到技术研发的角度，这是错误的。 技术研发有专门的研发团队干。我不认为有纯粹的技术团队。技术是用来应用的。科学可以纯粹，但技术不行。因此技术人员必需能把握产品的应用方向，就是要和产品经理双向奔赴。只是产品经理重点放在如何通过产品打通市场上，技术重点放在研发出根据产品经理规划满足市场需求的产品上。 相对大量学计算机的技术人员而言，经过市场营销训练的产品经理更加难得。让产品经理用软件工程工具建模，是暴殄天物，也是对工程师专业性的褫夺。

刚看到书名时有点开心，可算有本产品相关的书籍和UML深刻结合起来，也印证了我的产品道路是正确的，至少没有走偏。大部分观点和作者一致，能产生一些共鸣。软件是互联网产品的载体，互联网产品经理应该掌握软件工程方面的知识，并探索出属于自己的方法论灵活运用。 对于UML，是一种工具，目的是建模，抽象现实，使用哪些图、细化到什么程度因场景、阅读者而异。 对于产品文档，当然是越详细越好，但时间成本也相应越来越高，“用最少时间，编写最少内容，且该文档能被研发人员快速看完、正确开发”是非常理想的状态。 对于流程驱动、用例驱动、领域驱动，对于瀑布、RUP、敏捷开发，对于用例、用户故事，是软件行业发展到不同阶段解决不同问题的产物，没有孰优孰劣，应该根据产品情况、项目规模选择性使用。

太水货了这本书，没有啥干货，看完只觉得浪费我时间。 第一次看目录还觉得挺有看头的，说不定可以跟平时里工作场景进行一下验证，便加入到书架中，抽国庆空闲时间翻阅了下这个书，结果没想到看完以后啥收获也没有，废话一堆还故弄玄虚，将几个所谓的理论百度粘贴后堆砌在一起后就开始水字数，再自己臆想中一下实际案例，还不如大学老师为了水资格出的教材质量高。本书唯一的看点就是目录这块了，回头可以搜关键词找找对应的材料看看。 气死我了，一般的烂书我忍忍就算了，这次算我走眼浪费宝贵的国庆假期看这破玩意，不吐不快！

我是书作者擎苍，感谢各位阅读，大家可到公号「图解产品设计」上学习更多知识和案例。[微笑][微笑][微笑]