解决技术问题的方法论 点击:159 | 回复:0



今生缘

    
  • [版主]
  • 精华:43帖
  • 求助:20帖
  • 帖子:4757帖 | 10148回
  • 年度积分:75
  • 历史总积分:111144
  • 注册:2011年3月02日
发表于:2018-09-28 09:43:35
楼主

 当遇到设备故障等技术难题时,对于技术团队来说,最关键的并不是对于技术细节的把握,而更多的是对问题处理阶段和进程的把握。很多时候,我们会因为急于解决问题,而盲目的采取着各种措施,却丢失了大局观,陷入极为被动的困境。在我看来,当遇到设备故障等技术难题时,通常会经历几个不同的重要阶段。如果你很清晰的把握这个过程,那么那些技术细节的浮现乃至问题的迎刃而解,只是一个结果而已。

 1症状

  所谓症状,就是设备的异常情况的现象,其与本来(设计的)预期的不同之处。可以是一个故障报警代码,也可以是一个异常情况的具体描述。比如:”我的汽车发动不起来了“,或者“我的仪表盘显示屏上显示了xxx的故障代码“ 等等。

  对于症状的描述的具体程度是很重要的,还是拿上面的症状举例,”我的车坏了“和”仪表板上有个故障“,这样的描述就可以再具体些。

 2线索

  线索,是说在发生异常的症状期间的一些其他可能的相关现象,简单的说就是在此期间还发生了什么,它们可以是之前、也或许是之后,或者伴随症状出现。还是拿汽车无法发动来举例,”之前使用汽车的时候,车灯关了么?“”汽车发动的时候,有没有点火的声音?“”车灯现在还亮么?

  线索的收集,仍然是停留在现象信息的层面上的,同时也并不消耗很大的成本。但这却是一个很重要的工作。很多时候,我们很急于去快速找到问题所在,但却忽视了线索的收集。要知道,在有经验的情况下,寻找线索是非常有方向性的,这时我们可以很专注于那些经验告诉我们的线索;但是很多问题是非常独特的,很少有经验可以参考。所以,关于线索,我的经验是,“宁可错杀一千,不可放过一个”。很多检测报告申请的时候,往往要填一大堆表,也是这个道理。

 3测量

  坦率说,我觉得,这也是线索的一部分。之所以分开,是考虑到
A.测量会带来成本的消耗。关于现象的描述,打电话给维修店,他们都会乐意解答啦,但一旦你让他们上门检测,几十块的上门费总是要的吧。对于工厂的设备的服务,那些服务商收费就更狠了。
B.测量获得的更多是量化的数据线索。拿汽车发动的例子来说,就需要测量电瓶的电压了。而对于很多工厂设备,有可能要测量的数据就很多了。上示波器拉个波形出来也是常有的事情。
C.测量是需要基于线索和症状有一定针对性的。
  测量,是将故障现象从定性到定量的过程。其重要性不言而喻。但我们发现,很多时候,我们需要在故障发生时(甚至发生前)就获得数据,如果等到发生后再去获得,就晚了,没意义了。这就是信息的实时性,也是现在很多设备需要上“预防性维护”的系统的重要原因。很简单,想象一下-当故障发生的时候,所有和故障相关的信息数据都在你得手上了,那你可以节省多少时间去收集线索和数据呢。

 4分析

  分析,说白了就是将上面的所有关于此症状的信息、线索、测量数据放到一起,找到它们之间的因果关系,从而找到问题出现的原因。比如,”测量了电瓶电压后,电瓶的低电压,告诉我们可能是电瓶没电了,导致车子无法发动”

这里有几点需要注意:

1. 分析的结果是非常取决于之前的线索和测量的结果的,没有充分的线索和数据,是无法得出好的分析结果的。

2. 原因的追溯是可以没有终点的,何时我们认为满意呢?拿上面这个例子,汽车无法发动可能是因为电瓶没电造成的-那电瓶为什么没电呢?再找线索,分析发现可能是电瓶坏了-那电瓶为什么会坏了呢?再找线索发现电瓶寿命可能太长了……这样可以永无止尽的追溯下去,但一定有一层原因,我们认为可以通过我们的行为去干涉它,来改变故障现象的发生,这时我们就认为是满意的分析了。例如在这里,我们可以通过更换电瓶来解决问题;但假如你的电瓶每3个月就坏一次,那就要继续分析下去了,需要进一步的线索(包括日常使用习惯、行车环境、保养记录…..)去分析了。

3. 分析是一个系统工作。很多供应商都会提供所谓的根源故障的报告,在其中会提及其产品的故障的可能性,比如“产品的损坏可能是由于“短路”或“过电压”造成的”。很多工厂或设备使用方在故障发生时对这种分析报告充满信心,而在报告结果出来后又对供应商给出这样的报告表示不认可。在这里我要提醒大家的是,供应商提供产品根源故障分析,是其向客户提供服务的一部分,但这并不代表供应商就需要成为整个故障分析的主体。所有在这其中的分析检测报告都是整个故障诊断分析过程的一部分,而不是一个结论性的结果。千万不要指望一个供应商的一个分析报告就可以帮你解决问题。它只能告诉你接下来要分析和测试以及排查的方向,让我们知道,我们还需要去看“短路”和“过电压”的可能性。记住,真正能够拯救你的只有靠你自己。

4. 分析的结果往往是可能性,即便你已经有了十足的把握,在没有对分析结果进行测试之前,请告诉自己和大家,可能性故障原因(最多你可以用“极大疑似可能”)

5. 是否一定要打破沙锅问到底呢?这就带出了“措施”阶段。


措施

  我们说了,我们追溯问题原因的目的,在于通过对诱因的改变去解决问题,消除故障症状。一味的刨根问底的找原因,其实并不能最终解决问题;最终是一定要落到采取措施改变诱发条件上的。基于不同层次的原因,以及你对解决问题的紧急程度,其措施也会不同。拿刚才电瓶没电导致汽车无法发动来说,如果只是说车子发动不了了,那么采取的措施可以是“换一辆车出行”或者“叫taxi”,因为你可能急需出行,没有时间管为什么;经过分析,你知道是因为前天晚上忘记关灯导致车子的电瓶没电了,于是采取措施找另外一台车帮充电;但如果是电瓶寿命超过了,无法充电了,那就只能换电池了……

  总之,如果采取的措施可以最终满意的解决您的问题,那么我们就没必要再追究什么原因和责任了(从解决问题的角度看是这样的,但如果造成损失了,责任是必须追究的啦)


测试
  测试其实是验证分析结果的一部分。这里面有2中情况

1. 是通过试验的手段去试图复现(完整或者部分)故障现象中各个线索和数据之间的因果关系。如果在试验中证明满足了特定的几个条件,就一定会发生某个故障,那么就说明我们已经找到了问题症状和其诱因之间的必然联系了。这时我们说,已经找到原因了。

2. 很多时候,我们并没有条件去做上述的“复现”的试验,或者也没有必要。但当我们分析到某种原因的时候,我们发现已经有能力去改变这个(些)可能的故障原因了,这时我们需要对这样的“措施”进行验证。

  第1种测试看情况可有可无(当然有条件最好做),而第2种测试,则是最终验证我们是不是真正解决问题的关键性实践步骤。当我们将最终分析结果的建议措施付诸实施,发现问题故障消失,此时,我们可以说“结案”了。

  需要提醒的是,这个测试的效果有时是立竿见影的,而很多时候,是一个漫长的试验过程,尤其是那些“软”故障,一定要有准备,继续不断的去“测量”和收集“线索”,直到最终测试数据表明可以”结案“了为止。

  说了这么多,就是希望帮助大家在处理技术难题(尤其是故障)时提炼一下思路。其实,对于处理问题的进程的管理和把握是非常锻炼和考验技术管理人员的能力的。在处理疑难杂症的时候,常问以下几个问题,用来把握问题处理的进程和阶段:

a. 问题症状的描述是怎样的?

b.我们需要寻找哪些相关线索,进行哪些测量

c.这些线索和测量数据说明了什么,他们有什么样的因果关系?

d.我们可以复现问题,或者这些线索中的因果关系么?

e. 我们可以采取哪些措施呢?何时可以采取措施

f. 采取的措施实施获得了什么效果?

g. 我们对测试措施的结果满意么?

1分不嫌少!


楼主最近还看过


热门招聘
相关主题

官方公众号

智造工程师