经理|产品经理必会之状态机设计( 二 )

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

文章插图
以上这个状态机的流转图，是不是已经看得有些晕了？但，这仅仅是我一个外人揣测出来的样子，实际的状态机流转图据我所知，远比这个复杂得多。因为在这个图里，没有基于服务商的视角（比如服务商自身也可能会自发的取消、改派或者换一个司机），也几乎没有基于高德平台的视角（有感改派、无感改派、车型升级等）。所以这也是为什么状态机的梳理对于产品经理的逻辑性要求非常高的原因，业务场景太复杂了，逻辑性不够严谨的话，肯定被那么多的内容被搞晕。
说完了状态机设计的2大要点，我们再一起来看看，状态机设计中所面临的挑战是什么。
挑战一、状态机发生了缺失、状态跳跃如何处理
还是以高德打车为例，大量的状态都是需要依赖下游的网约车服务商来完成的，比如接单、到达。这个时候由于技术等问题，很有可能出现还没达到，行程已经开始了。这个时候，在设计状态机时，就需要明确强依赖（只有A状态，才能跃迁至B状态）与弱依赖（无论什么状态都可以跃迁至B状态），以及明确状态机回补（A状态缺失时，如何补一个A状态回去）的策略。
挑战二、对于过于繁杂的状态机，如何进行有效的的管理与迭代在一个异常复杂的业务场景中，会出现状态机多到无法单独依靠一个人来梳理和负责的程度（高德打车就是），这个时候，就需要对状态机进行领域划分来管理。比如以高德打车为例，就可以简单划分为行前、行中、行后，来分别管理状态机。
挑战三、不同的业务场景，对同一套状态机的要求不同时，如何快速响应业务变化（即不能每上一个新业务就要对状态机做开发迭代）
比如还是说高德打车，日常的打车和接送机显然在业务上具备显著的差异性，这个时候，如何在同一套状态机的基础上快速响应各种业务变化呢？这个时候就需要引入一个叫流程编排的概念了，即状态机的跃迁不是一成不变的，而是基于不同的条件（业务场景）可以进行灵活的编排，这个话题以后有机会可以单独开一篇文章来写，有兴趣的同学可以先行自己查阅相关资料。
最后，再把今天文章涉及的核心内容给大家汇总一下。
1、状态机（又叫有限状态机），英文为FSM（Finite State Machine），具体定义为：在当前状态下，输入一个命令，然后根据业务规则触发相应的工作，最后完成一次状态的迁移。
2、状态机的设计，需要遵循<现态、事件、动作、次态>状态机四要素来完成。
3、设计状态机的第一步，叫抓住主要矛盾，即理清楚整个流程中的关键节点（关键节点就是说，少了这个节点，整个流程运转不下去了）。
4、状态机设计的第二步，叫罗列特殊业务场景，即把整个业务流程中，可能发生的所有特殊（或者需要进行运营干涉）的业务场景都罗列出来，并且要制定相应的应对措施（即发生了这种场景怎么办，比如司机取消怎么办）。
5、状态机的挑战一、状态机发生了缺失、状态跳跃如何处理。
6、状态机的挑战二、对于过于繁杂的状态机，如何进行有效的管理与迭代。
7、状态机的挑战三、不同的业务场景，对同一套状态机的要求不同时，如何快速响应业务变化（即不能每上一个新业务就要对状态机做开发迭代）。
作者：超级大头，8年+各类中后台产品设计经验，个人公众号：产品经理两三事。