扪心自问，我们在真实用户旅程的投入有多匮乏？

做事情， “科学精准” 的态度

在面对是否直接吃药这个问题上，很多人画了草图，认为直接吃药。

根据梅奥公开的诊断流程，针对可能新冠的儿童我们应该：

根据梅奥公开的诊断流程，针对成人我们应该：

写作背景

15年一直再看流程图，前两天看到有关国外针对新冠的路径图，正好有小伙伴问，如何做故障的根因分析。

真理论很多很多，假实践也不少。

我联想到上学学的故障分析法，不过随着时间的偏移，我们也不能尽信书，下面讲讲我的一些看法，内容很多，这里只简单介绍，并提6个问题。文章正文不足1千字，阅读需要N分钟。

故障分析的方法

第一种 故障分析法

书上的定义

以不希望发生的一个事件作为分析的目标，通过逐层向下推测所有可能得故障原因，来寻找可能得因素之间的逻辑关系，并使用逻辑门来形成树状图。

故障树示意图

在百度上找了个一个简单的故障图。这个图太简单了，其中一旦出现某一项目的故障，基本很容易能定性的看出根因在哪里。

下图摘自百度

然而实际业务模型或者开发模型，可能远远比这个要复杂的多。但即便是这样，能够有可视化的故障树，也是非常有帮助的，说的高大上一点，我个人认为是一种高级的知识图谱，能很快的定性分析问题。

故障树的定量分析

然而，故障树不仅能定性，还能定量分析问题。我们把上面的图稍微复杂一下，并且给每一项都增加一个事件发生的概率M，这样是否相对容易算出某个事件的量化情况。

下图摘自北航质量管理与可靠性教材

第一个问题

然而，这篇文章并不是讨论故障分析的。

如果将用户路径或者研发架构图，按照如上方法，进行整理，我们是否能到到一些比较有意思的内容。 但是我们现在有这个类似的图吗？

第二个问题

之前我在掘金有篇文章讲过一种图，是定性和定量的鱼骨图和漏斗模型的结合体。其中讲的也是核心路径的整理。

那我们是否可以从产品角度出发，以某一个功能或者模块的用户旅程为节点，画出这个功能或者模块的用户旅程图来？

第三个问题

点汇聚成线，一个又一个的模块的用户路程图，是否可以汇聚成一张企业大的用户旅程图，这就是可汇聚可下钻。

第四个问题

加上解答完成了前面三个问题，一张用户旅程的“地图”就出来了，我们是否可以针对某个情况，设置关注的点：

• 告警，比如故障、高流量、异常流量
• 提升，比如漏斗分析、性能提升

第五个问题

如何创新或者突破？以下图为例，我们想更快的从A到达E。

graph TD
A --> B --> C --> D --> E

方法1：去掉A到E的中间节点，俗称 砍砍砍，比如从填写5个部门的5张表的来回奔波到一个部门填写一张表

方法2：加快A到E的中间节点，俗称 加速，比如从走路到自行车，再到汽车飞机。

所以第五个问题，其实是可以拆分成两个问题：砍哪个或者哪些，以及如何提高某个或某些的速度

至于图的动态修改，我们姑且认为图都是动态生成。

第六个问题

抽象概念是很难的，科学精准也更难。不论艰难险阻，我们都将失败，但我们必须出发。你和你的公司，现在在哪个问题上？

总结

本文既举了例子，提出了方法，也提出了问题，也提出了问题的解决办法，希望用户能有所收获，至于如何实现，可以逐个知识点学习，希望类似的方法能在用户旅程这个点进行结合，更快的提高。

参考内容

• 梅奥医学
• 百度百科
• 质量管理与可靠性

愿景：成为世界级的监控观测基础设施

作为国内领先的具备可观测性的实时数据监测平台，观测云不断钻研云计算技术，夯实产品性能和服务质量，在帮助越来越多的企业数字化转型的同时，为国内可观测性技术的发展贡献力量。