扪心自问,我们在用户旅程的投入有多匮乏?
做事情, “科学精准” 的态度
在面对是否直接吃药这个问题上,很多人画了草图,认为直接吃药。
根据梅奥公开的诊断流程,针对可能新冠的儿童我们应该:
根据梅奥公开的诊断流程,针对成人我们应该:
写作背景
15 年一直再看流程图,前两天看到有关国外针对新冠的路径图,正好有小伙伴问,如何做故障的根因分析。
真理论很多很多,假实践也不少。
我联想到上学学的故障分析法,不过随着时间的偏移,我们也不能尽信书,下面讲讲我的一些看法,内容很多,这里只简单介绍,并提 6 个问题。文章正文不足 1 千字,阅读需要 N 分钟。
故障分析的方法
第一种 故障分析法
书上的定义
以不希望发生的一个事件作为分析的目标,通过逐层向下推测所有可能得故障原因,来寻找可能得因素之间的逻辑关系,并使用逻辑门来形成树状图。
故障树示意图
在百度上找了个一个简单的故障图。这个图太简单了,其中一旦出现某一项目的故障,基本很容易能定性的看出根因在哪里。
下图摘自百度
然而实际业务模型或者开发模型,可能远远比这个要复杂的多。但即便是这样,能够有可视化的故障树,也是非常有帮助的,说的高大上一点,我个人认为是一种高级的知识图谱,能很快的定性分析问题。
故障树的定量分析
然而,故障树不仅能定性,还能定量分析问题。我们把上面的图稍微复杂一下,并且给每一项都增加一个事件发生的概率 M,这样是否相对容易算出某个事件的量化情况。
下图摘自北航质量管理与可靠性教材
第一个问题
然而,这篇文章并不是讨论故障分析的。
如果将用户路径或者研发架构图,按照如上方法,进行整理,我们是否能到到一些比较有意思的内容。 但是我们现在有这个类似的图吗?
第二个问题
之前我在掘金有篇文章讲过一种图,是定性和定量的鱼骨图和漏斗模型的结合体。其中讲的也是核心路径的整理。
那我们是否可以从产品角度出发,以某一个功能或者模块的用户旅程为节点,画出这个功能或者模块的用户旅程图来?
第三个问题
点汇聚成线,一个又一个的模块的用户路程图,是否可以汇聚成一张企业大的用户旅程图,这就是可汇聚可下钻。
第四个问题
加上解答完成了前面三个问题,一张用户旅程的“地图”就出来了,我们是否可以针对某个情况,设置关注的点:
告警,比如故障、高流量、异常流量
提升,比如漏斗分析、性能提升
第五个问题
如何创新或者突破?以下图为例,我们想更快的从 A 到达 E。
方法 1:去掉 A 到 E 的中间节点,俗称 砍砍砍,比如从填写 5 个部门的 5 张表的来回奔波到一个部门填写一张表
方法 2:加快 A 到 E 的中间节点,俗称 加速,比如从走路到自行车,再到汽车飞机。
所以第五个问题,其实是可以拆分成两个问题:砍哪个或者哪些,以及如何提高某个或某些的速度
至于图的动态修改,我们姑且认为图都是动态生成。
第六个问题
抽象概念是很难的,科学精准也更难。不论艰难险阻,我们都将失败,但我们必须出发。你和你的公司,现在在哪个问题上?
总结
本文既举了例子,提出了方法,也提出了问题,也提出了问题的解决办法,希望用户能有所收获,至于如何实现,可以逐个知识点学习,希望类似的方法能在用户旅程这个点进行结合,更快的提高。
参考内容
梅奥医学
百度百科
质量管理与可靠性
版权声明: 本文为 InfoQ 作者【Yestodorrow】的原创文章。
原文链接:【http://xie.infoq.cn/article/d59b6c9d8f37e6d73e7e1bb60】。文章转载请联系作者。
评论