导读：状态机（又叫有限状态机），英文为FSM（Finite State Machine），具体定义为：在当前状态下，输入一个命令，然后根据业务规则触发相应的工作，最后完成一次状态的迁移。本文作者围绕状态机设计，以高德打车为例，对其展开分析，希望对你有帮助。

从一个真实的产品学习一个产品知识点！

今天想来和大家一起探讨一下关于产品的状态机设计。状态机是绝大多数产品都会遇到的一个设计要素，甚至是核心要素之一，可以说如果你掌握了状态机，那么你就掌握了这个产品的大体框架了。

首先来看一下状态机（又叫有限状态机），英文为FSM（Finite State Machine），具体定义为：在当前状态下，输入一个命令，然后根据业务规则触发相应的工作，最后完成一次状态的迁移。

状态机的设计，需要遵循<现态、事件、动作、次态>状态机四要素来完成。

在这4个要素变化中需要注意，动作完成后，状态机不一定会发生跃迁，比如支付失败就依旧是待支付的状态。

以下是一个非常简单的订单状态机流转图，上半部分是动作，括号中是状态机。

产品中状态机的设计，极度考验一个产品经理的逻辑严谨性以及他对于业务认知的深度。缺乏严谨性，设计出来的状态机四要素的转变可能存在遗漏、而对于业务认知深度不够，状态机可能缺乏对于业务全场景的覆盖。

下面就以我最近一直使用的高德打车，来猜测一下整个高德打车状态机的设计方式。也请在看文章的小伙伴们，可以自己先揣测一下高德打车的状态机是如何设计的。

首先，我们需要明白高德打车是一个面向乘客的聚合打车平台（不是滴滴的自营模式），它联合了百余家各地的网约车（如T3、享道、曹操等）及出租车公司为用户提供一键全网叫车的服务。

简单的从整个叫车到支付完成的过程来看，我们大致可以揣测出用户通过高德平台叫车可以进行比价勾选倾向的车型和服务商，叫车请求发出后，首先会生成一个主单，然后向各个服务商发起下单请求，服务商的司机应答后再由高德为乘客选出性价比最高的车辆，然后开始进行乘车服务。

设计状态机的第一步，叫抓住主要矛盾，即理清楚整个流程中的关键节点（关键节点就是说，少了这个节点，整个流程运转不下去了）。

从上面的流程中可以推断中，打车服务的关键节点有：乘客下单、司机和乘客撮合、服务商司机接单、司机与乘客绑定、司机到达上车点、开始行程、形成结束、支付完成。那么这些关键节点，就构成了如下的状态机流转方式。

如上图所表达的那样，理想的状态机应该是线性的，非跳跃的，无环的，但实际状况永远要比理想复杂很多。在高德这种多方参与且约束力较弱的业务场景中，实际发生的特殊（异常）状况可以说是司空见惯了。就罗列一下我个人所遇到过的各种特殊状况：乘客取消、司机取消、修改地址、司机不来接客、增加服务商、司机拉黑名单、平台进行司乘撮合等等。

这里就会牵扯到状态机设计的第二步，叫罗列特殊业务场景，即把整个业务流程中，可能发生的所有特殊（或者需要进行运营干涉）的业务场景都罗列出来，并且要制定相应的应对措施（即发生了这种场景怎么办，比如司机取消怎么办）。在这一点上，非常考验产品经理对于整个行业的理解和对于自己公司业务的理解，所以前面说设计状态机需要对业务理解有足够的深度！

我们一起来看一下，当我们把上面我所遇到过的特殊情况都整理到整个状态机的图中之后，状态机的流转会变成一个什么样子。

以上这个状态机的流转图，是不是已经看得有些晕了？但，这仅仅是我一个外人揣测出来的样子，实际的状态机流转图据我所知，远比这个复杂得多。因为在这个图里，没有基于服务商的视角（比如服务商自身也可能会自发的取消、改派或者换一个司机），也几乎没有基于高德平台的视角（有感改派、无感改派、车型升级等）。所以这也是为什么状态机的梳理对于产品经理的逻辑性要求非常高的原因，业务场景太复杂了，逻辑性不够严谨的话，肯定被那么多的内容被搞晕。

说完了状态机设计的2大要点，我们再一起来看看，状态机设计中所面临的挑战是什么。

挑战一、状态机发生了缺失、状态跳跃如何处理

还是以高德打车为例，大量的状态都是需要依赖下游的网约车服务商来完成的，比如接单、到达。这个时候由于技术等问题，很有可能出现还没达到，行程已经开始了。这个时候，在设计状态机时，就需要明确强依赖（只有A状态，才能跃迁至B状态）与弱依赖（无论什么状态都可以跃迁至B状态），以及明确状态机回补（A状态缺失时，如何补一个A状态回去）的策略。

挑战二、对于过于繁杂的状态机，如何进行有效的的管理与迭代在一个异常复杂的业务场景中，会出现状态机多到无法单独依靠一个人来梳理和负责的程度（高德打车就是），这个时候，就需要对状态机进行领域划分来管理。比如以高德打车为例，就可以简单划分为行前、行中、行后，来分别管理状态机。

挑战三、不同的业务场景，对同一套状态机的要求不同时，如何快速响应业务变化（即不能每上一个新业务就要对状态机做开发迭代）

比如还是说高德打车，日常的打车和接送机显然在业务上具备显著的差异性，这个时候，如何在同一套状态机的基础上快速响应各种业务变化呢？这个时候就需要引入一个叫流程编排的概念了，即状态机的跃迁不是一成不变的，而是基于不同的条件（业务场景）可以进行灵活的编排，这个话题以后有机会可以单独开一篇文章来写，有兴趣的同学可以先行自己查阅相关资料。

最后，再把今天文章涉及的核心内容给大家汇总一下。

1、状态机（又叫有限状态机），英文为FSM（Finite State Machine），具体定义为：在当前状态下，输入一个命令，然后根据业务规则触发相应的工作，最后完成一次状态的迁移。

2、状态机的设计，需要遵循<现态、事件、动作、次态>状态机四要素来完成。

3、设计状态机的第一步，叫抓住主要矛盾，即理清楚整个流程中的关键节点（关键节点就是说，少了这个节点，整个流程运转不下去了）。

4、状态机设计的第二步，叫罗列特殊业务场景，即把整个业务流程中，可能发生的所有特殊（或者需要进行运营干涉）的业务场景都罗列出来，并且要制定相应的应对措施（即发生了这种场景怎么办，比如司机取消怎么办）。

5、状态机的挑战一、状态机发生了缺失、状态跳跃如何处理。

6、状态机的挑战二、对于过于繁杂的状态机，如何进行有效的管理与迭代。

7、状态机的挑战三、不同的业务场景，对同一套状态机的要求不同时，如何快速响应业务变化（即不能每上一个新业务就要对状态机做开发迭代）。