目 录CONTENT

文章目录

《“图解”产品:产品经理业务设计与UML建模》读书笔记

慧行说
2023-09-15 / 6 评论 / 4 点赞 / 808 阅读 / 3,689 字 / 正在检测是否收录...
温馨提示:
本文最后更新于 2023-10-31,若内容或图片失效,请留言反馈。部分素材来自网络,若不小心影响到您的利益,请联系我们删除。

DALL·E 2023-10-31 22.34.48 - A photo illustration tailored for a product management blog. The central focus is on a large whiteboard filled with UML diagrams and flowcharts. Adjac

断断续续的读了两个月,总算读完这本书了。跟书名一样,这本书深入浅出的讲解了产品经理在梳理产品需求时,会涉及到画哪些图,以及这些图都有什么作用。

在我的产品设计过程中,用到最多的是活动图(流程图),泳道图(流程图),时序图,状态图。在本书中作者描述了更多的图,比如类图,这部分我在之前的博文中也有具体描述。作者从产品经理业务设计的全流程开始,一步一步的告诉读者,产品经理需求梳理的全貌。

image-20230914142943491

认知篇:认识业务设计

认知篇属于扫盲帖,让用户对需求分析以及需求分析的工具进行一个粗略介绍。核心就是一句话:产品的本质是为了解决业务问题,所以应该以业务为中心来进行产品设计

但是这里有一个误区,我待过的公司中大多数存在一个误区,就是什么是以业务为中心?在很多公司变成了以业务人员的口述需求为中心,我觉得这是一个很大的误区,在产品设计中一定要避免。一个经典的例子,用户要一匹马,业务员可能会想到给客户提供一匹赛马,但是产品解决方案最终可能是一辆车,那么这个例子的以业务为中心是什么?我觉得是要满足用户快速实现两点之间距离位移,所以很多时候,业务人员会提一些在他们认知范围之内的需求,并要求产品经理按照他们的思路去实现,这是不合理的,要尽量避免。

定方向:产品战略、解决方案

产品战略跟解决方案属于需求分析的前期工作,大部分执行产品经理在这一块接触不会太多。拿我曾经负责过的一些项目来说,战略上基本都是老板定的,比如做一个产品就是为了噱头,提升公司股价,这算是产品的战略。又或者这个产品要解决什么样的用户痛点,实现什么样的商业目标都属于战略的一环。同时要判断当前环境下,自身企业是否具备做这个产品的机会。

有了战略之后,产品经理要梳理解决方案,在本书中,作者主要介绍了梳理解决方案的具体步骤:

  • 梳理涉众:也就是目标用户,你要为谁来做这个产品?
  • 梳理涉众的期望:你的目标用户期望通过你的产品解决什么痛点?
  • 确定产品价值:比如你的产品有什么价值点?举个例子,淘宝可以让卖家在平台出售商品,获得收益,这就是属于用户的价值;
  • 构建高价值的解决方案:给目标用户一套高价值的解决方案,什么是高价值?就是既能解决用户的问题,又能恰到好处的满足用户的定位,这里有一点比较重要,并不是一味的降低成本就能满足用户的价值,作者举了一个高档餐厅跟大排档的区别,高档餐厅的菜单需要精致,配的上餐厅的基调;大排档的菜单则不需要,同样是菜单,面对的客户不一样,产品经理要给出的解决方案也不一样。
  • 确定需求排期:这点就是根据用户确定好的需求点梳理方案,并且对需求进行排期。在需求的开发过程中,可能一开始梳理的需求量是巨大的,比如你要做一个电商网站,那么卖家中心的商品管理、订单管理、库存管理就属于高优先级的功能,售后模块可以在优先级较高的功能昨晚之后再开发,这个就属于优先级。类似的还有多种支付方式,电商初期可能只支持银行卡或者余额支付,随着用户量的提升,移动支付、金融白条之类的需求也可以加上。

搭框架:功能框架、非功能框架

搭框架一般就是结构设计,如果复杂点也可以叫架构设计。把用户不同的功能组合起来,形成一套框架,这点类似于建房子的CAD图纸。比如这套房子预估入住人数为一家三代6口人,就有了以下的结构:

  • 爷爷奶奶:老人房;
  • 父母:卧室;
  • 子女:儿童房;
  • 公共:书房、客厅、厨房、阳台;

在书中,作者是通过用例图来进行梳理,这里我自己在梳理时,更多的喜欢用思维导图,当然这个各有所爱,工具不是问题,目的是梳理清除功能框架。有关搭框架作者介绍了三种方法:用例技术、流程驱动设计、领域驱动设计

对于非功能框架,这部分在中小系统中很少涉及,而且大部分都是研发根据经验处理了。比如系统的并发、接口的响应时间、对用户输入数据的数据加密(隐私保护)等等,还有一些等保要求的需求,大多数也都是非功能性需求,这部分需要产品经理对技术有一定的了解,否则是无法准确的定义这部分需求的。但是非技术出生的产品经理也应该了解。

其实这部分作者还应该写一部分,就是需求中的产品框架该如何定义,上面作者描述了功能框架,拿作者在书中举例的银行系统来说:

image-20230914161710242

用例图清晰的描述了系统的涉众分别应该做哪些事儿,但是系统应该如何设计呢?作者并没有提到,我认为在搭框架的部分还应该把产品架构定义清晰,比如我通过作者书中的描述,我认为银行系统应该如下(简化版):

  • 系统设置:
    • 员工管理;
    • 角色管理;
  • 客户管理:所有银行的客户(储户);
  • 银行卡管理:所有客户的银行卡管理,比如银行卡的各种信息,开户资料等;
  • 基金管理:
    • 基金申购:客户线下柜台提出申购,客户经理在系统进行申购处理;
    • 基金赎回:客户线下赎回基金;

这个我称之为产品架构,有区别与功能架构,功能架构会完整的包含在产品架构中,产品架构对于多个产品共同负责一款产品是很重要的,可以通过产品架构来进行产品分工,这样团队的新人也能够独立负责一个模块。

做细节:业务流程、业务操作、信息结构

业务流程这块可以通过泳道图、流程图、状态图、时序图等多种方式来进行梳理。常用的为流程图,比如一个系统有多个涉众,从第一个流程发起者开始,一直到最后的流程结束,我们称之为业务流程。

拿最常用的电商系统来举例吧,当现在有了一个电商系统,卖家首先需要在后台去发布商品,导入库存。此时用户在前台可以看到已发布的商品,然后进行下单、支付。支付完成之后卖家需要进行发货,发货之后需要通知仓库进行打包,然后通知快递员上门揽件,快递揽件之后进入快递过程,最终用户收到货物,并确认收货,电商平台此时需要把货款支付给卖家。这样一个完整的电商流程就结束了。

这个全流程我们称之为业务流程;在这个流程中有许多涉众、有卖家、买家、库管员、快递员,他们在这个系统中的操作就称之为业务操作;针对商品信息、卖家信息、仓库信息则可以用信息结构来表示,比如商品有规格、价格、属性等多种属性;

当然我上面举的例子只是为了简化说明,实际在电商系统中还有各种复杂的流程,比如出入库的流程、下单的流程、商品发布的流程、售后退款的流程等等,如果产品经理在画图时发现流程过长,在梳理总流程时可以将颗粒度放大,从而梳理出总的流程。在具体的业务流程中再单独细化。

业务操作一般用状态图或用例图来表示,举例就是电商的订单状态,我们简单的设计为以下:

状态 卖家操作 买家操作
待付款 取消订单、修改订单 取消订单、付款、修改订单
待发货 发货 售后
待收货 确认收货
已完成

就是不同状态的订单在卖家跟买家端有不同的操作,用状态图非常好表示这个关系。

画界面:交互设计、信息设计

画界面属于产品经理工作最繁琐也最细节的一环了,产品经理需要根据产品架构来确定页面上的字段参数。这一章我感觉作者写的也比较模糊,首先在大多数公司,这块的工作至少分了两个岗位(产品经理,UI设计师),产品一般只需要根据产品架构图出线框图即可,然后UI设计师根据线框图输出UI。至于其中的交互设计,在没有UE(交互设计师)的情况下,由产品经理跟UI共同负责。

举个例子:经常点外卖的知道外卖添加到购物车的时候会有一个动效,这就属于交互的一部分,产品经理很少会通过axure或者墨刀把这种交互做出来,只能做一些左滑右滑,单击双击之类的。

有关交互设计,在我的产品经历中,我更喜欢用框架,比如早些年的bootstrap,然后后来的ant design,elementUI,小程序的UNI等等,产品经理应该多看这些框架的交互设计,从而提升自己的设计经验。

信息设计我一般习惯用用例图来查漏补缺,一个页面比如商品管理,用例就有:发布商品、下架商品、上架商品、删除、编辑、价格调整等等;每一个用例都是一个独立的功能,比如发布需要用到发布页面,下架可能是一个弹窗等等。

信息设计还有一个比较重要的就是字段:页面上需要展示什么字段,研发就需要对应的在数据库建表,并且每个字段需要明确的标注字段的来源、是否必填、上下限等。

字段 是否必填 长度 类型 默认值 备注
预售日期 18 datetime 当前日期 字段的备注说明

在对字段进行描述时,一定要深入思考,当然,这部分很多产品经理不知道字段的类型有哪些,基本上只需要了解str(字符串),int(整数),decimal(小数)就足够了,感兴趣的可以自行网上搜索学习下字段的类型还有哪些?研发也需要通过这个文档来进行表结构的建立。下图为数据库的表结构示例。

image-20230915111607092

拓展篇:应用和思考业务设计

拓展篇更多的是对前面的一些内容的扩展,在第二部分梳理解决方案的时候其实就已经要开始业务调研、业务分析与设计了,作者在这部分扩展讲解了一些业务调研、用户访谈、竞品分析的方法,将的比较浅,所以这部分我只粗度了下,没有深入。比如我自己在做业务分析跟调研时,经常会想到找开源的同类产品,然后自己搭建一套完整的产品,从功能到数据表结构去进行分析。

后面的设计模型、UML、用例和用户故事这块基本上就是浅浅的带过了,如果想更深入的了解设计模型还是建议找专业的书籍来进行阅读,UML我推荐《火球UML大战需求分析》,懂技术的可以去plantuml官网学习。

后记

整本书读完感觉能打个6分吧,对于初级产品、中级产品而言本书还是值得一读,算是一种产品方法论。但是所有产品的书几乎也都有一个通病,就是基本上都是把产品要做的工作从头到尾给你走一遍,广度够了,但是深度不够。

4

评论区