工程师每天的工作其实就是解决问题。但是，每个工程师解决问题的能力其实是有差异的，所以效果也是不尽相同。

那么是什么导致了这个能力的差异呢？

最近我发现其实是没有明确“要解决的问题到底是什么”。

所以，今年部门重新为大家设计了需求文档的模板，这个模板里最重要的就是Overview和Why两个部分，这两个部分就是在帮助大家明确问题。

那么我今天也谈一下如何来明确问题。

明确问题的三个步骤

我们经常遇到的场景就是，用户给一个需求：请在界面上添加一个按钮，点击后实现什么什么功能。这其实不是在描述问题，而是在说如何解决问题。请注意，遇到这样的场景时，你一定要问自己“我遇到的问题本质到底是什么？我实现这个功能要解决什么问题？”

你可以从三个方面来明确问题：

第一步，你要找出对方关心的问题点。还拿刚才这个当例子，你可以说，“我看了一下你这份文档，似乎是想让我们做这个功能以降低客服人员每天处理这类case的数量，我刚才去查了一下过去一年里这个类型的case占到客服每天工作量的10%，这个数字确实很惊人。我想明确一下，你想让我解决的问题是不是这个？”这个时候，对方很可能就会讲，“对啊，我就是要解决这个问题。”

第二步是明确解决问题的目标。现在你知道你要解决的问题是什么了。那业务方是希望把这个类型的case率降到2%还是1%，甚至完全清零？不同的目标对应的解决方案肯定也不一样。

再高级一点，你还可以给出建议的目标，比如你可以说，“我分析了一下过去的case数据，我发现有70%左右是要干的完全一样的事情，另外30%的case略有不同，我们可以完全实现那70%的功能，大概需要付出10个人日的成本。当然，如果要完全把case量清零，可能要付出100个人日的成本，但是我觉得可能并不划算，你觉得呢？”这个时候，用户肯定会非常信服你的答案，对于你来说就既明确了问题，又知道了自己的目标是什么。

第三步就是要明确可以用来解决这个问题的资源。 我们现在假设你和用户达成一致了，你们的目标就是要把这个类型的case量降到30%。那你肯定就会需要客服部门，甚至其他团队等等的配合。这些资源，你都需要去申请。

经过我们这三个步骤，你就可以从一头雾水到达一种非常清晰的状态。而不是像以前，拿到需求就开始去分析如何实现功能。而且，在分析问题的过程中，你也对公司业务部门的工作情况了解了许多，也间接让你明白了我们系统的用户有哪些痛点。

复杂问题怎么办？

像刚才那个例子中的问题明确到这一步，要解决它其实就很简单了。但是，现实工作中，其实有很多问题没有那么明确和清晰，我们总觉得解决起来就是千条万绪，找不到思路呢？这个答案很简单，也很重要。因为，我们生活当中遇到的大多问题都是所谓的复杂问题，而不是元问题。

什么是复杂问题呢？就是掺杂了多个维度和变量的问题。那什么是元问题？就是那些最本质、最细小的待解决的问题。

复杂问题是不可直接解决的。你每天都在应对各种各样复杂问题的时候，其实都是在下意识地把这个复杂问题做拆解，然后再去逐个地解决掉。但是“下意识”是靠不住的。我们都需要有意识地去训练拆解和解决问题的习惯和能力，并且要能够主动应用这种能力才可以。

当问题被拆成了这样一个个元问题的时候，你其实就会对如何解决这个问题有一个特别好的认知了。你可以一项一项地对照着来问自己。这样一来，很多问题就可以变得非常落地，变得可以解决了。而且，还会变得很有方法，有逻辑。你可以依着那个逻辑去想你该怎么样达到你的目标。

那么如何拆分问题呢？

有两个办法。第一，公式化你的问题。这个办法我在之前的文章有价值的目标里提到过，在描述电商的商业逻辑时，用到的就是一个公式。

用公式有一个好处，可以将问题中的所有因素放到一个公式里，那些因素是正面促进作用，哪些因素是反面抑制作用，都可以清楚的看到。这样，解决方案也就呼之欲出了。

第二个办法，搭建问题树。我们常用的思维导图就是问题树的一个应用。问题树有助于我们将问题影响的各个方面都罗列出来，不会有遗漏，同时也可以帮助我们层层递进的去分析问题。

好了，今天的文章写完了，但是你会发现写到最后我都没谈到如何解决问题，因为我觉得问题一旦分析清楚了，解决方案就已经不难找了。而普通人和高手的区别往往就是没有高手那种洞察问题本质的能力。

另外，关于问题的分类，也可以看之前的文章认知的场景里提到的Cynefin Framework。