作为一个技术负责人，帮人解决技术难题是一份不能脱责的工作，平常20%的工作时间是在帮人解决问题。解决问题时也常碰到恼火的情况， 而让人恼火的原因不在问题的本身，在于提出问题的方式。提问题的人如果缺乏对问题基本了解，甚至还无法描述出问题，就将问题抛出，那解答问题的人就需要追本溯源，从问题具体是什么开始追问，然后再去一步步的耐心解决，效率明显低下。很多时候，解答问题的人，怎样才能做到授人以渔而不是授人以鱼呢？
下面主要说说我对解决问题的一些思路：
收集足够的信息描述出问题
什么是问题？我经常给它定义：问题就是信息不对称。最可怕的不是问题本身，是不知道问题出在哪，而不知道问题出在哪，是因为没有收集关于问题的充足信息。当无法用清晰的方式将问题的现象描述出来，说明信息是不充分的。比如经常被问到一个问题：我昨天的程序还是可以跑起来的，但是今天就不能跑起来了。这个问题的表象就是昨天可以运行的今天不能运行了，如果只能这样的描述问题，显然没有掌握充分信息。需要更多地去收集：今天不能运行是因为抛异常了嘛？异常的描述信息有收集吗？异常描述里的关键字有提取吗？有将这些关键字拿到搜索引擎里去搜索别人关于这个关键字的更详细描述吗？有收集昨天和今天运行环境的变化吗？沿着这个思路，90%的问题都可以找到原因。而当你一股脑将问题抛给有经验的人去解决时，他的思路其实也是如此，一步步搜索关于问题的相关描述信息，只是他们更多的是在他们拥有的经验里快速搜索，所以，他们解决问题的速度会更快。可他们的经验，也是经过长时间信息积累后一步步建立起来的，慢慢从“慢思考”转变为了“快思考”。如果你不去经历这样思路和信息积累过程，将永远只能依赖别人的经验。
学会问问题，掌握问问题的艺术
个人的经验不足，就需要很多地去依赖过来人的经验。但很多时候，有人问一个技术问题，讲了三分钟后，我只能反问他一句：问题是什么？这真是尴尬。其实被问问题的人，他们最需要知道这几件事：问题发生的场景是什么？已经收集到的关于问题描述信息有哪些？希望问题解决后达到的效果什么？需要说清楚问题发生的场景，现象描述以及达到的效果，是因为这三者是解决问题的人从他的经验里搜索和匹配信息的关键，大多数的情况下，人解决问题的依据都是头脑里现存的信息，而如果你问问题的方式，不能快速帮助被问问题者快速匹配信息，那他解决问题的效率跟你是一样的。重要的事情再重申一遍：问题的场景、现象、需要达到的效果。
努力创造问题重现的环境
前文说到，90%的问题可以沿着信息搜集的方式找到原因。但是，另外10%的问题，问题的描述信息却不能轻易的搜集到，而需要努力去重现问题发生的场景，一个能重现的问题就是一个好问题。当然，部分问题的场景重现难度，可能是现有能力不能驾驭的，对于这部分问题，当请求他人协助时，不如就直接请求别人协助构建问题重现的环境。而当然，问题如果真的无法重现，只会敦促你更好地去建立跟踪机制，比如程序的日志功能完善等。有些时候，不构建重现问题的环境，通过暴力的手段，也可以将问题暂时绕过，比如重启程序或者重启设备，但是这样的方式只是暂时，不能保证下一次不再发生。当你用了这种暴力手段，甚至有可能导致重现问题的场景变得更加困难。所以，暴力虽好，且用且慎重。
4.不制造新的问题
有了足够的问题描述信息，靠自己或者依靠他人的经验，可能就能得到解决方案。但是这时，一定要静心下来想一想，解决方案会不会制造新的问题呢？因为新的解决方案难免要就要对现有的情况实施变更，而只要有变更，就会有发生更严重问题的风险。别让你的解决方案成为新的祸根，铭记海恩法则：每一次严重事故的背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患！再好的技术，再完美的规章，在实际操作层面，也无法取代人自身的素质和责任心。