产品经理应该这样提需求之“状态机”

在程序猿眼里，产品经理就是需求生成器，各种各样的点子都会从产品经理强大的脑洞中生成。这些点子最终会变成需求，交付给程序猿实现。然而产品狗和程序猿毕竟是两个物种，如何让程序猿能完全同步产品经理的脑洞，这的确是个技术活。但是产品经理如果能了解程序猿的思维方式，想必可以再一定程度上弥补「种族差异」带来的交流困难！今天，咱们就用「状态机」来开个篇，说说按照程序猿的思维方式是怎么理解和管理状态的。

「状态机」是什么

一般说来，状态机是用来描述一个事物多个状态之间相互切换关系的数学模型，可以用图表或者图形来描述一个状态机。

用图表描述状态机

用图形描述状态机

很明显，使用「有向图」描述的状态机更直观，更能让人理解。

「状态机」中的要素

1. 现态：状态机描述事物当前所处的状态
2. 次态：现态达到一定条件，并触发相应动作后能够达到的状态
3. 条件：执行动作的前提
4. 动作：当条件满足后，触发状态机状态改变

当「现态」满足指定「条件」，并触发相应「动作」后，会进入一个指定的「次态」。状态改变后，「次态」就会变成新的「现态」。

举个栗子

叨逼叨说了这么多概念性的东西，可能大家已经成功被我带到坑里了。不要紧，咱们马上来个具体的例子，看看「状态机」到底如何使用。

以打电话的过程举例，整个过程中可能存在以下几个状态：「待机」、「振铃」、「通话」、「停机提示」等几个状态，如果我们要用自然语言描述这些状态的转换关系，可能需要费一些口舌，但是如果用下面的「状态机」来描述，是不是就一目了然了？

产品经理如何利用状态机

经过上面对「状态机」的介绍，可以发现「状态机」相对自然语言来说，对描述一些多状态切换的场景有很大的优势。它不仅可以简洁清晰的描述出一些复杂状态间的转换条件，而且也很难产生歧义。如果新需求的交互涉及到多种状态的切换，又担心程序猿在实现时会遗漏一些关键路径，不妨试试「状态机」的图形化描述方式，说不定有奇效哦。

最后，再提供大家一个「状态机」的例子做参考，这个例子的名字叫「一个程序猿的日常」。

本文所说的「状态机」都是指「有限状态机」（FSM）。另外还有一种进阶版的「层次状态机」。如果有兴趣的话可以自行搜索。

#专栏作家#

给产品经理讲技术，微信公众号（pm_teacher），人人都是产品经理专栏作家。资深程序猿，专注客户端开发若干年，对前端、后台技术略懂，热衷于对新的科技领域的探索。

本文原创发布于人人都是产品经理，未经许可，不得转载。