接下来，我会为你逐一讲解这5个步骤。
## 第一步：明确问题（Specify）
第一个步骤是，**明确问题**。
我有个朋友曾经遇到过这样的情况：
领导跟他说，最近团队士气好像不高。他立刻分析了8点原因，并提出了针对性的改进意见，还觉得自己反应很快，能力很强。
然后领导就让他负责提升士气，于是他组织培训和团队活动，搞各种评奖，推出各种新制度……干了一大堆事儿。
结果半年后，老板说，感觉士气还是没什么变化。
这其实是很多人都会犯的第一个错误：**问题本身都没有明确定义，就直接开始采取行动。**结果很可能就是，你做了很多事情，但无法衡量。
所以你一定要提醒自己，在解决问题之前，先要明确问题。（这本来是不言而喻的道理，但是在实际工作中我们往往容易忘记。）
怎么明确呢？根据问题有没有用数据量化，可以分为两种情况。
### 量化了的问题
首先，对于已经用数据量化的问题，关键在于**确认数据是否准确**。
通过数据来展现问题是比较直观的，而且很多人认为“数据不会撒谎”，所以他们看到数据之后就直接开始处理。
但其实这种情况也是需要明确问题的。因为数据可能出错，出错的原因有很多种，可能是源数据出错，也可能是计算时出错。
我就多次遇到过报表系统出问题导致业务数据异常的情况；也遇到过统计部门调整算法但是引入bug，从而导致数据错误的情况。
怎么确认数据是否准确呢？最方便的方法当然是**让数据部门去核对**，但是可能耗时比较长；而最快速的方法则是**通过多个关联数据互相验证**。
以互联网电商业务为例，如果**月销售收入**下降了20%，但是**月订单量**和**月活用户**（MAU，Monthly Active User）都在增长，那么很可能是销售收入的数据统计出了问题。
### 没有量化的问题
其次，对于没有用数据量化的问题，又可以分为两类。
一类是**可以量化但是还没量化的**，比如“业务增长放缓”，其中的“放缓”到底是什么意思，是增长速度从100%下降到60%，还是增长速度从10%下降到6%？不同的人理解可能千差万别。
对于这一类问题，你把量化的环节补上就行了。比如老板说：“我对当前的利润增长速度不满意，希望更快一点。”你就要明确，老板关注的指标是季度增长率还是月增长率？更快一些具体是多快，20%还是50%还是200%？
另一类是无法简单量化的，比如“团队士气不高”，其中的“士气”只是一种主观感受，很难量化。
所以这类问题是最棘手的，一是士气不高也许只是领导自己的感受有问题，并不是真的存在这个现象；二是就算真的士气不高，改善的效果也很难衡量。
你怎么证明你提高了士气，又怎么证明士气到底提高了多少呢？
直接用数据来衡量肯定是不现实的。经过实践摸索，我发现**调查问卷**是一种比较有效的方法。既然是主观感受，那我们就综合大多数人的主观感受来得到一个相对客观的评价。
这就像一部电影好不好，虽然不能用片长、投资金额或明星数量来衡量，但是如果看过的观众都来打分，最后综合算出一个分数，还是有一定参考意义的。而且评价的人越多，越能客观地反映影片的质量，这也是豆瓣等平台的价值。
调查问卷的设计技巧总结如下：
1. 问题数量在10～15个左右，太少会导致问题分析不全面，太多会导致被调查的人不想答。
1. 问卷数量至少10份以上，太少会导致单个样本对整体结果影响太大。
1. 尽量用选择题，开放性问题不要超过3个，因为没几个人会认真回答开放性问题。
1. 评分用1～5分，不要用1～10分，用10分制的话，区别度不大，平均分基本都是7～8分。
如果你的P8或P9级别的领导让你帮他分析一下团队的士气，那么你可以这样设计调查问卷：
注：仅为示例，实际的问卷内容要更多一些。
基于多份问卷的结果，就能在一定程度上分析出团队士气情况和整体成员的认知情况，从而避免个人主观判断的偏差。
不过，如果团队的人数很少，就不要用调查问卷了。比如你是P7的Team Leader，手底下带了5个人，现在你觉得团队士气不高，可以直接找他们一个一个聊，这样效果更好。
## 第二步：拆解问题（Split）
第二个步骤是，**拆解问题**。
明确问题之后，你是不是就准备急着去分析原因了呢？毕竟你是负责人，领导还等着你的答案呢。
这就是很多人都会犯的第二个错误：**把自己当成拯救世界的超级英雄，以为可以一个人搞定所有的事情**。
如果问题很简单，那么确实可以这样做。但大部分问题其实是比较复杂的，甚至有的问题看起来很简单，实际上可能涉及很多方面，如果你只靠自己一个人去分析，也许花了很长时间都搞不定。
所以为了能够更高效地分析问题和更快地给出解决方案，你要学会拆解问题。
具体的做法是，对问题进行初步的分析，将大问题拆解为几个独立的子问题，然后再根据子问题的数量和规模，看看是否需要申请更多人力资源来一起参与问题处理。
简单来说，就是**不要单打独斗，要学会利用团队力量**。
至于按照什么维度拆解，这就和问题本身有关了。业务类的问题，可以按照业务类型来拆解，也可以按照客户群体来拆解；管理类的问题可以按照流程来拆解，也可以按照事项分类来拆解。
拆解问题有几个常见的小技巧：
1. 拆解出来的子问题数量2～5个，拆太多了就很难保证互相独立。
1. 拆解出来的子问题尽量互相独立。
1. 明确子问题负责人，组成工作组，定期向上汇报进展。
比如电商业务的“订单数下降30%”，你可以按照业务类型来拆解，看看不同品类各自下降了多少。
经过分析，你可能会发现，“男装下降了20%”、“鞋类下降了30%”、“食品下降了20%”，其它品类的数据还是增长的。
于是，“订单数下降30%”这个大问题拆解成了3个子问题，你可以分别协调对应的运营负责人来一起处理。
又比如“团队研发效率不高”，经过调研发现，团队反馈最多的前4个问题是“会议太多”“测试环境不足”“发布太麻烦了”和“需求变更太频繁”。
如果你一个人搞不定这4个子问题，你可以分别协调项目经理、测试负责人、运维负责人和产品负责人来一起处理。
## 第三步：定位问题（Seek）
第三个步骤是，**定位问题**。
我曾听过这样的案例：
半年的业务买量数据不升反降，老板让运营负责人赶紧想办法。于是他连夜构思解决方案，提出了几个大展拳脚的方案，比如SEO优化、增加更多渠道等。
老板大手一挥批准其中3个方案，半年后一看，投入多了几千万，买量的数据却没有多大起色，老板脸色很难看。
这就是很多人都会犯第三个错误：**没有找到根本原因的情况下，就急于给出解决方案**。
如果你只找到了表层原因，那么后续提出的方案就是无法从根本上解决问题，只能白白浪费时间和资源。
定位问题的技巧就是**5W根因分析法**，我在26讲已经介绍过了。需要注意的是，根本原因可能不止一个，不同的追问线索可能找到不同的根本原因。
比如“加班太多导致士气不高”，我们也许可以得到两个根本原因：“市面上的Go程序员较少” 和 “没有项目经理”。
>
问题1：为什么士气不高？
答：因为加班太多。
问题2：为什么加班太多？
答：因为人力不够。
问题3：为什么人力不够？
答：因为招聘困难。
问题4：为什么招聘困难？
答：因为市面上的Go程序员太少。
问题1：为什么士气不高？
答：因为加班太多。
问题2：为什么加班太多？
答：因为项目执行混乱。
问题3：为什么项目执行混乱？
答：因为没有项目经理。
## 思考题
这就是今天的全部内容，最后留一道课后思考题给你吧。你职业生涯中处理过的最棘手的问题是什么？你在处理过程中是否犯过某些错误？如果是学完这一讲之后再交给你处理，你会怎么做？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。