经理|产品经理必会之状态机设计新笔|twitter|品牌|用户|注意力

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

文章插图
从一个真实的产品学习一个产品知识点！
今天想来和大家一起探讨一下关于产品的状态机设计。状态机是绝大多数产品都会遇到的一个设计要素，甚至是核心要素之一，可以说如果你掌握了状态机，那么你就掌握了这个产品的大体框架了。
首先来看一下状态机（又叫有限状态机），英文为FSM（Finite State Machine），具体定义为：在当前状态下，输入一个命令，然后根据业务规则触发相应的工作，最后完成一次状态的迁移。
状态机的设计，需要遵循<现态、事件、动作、次态>状态机四要素来完成。

文章插图
在这4个要素变化中需要注意，动作完成后，状态机不一定会发生跃迁，比如支付失败就依旧是待支付的状态。
以下是一个非常简单的订单状态机流转图，上半部分是动作，括号中是状态机。

文章插图
产品中状态机的设计，极度考验一个产品经理的逻辑严谨性以及他对于业务认知的深度。缺乏严谨性，设计出来的状态机四要素的转变可能存在遗漏、而对于业务认知深度不够，状态机可能缺乏对于业务全场景的覆盖。
下面就以我最近一直使用的高德打车，来猜测一下整个高德打车状态机的设计方式。也请在看文章的小伙伴们，可以自己先揣测一下高德打车的状态机是如何设计的。
首先，我们需要明白高德打车是一个面向乘客的聚合打车平台（不是滴滴的自营模式），它联合了百余家各地的网约车（如T3、享道、曹操等）及出租车公司为用户提供一键全网叫车的服务。

文章插图
简单的从整个叫车到支付完成的过程来看，我们大致可以揣测出用户通过高德平台叫车可以进行比价勾选倾向的车型和服务商，叫车请求发出后，首先会生成一个主单，然后向各个服务商发起下单请求，服务商的司机应答后再由高德为乘客选出性价比最高的车辆，然后开始进行乘车服务。
【 经理|产品经理必会之状态机设计】设计状态机的第一步，叫抓住主要矛盾，即理清楚整个流程中的关键节点（关键节点就是说，少了这个节点，整个流程运转不下去了）。
从上面的流程中可以推断中，打车服务的关键节点有：乘客下单、司机和乘客撮合、服务商司机接单、司机与乘客绑定、司机到达上车点、开始行程、形成结束、支付完成。那么这些关键节点，就构成了如下的状态机流转方式。

文章插图
如上图所表达的那样，理想的状态机应该是线性的，非跳跃的，无环的，但实际状况永远要比理想复杂很多。在高德这种多方参与且约束力较弱的业务场景中，实际发生的特殊（异常）状况可以说是司空见惯了。就罗列一下我个人所遇到过的各种特殊状况：乘客取消、司机取消、修改地址、司机不来接客、增加服务商、司机拉黑名单、平台进行司乘撮合等等。
这里就会牵扯到状态机设计的第二步，叫罗列特殊业务场景，即把整个业务流程中，可能发生的所有特殊（或者需要进行运营干涉）的业务场景都罗列出来，并且要制定相应的应对措施（即发生了这种场景怎么办，比如司机取消怎么办）。在这一点上，非常考验产品经理对于整个行业的理解和对于自己公司业务的理解，所以前面说设计状态机需要对业务理解有足够的深度！
我们一起来看一下，当我们把上面我所遇到过的特殊情况都整理到整个状态机的图中之后，状态机的流转会变成一个什么样子。

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