产品经理的图形化表达：状态机
状态机在产品设计中十分重要，尤其是业务状态的流转。状态机由不重叠的状态组成，包括起始状态和结束状态，状态之间的转换由特定的输入条件触发，且状态的终止条件通常是下一个状态的输入条件。此外，状态设计需遵循完整连贯、唯一性、区分视角、统一规则、粒度适中、通俗易懂及与业务流同向等原则，确保状态设计合理有效。
基础知识
前言
产品的业务功能设计基本上都离不开业务状态的流转，比如订单状态会有：待付款、待发货（已付款）、已发货、已完成、已评价、已取消等等状态。随着业务的推进，一个业务对象会从一个状态转变到另一个状态，这种状态的流转就是状态机（State Machine），状态流程在产品设计中非常重要，如果梳理清楚了业务的状态及其流转条件，那么整个产品的业务逻辑就会非常清晰。
状态流程：
将一个对象各个状态按时间线串联起来，得到的就是这个对象的状态流程。
状态机的定义和状态三要素
什么是状态机
我们先来看下面的订单状态机图，然后再来讲状态机的具体定义。
从上面的图我们可以看到这是订单的业务状态流转图。这里有一个起始状态，就是待付款，这是在用户下单后形成的。然后有三个结束状态，已取消、已完成和已评价。为什么已完成也是结束状态，是因为用户评价不是必要的环节。这里我们就得到了状态机的第一个关键要素：状态机由若干个不重叠的状态组成，状态机中至少有一个起始状态和一个结束状态。
然后我们也会看到，状态和状态之间是通过一条单向的线条连接的，这里引出了状态机的一个特征：状态机是有个有向图。最后，线条上注明了一个动作，这是促发状态改变的动作，也就是状态的改变是由外部的动作促发的。
结合上面的例子，我们就得到了状态机的定义：
状态机是一个有向图形，由一组状态和一组相应的动作组成。状态机通过响应一系列动作而运行。
结合上面的例子，我们同样就得到了状态的三个要素：
状态是由输入条件、状态描述、终止条件三个要素组成。
- 输入条件：输入条件是进入这个状态的触发开关，当条件被满足，就会执行一次状态的迁移，即进入此状态。如上图中，“用户付款成功”后，商品就会进入【待发货】状态，“用户付款成功”就是【待发货】的输入条件。
- 状态内容：即这个状态是什么。
- 终止条件：终止条件是这个状态结束的开关，当条件满足时，此状态就会终止。如上图中的“商家发货”，就是【待发货】状态的终止条件。上一状态的终止条件，是下一状态的输入条件，例如下图中“商家发货”是【待发货】的终止条件，是下一状态【待收货】的输入条件。
无论是输入条件还是终止条件，都包含手动和自动两种：
- 手动：即需要用户手动触发，如“商家发货”，就需要商家手动点击“发货”按钮，或输入发货单号并手动提交成功，系统才可判断商品终止了【待发货】状态，进入【待收货】；
- 自动：即无需用户手动操作，系统根据已设置好的规则，当规则满足后，自动执行状态迁移。
这两种类型的条件可同时存在，也可只存在其中一种。如商品从【待收货】流转到【待评价】状态，既可手动触发，又有自动触发机制：
- 手动：用户主动点击“确认收货”按钮；
- 自动：从状态流转到【待收货】起开始计算，10天后，系统会自动确认收货，状态变更为【待评价】。
我们在设计状态流转时，会尽量减少需要用户手动触发的条件，改为自动触发，但很多时候系统无法做到完全自动，有些环节只能通过用户操作来完成。
然而，众所周知，用户都是懒的，用户都是上帝，我们无法强迫每个用户按照我们的要求去做，只要有需要手动触发的条件，就一定会有用户不主动做，这就会导致后续流程无法继续进行，所以对于状态流转比较重要的节点，我们大多会采用手动为主，自动为辅的原则，即预留一定的时间等待用户手动操作，当即将到达这个时间时，给予一定的预警提示，如若用户仍不操作，则在到达时间后由系统自动向更为常见的方向执行。
状态设计原则
完整连贯
一个对象的状态是贯穿这个对象整个生命周期的，前后两个状态是紧密衔接的，中间不应出现任何真空时期。
唯一性
唯一性是指一个对象在一个时间点只有一个状态，不会同时存在多种同级状态，这是很多同学在设计时没有意识到的一点，其中有两个场景是大家容易混淆的：
父子状态：
一个对象有父子状态是比较常见的场景，例如前文提到的【待收货】，是一个比较笼统的父状态，它其实包含了【已揽件】、【运输中】、【派送中】、【待取件】多个子状态。
定义父子状态的目的，是因为有时候子状态过多，在向用户展现时不方便，这时就可以将几个相近的子状态归纳为一个父状态，并以父状态展示给用户。在这类场景中，有的同学可能就会认为这个商品订单在一个时间点同时有两个状态，但实际上商品订单是以子状态来流转的，所以订单的真实状态是子状态，父状态只是套的一层壳。
多名称：
多名称是另一个容易混淆的场景，因为有的同学会把多个名称误以为多个状态。
买家收到商品后，订单就应该从【待收货】向下一状态转移，这时我们有【已收货】、【待评价】两个名称可以用，内涵也是一样的。在这类场景中，虽然叫法不同，但其实还是同一个状态。
区分视角
虽然一个对象在一个时间点只有一个状态，但不代表只有一个名称。
在实际状态设计中，为了让不同角色的用户更好的理解一个状态的含义，有时即使是同一状态，针对不同角色用户也会使用不同名称。
统一规则
前面提到，定义状态很重要的一个作用是为了统一这个状态下对象的规则，但要想达到这一目的，就得在设计对象状态时遵守这一原则。
粒度适中
很多同学在梳理对象状态时，随着对流程的细化，会发现这些状态越理越细、越理越多，感觉这里可以加个状态，那里也可以加个状态，最后导致这一对象的状态特别多，状态流特别复杂，徒增用户理解和实现成本。我们在定义对象状态时，在满足前面原则的前提下，应尽量减少引入更多的状态，控制状态粒度。
通俗易懂
状态名称需要精炼的表达出对象当前阶段的核心进展，并容易被大家所理解，如果实在找不到合适的通俗易懂的词，就要在状态旁边做好说明。
与业务流同向
在状态的定义中，我们强调了状态描述的是业务进展，这里包含的另一层意思是状态流程其实是对业务流程的概括，状态流是在业务流程的基础上总结出来的，所以状态流程与业务流程一定是同向的，即这个对象在业务上如何流转，它的状态就会以同样的方向流转。
关联对象的状态设计
大多数情况下，能够梳理清楚业务流程和操作流程，清晰准确的定义状态三要素，那状态设计基本就不会有什么问题了。
不过在状态设计中有一类场景会稍微复杂一些——关联对象的状态关系如何处理。
这里的关联对象，是指两个流程进展上相互有影响的对象，例如父子订单，父订单的流程进展受子订单的影响。
举个具体例子：
在某个需求管理工具中，假设需求的状态流程为：
这时小明创建了一个需求，同时在这个需求基础上拆分了两个子需求，那么父子需求的状态关系应该怎么处理呢？
这里有几个常见的处理原则。
一个对象仅有一个状态
父子对象虽然在业务上有父子关系，但各自状态是完全独立的，无论是业务角度还是实现角度都是这样，即便两者可能某些状态的命名都一样，但在逻辑上必须是互相独立，所以虽然状态名称相同，但实际是不同的对象，实质是不同的。
状态关系与对象流程关系相同
既然两个对象在流程上已经相互影响了，那么状态上也会存在一定的逻辑关系，因为状态流程是建立在对象业务（或操作）流程基础上，常见的几类关系有：
1）包含关系
即一个对象在多个状态间流转时，另一对象看到的仍是一个状态。例如商品消费订单和这个商品的配送订单，就是一对父子关系，消费者看到的消费订单是【配送中】，但配送订单可能会经过【分拣中】、【运输中】等等很多状态，这就是状态的包含关系。而之所以状态是包含关系，是因为这两个流程是包含关系，商品配送流程可以看作是商品完整流程中的子流程；
2）衔接关系
即一个对象先到某个状态，另一事项才会到某个状态。例如需求要想进入【已完成】状态，需要子任务进入【已完成】，父任务才允许【已完成】；
3）完全同步
即两个对象的状态是同步的，一个对象随另一对象状态变更而变更。
那有的同学会问了，在很多需求管理工具中，虽然父子需求存在父子关系，但为什么他们的状态是完全独立，相互之间不影响呢？
这其实也是体现了这一原则，因为在这些工具的定义中，父子需求的流程上相互没有影响，所以虽然他们存在逻辑关系，但相互间状态不影响。
没有回复内容