断断续续的读了两个月，总算读完这本书了。跟书名一样，这本书深入浅出的讲解了产品经理在梳理产品需求时，会涉及到画哪些图，以及这些图都有什么作用。
在我的产品设计过程中，用到最多的是活动图（流程图），泳道图（流程图），时序图，状态图。在本书中作者描述了更多的图，比如类图，这部分我在之前的博文中也有具体描述。作者从产品经理业务设计的全流程开始，一步一步的告诉读者，产品经理需求梳理的全貌。
认知篇：认识业务设计
认知篇属于扫盲帖，让用户对需求分析以及需求分析的工具进行一个粗略介绍。核心就是一句话：产品的本质是为了解决业务问题，所以应该以业务为中心来进行产品设计。
但是这里有一个误区，我待过的公司中大多数存在一个误区，就是什么是以业务为中心？在很多公司变成了以业务人员的口述需求为中心，我觉得这是一个很大的误区，在产品设计中一定要避免。一个经典的例子，用户要一匹马，业务员可能会想到给客户提供一匹赛马，但是产品解决方案最终可能是一辆车，那么这个例子的以业务为中心是什么？我觉得是要满足用户快速实现两点之间距离位移，所以很多时候，业务人员会提一些在他们认知范围之内的需求，并要求产品经理按照他们的思路去实现，这是不合理的，要尽量避免。
定方向：产品战略、解决方案
产品战略跟解决方案属于需求分析的前期工作，大部分执行产品经理在这一块接触不会太多。拿我曾经负责过的一些项目来说，战略上基本都是老板定的，比如做一个产品就是为了噱头，提升公司股价，这算是产品的战略。又或者这个产品要解决什么样的用户痛点，实现什么样的商业目标都属于战略的一环。同时要判断当前环境下，自身企业是否具备做这个产品的机会。
有了战略之后，产品经理要梳理解决方案，在本书中，作者主要介绍了梳理解决方案的具体步骤：
- 梳理涉众：也就是目标用户，你要为谁来做这个产品？
- 梳理涉众的期望：你的目标用户期望通过你的产品解决什么痛点？
- 确定产品价值：比如你的产品有什么价值点？举个例子，淘宝可以让卖家在平台出售商品，获得收益，这就是属于用户的价值；
- 构建高价值的解决方案：给目标用户一套高价值的解决方案，什么是高价值？就是既能解决用户的问题，又能恰到好处的满足用户的定位，这里有一点比较重要，并不是一味的降低成本就能满足用户的价值，作者举了一个高档餐厅跟大排档的区别，高档餐厅的菜单需要精致，配的上餐厅的基调；大排档的菜单则不需要，同样是菜单，面对的客户不一样，产品经理要给出的解决方案也不一样。
- 确定需求排期：这点就是根据用户确定好的需求点梳理方案，并且对需求进行排期。在需求的开发过程中，可能一开始梳理的需求量是巨大的，比如你要做一个电商网站，那么卖家中心的商品管理、订单管理、库存管理就属于高优先级的功能，售后模块可以在优先级较高的功能昨晚之后再开发，这个就属于优先级。类似的还有多种支付方式，电商初期可能只支持银行卡或者余额支付，随着用户量的提升，移动支付、金融白条之类的需求也可以加上。
搭框架：功能框架、非功能框架
搭框架一般就是结构设计，如果复杂点也可以叫架构设计。把用户不同的功能组合起来，形成一套框架，这点类似于建房子的CAD图纸。比如这套房子预估入住人数为一家三代6口人，就有了以下的结构：
- 爷爷奶奶：老人房；
- 父母：卧室；
- 子女：儿童房；
- 公共：书房、客厅、厨房、阳台；
在书中，作者是通过用例图来进行梳理，这里我自己在梳理时，更多的喜欢用思维导图，当然这个各有所爱，工具不是问题，目的是梳理清除功能框架。有关搭框架作者介绍了三种方法：用例技术、流程驱动设计、领域驱动设计。
对于非功能框架，这部分在中小系统中很少涉及，而且大部分都是研发根据经验处理了。比如系统的并发、接口的响应时间、对用户输入数据的数据加密（隐私保护）等等，还有一些等保要求的需求，大多数也都是非功能性需求，这部分需要产品经理对技术有一定的了解，否则是无法准确的定义这部分需求的。但是非技术出生的产品经理也应该了解。
其实这部分作者还应该写一部分，就是需求中的产品框架该如何定义，上面作者描述了功能框架，拿作者在书中举例的银行系统来说：
用例图清晰的描述了系统的涉众分别应该做哪些事儿，但是系统应该如何设计呢？作者并没有提到，我认为在搭框架的部分还应该把产品架构定义清晰，比如我通过作者书中的描述，我认为银行系统应该如下（简化版）：
- 系统设置：
- 员工管理；
- 角色管理；
- 客户管理：所有银行的客户（储户）；
- 银行卡管理：所有客户的银行卡管理，比如银行卡的各种信息，开户资料等；
- 基金管理：
- 基金申购：客户线下柜台提出申购，客户经理在系统进行申购处理；
- 基金赎回：客户线下赎回基金；
这个我称之为产品架构，有区别与功能架构，功能架构会完整的包含在产品架构中，产品架构对于多个产品共同负责一款产品是很重要的，可以通过产品架构来进行产品分工，这样团队的新人也能够独立负责一个模块。
做细节：业务流程、业务操作、信息结构
业务流程这块可以通过泳道图、流程图、状态图、时序图等多种方式来进行梳理。常用的为流程图，比如一个系统有多个涉众，从第一个流程发起者开始，一直到最后的流程结束，我们称之为业务流程。
拿最常用的电商系统来举例吧，当现在有了一个电商系统，卖家首先需要在后台去发布商品，导入库存。此时用户在前台可以看到已发布的商品，然后进行下单、支付。支付完成之后卖家需要进行发货，发货之后需要通知仓库进行打包，然后通知快递员上门揽件，快递揽件之后进入快递过程，最终用户收到货物，并确认收货，电商平台此时需要把货款支付给卖家。这样一个完整的电商流程就结束了。
这个全流程我们称之为业务流程；在这个流程中有许多涉众、有卖家、买家、库管员、快递员，他们在这个系统中的操作就称之为业务操作；针对商品信息、卖家信息、仓库信息则可以用信息结构来表示，比如商品有规格、价格、属性等多种属性；
当然我上面举的例子只是为了简化说明，实际在电商系统中还有各种复杂的流程，比如出入库的流程、下单的流程、商品发布的流程、售后退款的流程等等，如果产品经理在画图时发现流程过长，在梳理总流程时可以将颗粒度放大，从而梳理出总的流程。在具体的业务流程中再单独细化。
业务操作一般用状态图或用例图来表示，举例就是电商的订单状态，我们简单的设计为以下：
| 状态 | 卖家操作 | 买家操作 |
|---|---|---|
| 待付款 | 取消订单、修改订单 | 取消订单、付款、修改订单 |
| 待发货 | 发货 | 售后 |
| 待收货 | – | 确认收货 |
| 已完成 | – | – |
就是不同状态的订单在卖家跟买家端有不同的操作，用状态图非常好表示这个关系。
画界面：交互设计、信息设计
画界面属于产品经理工作最繁琐也最细节的一环了，产品经理需要根据产品架构来确定页面上的字段参数。这一章我感觉作者写的也比较模糊，首先在大多数公司，这块的工作至少分了两个岗位（产品经理，UI设计师），产品一般只需要根据产品架构图出线框图即可，然后UI设计师根据线框图输出UI。至于其中的交互设计，在没有UE（交互设计师）的情况下，由产品经理跟UI共同负责。
举个例子：经常点外卖的知道外卖添加到购物车的时候会有一个动效，这就属于交互的一部分，产品经理很少会通过axure或者墨刀把这种交互做出来，只能做一些左滑右滑，单击双击之类的。
有关交互设计，在我的产品经历中，我更喜欢用框架，比如早些年的bootstrap，然后后来的ant design，elementUI，小程序的UNI等等，产品经理应该多看这些框架的交互设计，从而提升自己的设计经验。
信息设计我一般习惯用用例图来查漏补缺，一个页面比如商品管理，用例就有：发布商品、下架商品、上架商品、删除、编辑、价格调整等等；每一个用例都是一个独立的功能，比如发布需要用到发布页面，下架可能是一个弹窗等等。
信息设计还有一个比较重要的就是字段：页面上需要展示什么字段，研发就需要对应的在数据库建表，并且每个字段需要明确的标注字段的来源、是否必填、上下限等。
| 字段 | 是否必填 | 长度 | 类型 | 默认值 | 备注 |
|---|---|---|---|---|---|
| 预售日期 | 是 | 18 | datetime | 当前日期 | 字段的备注说明 |
在对字段进行描述时，一定要深入思考，当然，这部分很多产品经理不知道字段的类型有哪些，基本上只需要了解str（字符串），int（整数），decimal（小数）就足够了，感兴趣的可以自行网上搜索学习下字段的类型还有哪些？研发也需要通过这个文档来进行表结构的建立。下图为数据库的表结构示例。
拓展篇：应用和思考业务设计
拓展篇更多的是对前面的一些内容的扩展，在第二部分梳理解决方案的时候其实就已经要开始业务调研、业务分析与设计了，作者在这部分扩展讲解了一些业务调研、用户访谈、竞品分析的方法，将的比较浅，所以这部分我只粗度了下，没有深入。比如我自己在做业务分析跟调研时，经常会想到找开源的同类产品，然后自己搭建一套完整的产品，从功能到数据表结构去进行分析。
后面的设计模型、UML、用例和用户故事这块基本上就是浅浅的带过了，如果想更深入的了解设计模型还是建议找专业的书籍来进行阅读，UML我推荐《火球UML大战需求分析》，懂技术的可以去plantuml官网学习。
后记
整本书读完感觉能打个6分吧，对于初级产品、中级产品而言本书还是值得一读，算是一种产品方法论。但是所有产品的书几乎也都有一个通病，就是基本上都是把产品要做的工作从头到尾给你走一遍，广度够了，但是深度不够。
评论区