理清楚状态机，也将理清楚产品的业务逻辑

从上面的图我们可以看到这是订单的业务状态流转图。

这里有一个起始状态，就是待付款，这是在用户下单后形成的。然后有三个结束状态，已取消、已完成和已评价。

为什么已完成也是结束状态，是因为用户评价不是必要的环节。

这里我们就得到了状态机的第一个关键要素：状态机由若干个不重叠的状态组成，状态机中至少有一个起始状态和一个结束状态。

然后我们也会看到，状态和状态之间是通过一条单向的线条连接的，这里引出了状态机的一个特征：状态机是有个有向图。最后，线条上注明了一个动作，这是促发状态改变的动作，也就是状态的改变是由外部的动作促发的。

结合上面的例子，我们就得到了状态机的定义：状态机是一个有向图形，由一组状态和一组相应的动作组成。状态机通过响应一系列动作而运行。

03 如何在产品设计中使用状态机

了解到状态机的定义，我们来看看如何在产品设计中使用它。这里分下面几个步骤：

1. 列举某个业务对象的状态，这里需要使用 MECE 原则，即穷尽而不重复，将业务对象的所有状态都列举出来。比如上面的订单状态图，其实我们就遗漏了已退款、部分退款这两个状态。
2. 梳理哪些状态是起始状态，哪些状态是结束状态，以确定业务的开始和结束。
3. 确定状态直接的流转次序，并且列出促使状态流转的动作，也就是具体的业务行为。
4. 确定每个具体业务行为需要提交的数据和产生的数据，即业务行为的输入输出。

实际简化出来就是“定状态、理流程、明数据”三个要点。我们再举一个我们产品开发的任务管理的例子。对于产品开发任某个需求点，通常会经过需求评审到上线的过程。我们按照上面的步骤进行一下状态机的分析：

1. 状态列举：整个过程有待评审、被驳回、待开发、开发中、待测试、待验收、已上线7个状态。
2. 待评审属于起始状态，被驳回、已上线属于结束状态。
3. 状态的流转图如下：

每个业务行为的输入输出如下表所示。

04 状态机与流程图的区别

我们看上面的产品开发的任务管理状态机图其实并不是特别合理，我们可以看到不同的状态的流转其实的业务动作是一样的，比如评审不通过和通过实际上的行为应该是评审。

之所以会出现这个情况，是因为实际上这里揉和了多个业务对象：需求、开发任务、测试任务等等。

这种需要描述多个对象的状态机的情况，那么应该结合流程图来做，如下图所示。

这种方式可以将业务对象的状态变化和业务流程串联起来，会更好地知道哪些状态受关联的业务环节影响，比如需求的开发中状态就依赖开发任务的确认开始动作。

可以看到，状态机和流程图某些方面是类似的，都是用来描述业务流转，但是二者也存在明显的不同，状态机更关注的业务环节中某个对象自身的状态变化，而流程图更适合描述整个业务的环节的不同行为如何衔接各个业务对象。

也就是，状态机关注的范围相对会更小一些。

如果一个业务对象的状态流转无法通过作用于自身的业务行为表示，就可以引入相关业务对象的状态机和流程图来共同绘图表示。

由于同时绘制多个业务对象的状态机图可能会很复杂，因此建议将主路径用强调出来，这样可以很清晰地知道主流程如何流转。

05 总结

本篇介绍了状态机在产品设计中的应用，通过状态机可以很好地梳理单个业务对象业务状态如何流转。同时，对于多个关联的业务对象，也可以实用状态机和流程图结合的方式，梳理业务环节上的多个业务对象的状态流转以及他们之间如何相互影响。

实际我们产品设计过程中就可以采取“定状态、理流程、明数据”的方式去梳理业务。

作者：产品海豚湾；公众号：产品海豚湾（ID：pm-dophin-bay）

本文作者@产品海豚湾 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！