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

如何绘画状态机来描述业务的变化 　　对于设计过商品、订单、优惠券等复杂功能的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个例子是最简单的状态结构。