如何绘画状态机来描述业务的变化

不懂技术怎么做产品?15天在线学习,补齐产品经理必备技术知识,再也不被开发忽悠。了解一下>

对于设计过商品、订单、优惠券等复杂功能的PM来说,会发现很难描述清楚功能的本质。因为技术会反复的问,有几种状态啊,怎么转移啊,啥时候转移啊,什么时候截止状态啊,系统根据什么条件判断状态啊……

一、为什么需要使用状态机?

讲个亲身的例子,去年我设计电商系统的订单模块,就犯过类似的问题。

  • 一开始参照淘宝的订单系统,将订单设计为待付款、已付款、已发货、已完成,已关闭等5个状态。
  • 上线后很快就发现有问题。付款之后直接传给仓库那边发货,导致很多订单信息明明有误,但是来不及修改。用户下单
  • 之后想改地址改商品,而发货信息已经传给网仓了很难修改。
  • 然后我们不得不新增了一个中间状态“已确认”,让客服审核无误后,再传给网仓走发货流程。
  • 再后来我们发现除了主业务-下单购物之外,还需要兼顾支线业务-退款退货,此时不得不需要引入“退款中”状态并且增加退款子状态机、退货子状态机。

以上这些我最开始是用文字描述,然后加上凭感觉画的流程图来表示,服务端RD很难理解,并且无法清楚所有状态以及转移条件,不得不多次反复确认。

后来去搜索相关的资料,好好研究了一下状态机这个概念,才发现其实用一张图就可以表述清楚以上的一切。

接下来,我就来讲讲我对状态机的理解和认识,希望对大家有点帮助。

二、状态机的来源?

最早是电路设计领域里面的概念,具体来说是一种根据电路信号按照预先设定的状态进行转移,协调相关信号动作并完成特定操作的控制硬件。

后来软件编程里面继承了这种思想,用来表示有限多个状态以及在这些状态之间转移和动作的模型。简称为FSM(Finite State Machine),是常见的软件设计模式之一。

对于PM来说,借鉴这种思想并融入到自己的产品思维中是很有必要的。据此设计业务实体的功能会更容易阐述本质,并且让技术更容易理解。

三、状态机是什么?

从PM的角度可以这样定义,状态机用来表示业务实体的全部状态以及相互间如何转移。

其中,业务实体是指客观上可以相互区分的事物,比如订单、优惠券、商品、活动……

当然扯远一点,大部分对象都是有状态的概念,只是没必要都画个状态机图。

3.1 状态机的描述方法

文字是最古老的方式,繁琐并且不容易理解。
另外表格也可以描述,不够形象,理解较慢。
我认为图形最佳,仅需一些节点表示状态然后用有向线条连接。

3.2 常见的状态机

举一些例子让大家对状态机图有个基本的认知。

(1)灯泡状态机

小时候第一堂物理课讲解的电灯开关其实就是最简单的状态机。

(2)订单状态机

这个网购过的朋友应该都接触过,借鉴自淘宝。

3.3 状态机的要素

从状态机的内在因果关系可以抽象出3大要素:

  • 现态:是指当前所处的状态。
  • 条件:系统按照某一规则或者用户执行某个动作后,,状态会进行迁移。
  • 次态:条件满足后迁移到的新状态。

包含1个开始状态和N个终止状态,以及若干个中间状态。当到达终态, 状态机停止。

注意:有些工程师会把条件和动作分成2种要素,感觉不是特别恰当。因为动作本身就是条件的一种。

四、怎么画状态机?

我习惯使用Axure,以它来讲解怎么表示,其他工具方法类似。

4.1 要素怎么表示

“状态”使用圆角矩形表示。

“条件”使用有向线条上的文字表示,比如系统怎么样,或者用户执行xx动作。

线条的方向表示状态迁移。

一般情况下从左向右的画图顺序表示了初始→终止的方向,所以无需单独表示。复杂情况下可以用实心黑圆点初始状态,用实心黑圆点外包一个圆圈表示终止状态。

4.2 要素如何命名

状态建议以”已+动词”的结构来命名,比如已付款、已发货。

条件建议以”动作+结果”的动宾结构或者”表达式”来命名,以明确状态迁移的具体条件。比如支付失败、下单时间>72小时。

注意命名一般站在用户立场,尽量命名标准化。

4.3 画出状态机

  • 理解业务实体有多少种状态
  • 考虑每一个状态因为什么条件而变化
  • 将状态和状态之间用条件有向连接
  • 形成状态机图
  • 和服务端RD讨论并确定

4.4 画图注意点

不需要的状态尽量去除,让状态机结构最简单。

明确只有一个初始状态,终止状态可能有多个。

合理实现各个状态之间的切换。

方便扩展,状态有可能会增加,有可能会有子状态机。

注意不要遗漏状态,比如优惠券使用的状态机可能需要“使用中”

不要搞混动作和状态的区别,命名本身就不一样。而本质上动作是不稳定的,一旦执行完毕就结束了;而状态是稳定的,只要没有外部条件触发。

4.5 延展一下多维状态机

刚刚这2个例子是最简单的状态结构。只有一级,只有一维。

比如退款退货是订单的逆向流程,形成了多个维度的状态机。

​4.6 状态机图和流程图的区别

经常有人把状态机图给错认为是流程图的一种,其实他们本质不一样。

目的不一样,流程图表示的是流程,状态机图表示的是业务实体的状态变化。

另外,流程图中的节点一般是动作,而状态机图的节点是状态。

准确来说,状态机图是UML语言中的一种。

五、总结

不是所有的业务实体都有必要产出状态机图,关键的建议产出。

最后留2个思考,可以一起讨论下:

  1. 京东小程序的首页,有个领券功能,试问它的状态机有几个,分别怎么画,是否有其他设计问题。
  2. 电商领域中优惠券功能模块有几个业务实体,分别画出状态机图。

#专栏作家#

作者:浪子,人人都是产品经理专栏作家,业务型产品经理,3年社交+4年电商的工作经验,个人公众号:langzisay。

本文由 @浪子 原创发布于人人都是产品经理。未经许可,禁止转载。

给作者打赏,鼓励TA抓紧创作!
4人打赏
评论
欢迎留言讨论~!
  1. 赞!看完这么多文章就你的文章最详细易懂,感谢分享!另外能不能解答一下最后两个思考呢

    回复
  2. 赞一个!遇到多、复杂状态的时候确实应该用状态机来描述逻辑,比文字强太多!

    回复
  3. sku是否全退是啥意思

    回复
    1. 举例:买了两部手机,退了其中一部。

      回复
    2. 准确来说,应该是买了一部iPhone8一部iPhoneX,退了其中一部。(这2者是不同的SKU商品)

      回复
  4. 有两个子状态机不太理解,按照流程不是应该先买家申请退货,然后确定退回sku个数,然后卖家确定后才能收到退款吗

    回复
  5. UML里面不是有个叫状态图的吗?怎么弄出个状态机的概念了

    回复
    1. 是一个东西,只是画法有点区别。

      回复
  6. 感觉状态机图也能画出状态和流程的结合体了,那还有流程图的必要吗?

    回复
    1. 状态机和一般的流程图区别还是很大的,结合起来会搞得很混乱。根本没办法把状态和流程讲得清楚。

      回复
  7. 好棒!简单易懂!想请问一下作者,关于状态机有没有可以推荐的书籍或专栏?

    回复
    1. 建议搜状态机的文章看,书籍里面重点讲解状态机的只有uml书籍,比如火球大战uml分析,软件方法上之类的。

      回复
  8. axure的flow里没有开始结束状态的圆圈 :sad:

    回复
    1. 自制,so easy。

      回复
  9. 状态机,不错的机

    回复
  10. 好吧,当年都用rose画状态图,中间用visio,现在用axure简单画

    回复
    1. 从工具的角度来看,越来越不专业了。
      好奇什么原因?

      回复
    2. 效率一个比一个高。

      回复
    3. 嗯,算是一个原因。

      回复
  11. UML里面有种叫时序图,可以表达出事件影响状态的变化

    回复
    1. 嗯啊,感觉比活动图更适合表现具体的业务流程。
      不过当下敏捷横行,基本上都不画比较规范的时序图了。

      回复
  12. 回复
  13. 最近也了解了状态机的问题,诸位也可以去看看层次状态机

    回复
    1. 求个层次状态机在消费领域APP的实际场景。

      回复
  14. 状态泳道加动作节点

    回复
    1. 状态机没有泳道的概念啊,完全是不同的分析角度和对象

      回复
    2. 小白问个问题,求轻喷。。把你这个状态机加上各个状态不是就变成泳道图了?这个和业务流程图有什么区别?随着业务的流动,状态也有相应的改变,怎么去区分呢?

      回复
    3. 1、状态机图描述的是状态的变化。泳道图一般描述的是功能的具体步骤,一个是status,一个是action,本质不一样。
      2、这个是偏功能层面的,和业务流程图是2个维度的。你可以看下我最新的文章。

      回复
    4. 泳道图方框里是“动作”,状态机连线上是“动作”

      回复
  15. 挺好

    回复