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

　　在程序猿眼里，产品经理就是需求生成器，各种各样的点子都会从产品经理强大的脑洞中生成。这些点子最终会变成需求，交付给程序猿实现。然而产品狗和程序猿毕竟是两个物种，如何让程序猿能完全同步产品经理的脑洞，这的确是个技术活。但是产品经理如果能了解程序猿的思维方式，想必可以再一定程度上弥补「种族差异」带来的交流困难！今天，咱们就用「状态机」来开个篇，说说按照程序猿的思维方式是怎么理解和管理状态的。
　　「状态机」是什么
　　一般说来，状态机是用来描述一个事物多个状态之间相互切换关系的数学模型，可以用图表或者图形来描述一个状态机。
　　用图表描述状态机
　　用图形描述状态机
　　很明显，使用「有向图」描述的状态机更直观，更能让人理解。
　　「状态机」中的要素
　　现态：状态机描述事物当前所处的状态
　　次态：现态达到一定条件，并触发相应动作后能够达到的状态
　　条件：执行动作的前提
　　动作：当条件满足后，触发状态机状态改变
　　当「现态」满足指定「条件」，并触发相应「动作」后，会进入一个指定的「次态」。状态改变后，「次态」就会变成新的「现态」。
　　举个栗子
　　叨逼叨说了这么多概念性的东西，可能大家已经成功被我带到坑里了。不要紧，咱们马上来个具体的例子，看看「状态机」到底如何使用。
　　以打电话的过程举例，整个过程中可能存在以下几个状态：「待机」、「振铃」、「通话」、「停机提示」等几个状态，如果我们要用自然语言描述这些状态的转换关系，可能需要费一些口舌，但是如果用下面的「状态机」来描述，是不是就一目了然了？
　　产品经理如何利用状态机
　　经过上面对「状态机」的介绍，可以发现「状态机」相对自然语言来说，对描述一些多状态切换的场景有很大的优势。它不仅可以简洁清晰的描述出一些复杂状态间的转换条件，而且也很难产生歧义。如果新需求的交互涉及到多种状态的切换，又担心程序猿在实现时会遗漏一些关键路径，不妨试试「状态机」的图形化描述方式，说不定有奇效哦。
　　最后，再提供大家一个「状态机」的例子做参考，这个例子的名字叫「一个程序猿的日常」。