神刀安全网

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

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

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

「状态机」是什么

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

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

用图表描述状态机

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

用图形描述状态机

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

「状态机」中的要素

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

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

举个栗子

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

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

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

产品经理如何利用状态机

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

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

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

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

#专栏作家#

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

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

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » 产品经理应该这样提需求之“状态机”

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址