产品经理应该这样提需求之“状态机”
在程序猿眼里,产品经理就是需求生成器,各种各样的点子都会从产品经理强大的脑洞中生成。这些点子最终会变成需求,交付给程序猿实现。然而产品狗和程序猿毕竟是两个物种,如何让程序猿能完全同步产品经理的脑洞,这的确是个技术活。但是产品经理如果能了解程序猿的思维方式,想必可以再一定程度上弥补「种族差异」带来的交流困难!今天,咱们就用「状态机」来开个篇,说说按照程序猿的思维方式是怎么理解和管理状态的。
「状态机」是什么
一般说来,状态机是用来描述一个事物多个状态之间相互切换关系的数学模型,可以用图表或者图形来描述一个状态机。
用图表描述状态机
用图形描述状态机
很明显,使用「有向图」描述的状态机更直观,更能让人理解。
「状态机」中的要素
- 现态:状态机描述事物当前所处的状态
- 次态:现态达到一定条件,并触发相应动作后能够达到的状态
- 条件:执行动作的前提
- 动作:当条件满足后,触发状态机状态改变
当「现态」满足指定「条件」,并触发相应「动作」后,会进入一个指定的「次态」。状态改变后,「次态」就会变成新的「现态」。
举个栗子
叨逼叨说了这么多概念性的东西,可能大家已经成功被我带到坑里了。不要紧,咱们马上来个具体的例子,看看「状态机」到底如何使用。
以打电话的过程举例,整个过程中可能存在以下几个状态:「待机」、「振铃」、「通话」、「停机提示」等几个状态,如果我们要用自然语言描述这些状态的转换关系,可能需要费一些口舌,但是如果用下面的「状态机」来描述,是不是就一目了然了?
产品经理如何利用状态机
经过上面对「状态机」的介绍,可以发现「状态机」相对自然语言来说,对描述一些多状态切换的场景有很大的优势。它不仅可以简洁清晰的描述出一些复杂状态间的转换条件,而且也很难产生歧义。如果新需求的交互涉及到多种状态的切换,又担心程序猿在实现时会遗漏一些关键路径,不妨试试「状态机」的图形化描述方式,说不定有奇效哦。
最后,再提供大家一个「状态机」的例子做参考,这个例子的名字叫「一个程序猿的日常」。
本文所说的「状态机」都是指「有限状态机」(FSM)。另外还有一种进阶版的「层次状态机」。如果有兴趣的话可以自行搜索。
#专栏作家#
给产品经理讲技术,微信公众号(pm_teacher),人人都是产品经理专栏作家。资深程序猿,专注客户端开发若干年,对前端、后台技术略懂,热衷于对新的科技领域的探索。
本文原创发布于人人都是产品经理,未经许可,不得转载。
这几张状态图中,状态和动作都没有完全分清。
图形化比纯文字更直观清晰
看懂了看懂了,一种思维方法,用用试试吧
能解释下吗?没看懂……
没看懂
每篇文章都看