发表于：2014/7/17 23:47:38
#0楼
花这么大篇幅写这篇文章，主要是最近一直在帮着处理很多技术难题（尤其是设备故障）。有感而发，结合自己这些年的一些经验，希望能帮助大家理清思路。
我一直很认同的一句话：“如果你不能将自己做得事情用一个流程表述出来，那么你不知道自己在做什么“－EdwardDemings。
当遇到设备故障等技术难题时，对于技术团队来说，最关键的并不是对于技术细节的把握，而更多的是对问题处理阶段和进程的把握。很多时候，我们会因为急于解决问题，而盲目的采取着各种措施，却丢失了大局观，陷入极为被动的困境。在我看来，当遇到设备故障等技术难题时，通常会经历几个不同的重要阶段。如果你很清晰的把握这个过程，那么那些技术细节的浮现乃至问题的迎刃而解，只是一个结果而已。
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. 无论您的设备和产品是从谁那里买的，处理故障的主体一定是您自己，千万不要指望那些供应商替你解决问题，哪怕他们的服务再好，也没法天天放个人在那里专门帮你处理这个问题，你给他们所有的要求，都需要漫长的后台流程去处理，无法替代您在现场收集信息和采取措施。
2. 千万不要浪费太多时间反复和别人（尤其是供应商）去抱怨他们的服务不好，您的损失有多大。您的损失您自己明白就好，听取他们的意见，积极的采取措施处理就好，这才是关键。靠谱的供应商不用你解释，他们也明白客户的痛处；不靠谱的，你解释再多也是那个熊德行。
3. 解决问题，最缺的是靠谱的人。我们需要的，不是哪个人对所有技术（从产品到应用）和所有学科都那么精通的大拿（也找不到这样的人）；而是有好的方法和头脑去管理问题处理进程和调动技术资源的人，并且这个人是担当的。
4. 别在还没有任何分析的时候就立刻把矛头直指产品问题。绝对不是帮产品说话，也不是说产品就一定没问题。关键是，证明产品有问题并不能最终帮助你解决问题。事实上，任何卖到市场中的批量产品，都是经过了无数次测试的，其出现问题的概率其实要远远低于设备和生产线。即便是产品真的有问题，也一定是在经过了一系列的分析和测试后，才确定的；就算你要证明是产品的问题，也得用数据说话。所以，说回来，还是关注处理进程，急不得。
5. 千万别指望你一说出故障现象，马上就有人告诉你答案并帮你解决好。即便你偶尔碰到了“高人”的指点，也要低调的告诉自己是运气好。大部分时候，我们没那么运气。真正的高人，即便知道了所以然，也会继续问题一大堆问题，最后问题”你这个试过么？“”你那个看过么“云云。为什么？因为高人们知道，处理问题是一个艰难的过程，高人们对所有问题都是抱着谦虚、恭敬和学习的态度的，决不敢有任何造次。高人们亦是如此，那我们呢？
6. 不要过多的矫情是产品的问题还是应用的问题，别因为供应商或服务商提出某某可能原因，就说别人是在推卸产品责任。想想你到底是要解决问题还是去找茬的。你可以给供应商施压，但要客观。
7. 最后还是提醒一下，在你向任何人求助的时候，千万别忘记2件事
a. 他是帮我的，不是替我做事，这事是我自己的事情
b.问问自己以上几个问题，想想已经处理到哪里，需要对方做什么，具体点。原因很简单，通常对方不会直接给你答案，而是会反过来问题一大堆问题。
文自：麥克瘋
![附件 qrcode_for_gh_351ffa307662_430.jpg]()
我一直很认同的一句话：“如果你不能将自己做得事情用一个流程表述出来，那么你不知道自己在做什么“－EdwardDemings。
当遇到设备故障等技术难题时，对于技术团队来说，最关键的并不是对于技术细节的把握，而更多的是对问题处理阶段和进程的把握。很多时候，我们会因为急于解决问题，而盲目的采取着各种措施，却丢失了大局观，陷入极为被动的困境。在我看来，当遇到设备故障等技术难题时，通常会经历几个不同的重要阶段。如果你很清晰的把握这个过程，那么那些技术细节的浮现乃至问题的迎刃而解，只是一个结果而已。
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. 无论您的设备和产品是从谁那里买的，处理故障的主体一定是您自己，千万不要指望那些供应商替你解决问题，哪怕他们的服务再好，也没法天天放个人在那里专门帮你处理这个问题，你给他们所有的要求，都需要漫长的后台流程去处理，无法替代您在现场收集信息和采取措施。
2. 千万不要浪费太多时间反复和别人（尤其是供应商）去抱怨他们的服务不好，您的损失有多大。您的损失您自己明白就好，听取他们的意见，积极的采取措施处理就好，这才是关键。靠谱的供应商不用你解释，他们也明白客户的痛处；不靠谱的，你解释再多也是那个熊德行。
3. 解决问题，最缺的是靠谱的人。我们需要的，不是哪个人对所有技术（从产品到应用）和所有学科都那么精通的大拿（也找不到这样的人）；而是有好的方法和头脑去管理问题处理进程和调动技术资源的人，并且这个人是担当的。
4. 别在还没有任何分析的时候就立刻把矛头直指产品问题。绝对不是帮产品说话，也不是说产品就一定没问题。关键是，证明产品有问题并不能最终帮助你解决问题。事实上，任何卖到市场中的批量产品，都是经过了无数次测试的，其出现问题的概率其实要远远低于设备和生产线。即便是产品真的有问题，也一定是在经过了一系列的分析和测试后，才确定的；就算你要证明是产品的问题，也得用数据说话。所以，说回来，还是关注处理进程，急不得。
5. 千万别指望你一说出故障现象，马上就有人告诉你答案并帮你解决好。即便你偶尔碰到了“高人”的指点，也要低调的告诉自己是运气好。大部分时候，我们没那么运气。真正的高人，即便知道了所以然，也会继续问题一大堆问题，最后问题”你这个试过么？“”你那个看过么“云云。为什么？因为高人们知道，处理问题是一个艰难的过程，高人们对所有问题都是抱着谦虚、恭敬和学习的态度的，决不敢有任何造次。高人们亦是如此，那我们呢？
6. 不要过多的矫情是产品的问题还是应用的问题，别因为供应商或服务商提出某某可能原因，就说别人是在推卸产品责任。想想你到底是要解决问题还是去找茬的。你可以给供应商施压，但要客观。
7. 最后还是提醒一下，在你向任何人求助的时候，千万别忘记2件事
a. 他是帮我的，不是替我做事，这事是我自己的事情
b.问问自己以上几个问题，想想已经处理到哪里，需要对方做什么，具体点。原因很简单，通常对方不会直接给你答案，而是会反过来问题一大堆问题。
文自：麥克瘋
[此贴子已经被jint于2014/7/22 9:08:11编辑过]
