软件技术总监技能树详解1-技术难题如何解

技能树我根据由易到难开始细说吧：

技能点1：负责解决产品开发和产品运营过程中遇到的各类技术难题，并提供前瞻性的技术储备；

我们把这段话拆开看，包括两部分：        1）解决各类技术难题；2）提供技术储备：

        说到在产品开发过程和产品运营过程中遇到的怎么去应对，这个具体后面再商讨；我们先说技术难题怎么解决；技术储备怎么做前瞻性的提供我们在做完技术难题如何解决之后就很容易做了；

        技术难题大家都很明白是什么意思，就是别人不会解决，自己也不会解决，但是我们感觉是可以解决的，就是大家说的从理论上来讲是可以解决的；那么这就说明我们是可以找到方法的；

        我一直很认同的一句话:“如果你不能将自己做得事情用一个流程表述出来，那么你不知道自己在做什么”；

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

1. 症状(问题所表现出来的现象)

所谓症状，就是故障对象的异常情况的现象，其与本来 (设计的)预期的不同之处。可以是一个故障报警代码，也可以是一个异常情况的具体描述。比如:”车辆(液压驱动，系统A4VG闭式泵驱动6VM马达)速度慢“，或者“我的仪表盘显示屏上显示了xxx的故障代码“等等。
        对于症状的描述的具体程度是很重要的，还是拿上面的症状举例，”车辆行走慢“和”仪表板上有个故障“，这样的描述就可以再具体些。比如，“同样档位下，发动机大油门，车的速度明显比正常速度慢了很多”
        PS:在处理客户的问题时，要想准确了解故障的症状，往往需要用合理的方式去问，问不同的人，从不同的角度去佐证客户描述的准确性。

2.线索(问题出现前后相关的信息)

        线索，是说在发生异常的症状期间的一些其他可能的相关现象，简单的说就是在此期间还发生了什么，它们可以是之前、也或许是之后，或者伴随症状出现。还是拿车辆行走慢来举例，"之前使用的时候，有这样的现象吗? 是突然发生的还是逐渐的过程?“”系统的油温高吗?“出现这个问题前进行过哪些操作”?“拔掉马达的电磁阀插头速度有变化吗”?

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

 3:分析(根据了解到的线索，制定下一步的检测方案)

        尽可能多地了解线索，根据故障的症状制定初步的测试方案。往往，在这个阶段我们可以借助鱼骨图、思维导图等工具进行故障可能原因的分析，逐一列出，并制定相应的测试方案。鱼骨是可能的直接原因，鱼刺是根本原因的分析。

4:初步测试(对第三步的方案进行测试验证)
        坦率说，我觉得，这也是线索的一部分。之所以分开，是考虑到:
        A）测试会带来成本的消耗。

        关于现象的描述，打电话给维修店，他们都会乐意解答啦，但一 旦你让他们上门检测，几十块的上门费总是要的吧。对于工厂的设备的服务，那些服务商收费就更狠了。

        B）        测量获得的更多是量化的数据线索。

         车辆行走慢的例子来说，就需要测量A4VG泵G口的补油压力是否正常，进一步测试变量缸X1和X2口压力是否正常。

        C)        测量是需要基于线索和症状有一定针对性的。
        测量，是将故障现象从定性到定量的过程。其重要性不言而喻。但我们发现，很多时候，我们需要在故障发生时 (甚至发生前) 就获得数据，如果等到发生后再去获得，就晚了，没意义了。这就是信息的实时性，也是现在很多设备需要上“预防性维护”的系统的重要原因。很简单,想象一下一当故障发生的时候，所有和故障相关的信息数据都在你得手上了，那你可以节省多少时间去收集线索和数据呢。
        PS:对于液压系统而言，往往很难获得故障发生时系统的有关数据，尤其是工程机械液压系统更是难上加难。此时，与当事人的交流就至关重要了，通过询问故障前后的现象来获得有关线索就显得尤为重要了。

5:分析(对测试结果进行分析，缩小故障点的范围)
        分析，说白了就是将上面的所有关于此症状的信息、线索、测量数据放到一起，找到它们之间的因果关系，从而找到问题出现的原因。比如，”测量了A4VG泵的补油压力，可以判断出补油泵是否正常:测试了X1和X2口的压力可以判断出泵头控制阀是否正常等等。
这里有几点需要注意:

• A)分析的结果是非常取决于之前的线索和测量的结果的，没有充分的线索和数据，是无法得出好的分析结果的。
• B)原因的追溯是可以没有终点的，何时我们认为满意呢? 拿上面这个例子，车辆行走慢可能是因为A4VG泵变量不正常?-那泵为什么变量异常呢? 再找线索，分析发现可能是补油泵坏了那补油泵为什么会坏了呢? 再找线索，可能是油液污染导致磨损，可能是补油泵内部齿轮副断裂......这样可以永无止尽的追溯下去，但一定有一层原因，我们认为可以通过我们的行为去干涉它，来改变故障现象的发生，这时我们就认为是满意的分析了。例如在这里，我们可以通过更换补油泵解决:但这只是找到了故障的reason (离问题最近的原因) 还不是rootcause(最根本的，深层次的原因)，是什么原因导致补油泵损坏(油液污染磨损、补油溢流阀异常导致等等)那就要继续分析下去了，需要进一步的线索(包括日常使用习惯、行车环境、保养记录.....) 去分析了。
• C)分析是一个系统工作。很多供应商都会提供所谓的根源故障的报告，在其中会提及其产品的故障的可能性，比如“产品的损坏可能是由于“加工”或”装配”或“材料问题”造成的，也可能是客户使用不当造成的”。很多工厂或设备使用方在故障发生时对这种分析报告充满信心，而在报告结果出来后又对供应商给出这样的报告表示不认可。在这里我要提醒大家的是，供应商提供产品根源故障分析，是其向客户提供服务的一部分，但这并不代表供应商就需要成为整个故障分析的主体。所有在这其中的分析检测报告都是整个故障诊断分析过程的一部分，而不是一个结论性的结果。千万不要指望一个供应商的一个分析报告就可以帮你解决问题。它只能告诉你接下来要分析和测试以及排查的方向，让我们知道，我们还需要去看“油液是否清洁”和“启动前加油排气”的可能性。记住，真正能够拯救你的只有靠你自己。     
• D)分析的结果往往是可能性，即便你已经有了十足的把握，在没有对分析结果进行测试之前请告诉自己和大家，可能性故障原因 (最多你可以用“极大疑似可能”)
• E)是否一定要打破沙锅问到底呢?这就带出了“措施”阶段。
• F)进一步分析测试
  我们说了，我们追溯问题原因的目的，在于通过对诱因的改变去解决问题，消除故障症状。味的创根问底的找原因，其实并不能最终解决问题，最终是一定要落到采取措施改变诱发条件上的。基于不同层次的原因，以及你对解决问题的紧急程度，其措施也会不同。
  总之,如果采取的措施可以最终满意的解决您的问题，那么我们就没必要再追究什么原因和责任了(从解决问题的角度看是这样的，但如果造成损失了，责任是必须追究的啦)

6.测试:

        测试其实是验证分析结果的一部分。这里面有2中情况
        A)是通过试验的手段去试图复现(完整或者部分)故障现象中各个线索和数据之间的因果关系。如果在试验中证明满足了特定的几个条件，就一定会发生某个故障，那么就说明我们已经找到了问题症状和其诱因之间的必然联系了。这时我们说，已经找到原因了。
        B).很多时候，我们并没有条件去做上述的”复现”的试验，或者也没有必要。但当我们分析到某种原因的时候，我们发现已经有能力去改变这个 (些)可能的故障原因了，这时我们需要对这样的“措施”进行验证。
        第1种测试看情况可有可无(当然有条件最好做)，而第2种测试，则是最终验证我们是不是真正解决问题的关键性实践步骤。当我们将最终分析结果的建议措施付诸实施，发现问题故障消失，此时，我们可以说“结案”了。
        需要提醒的是，这个测试的效果有时是立竿见影的，而很多时候，是一个漫长的试验过程，尤其是那些“软”故障，一定要有准备，继续不断的去“测量”和收集“线索”，直到最终测试数据表明可以“结案”了为止。
说了这么多，就是希望帮助大家在处理技术难题(尤其是故障)时提炼一下思路。其实，对于处理问题的进程的管理和把握是非常锻炼和考验技术管理人员的能力的。在处理疑难杂症的时候，常问以下几个问题，用来把握问题处理的进程和阶段:
a.问题症状的描述是怎样的?
b.我们需要寻找哪些相关线索，进行哪些测量?
c.这些线索和测量数据说明了什么，他们有什么样的因果关系?
d.我们可以复现问题，或者这些线索中的因果关系么?
e.我们可以采取哪些措施呢? 何时可以采取措施?
f.采取的措施实施获得了什么效果?
g.我们对测试措施的结果满意么?

如果您已经经常在这样处理问题了，那么恭喜您，您已经知道如何去解决技术难题了。