Appearance
16问题定义和拆解：如何去定义问题、拆解问题？
今天我主要介绍问题的定义和拆解。
在实际工作过程中，分析师经常会面对业务方的诸多需求，此时我们需要找到业务方的本质需求是什么，然后在此基础上按照逻辑树进行拆解。
在讲解之前，我先说一下本课时的知识点你应该怎么运用？
先分享：分享给别人后，别人会有不一样的理解、疑问、质疑和新想法，会增强你的认知程度。
再使用：每一课时的内容都只是我经历的一个沉淀，每个人都要结合自己的实际情况去使用。只有多和同伴交流，你才能督促自己去对每个知识点进行更深入的理解。
在开源知识分享这件事上，1+1 永远大于 2。
使用方法：截屏或分享链接，你要花更多的时间去和同事探讨 ， 并独立思考，自己也可以总结笔记。
本课时内容分为三部分。
举个例子（问题识别）；
问题识别的方法论；
再举一个问题拆解的例子。
举个例子（问题识别）
案例背景：
小 A 同学每天都有大量临时提数需求或者杂事，没有时间去做真正的专题分析，感觉自己的能力提升不了，工作越来越没意思。因为力不从心，做事也不认真，老是出错，最近跟同事领导关系变差。年底考核，领导给小 A 的绩效也不太好，回去之后年终奖也少了很多，跟女朋友也经常吵架，最近事业感情都不太顺，失眠，甚至有点抑郁。
这一段话描述下来，我们发现有很多问题，如何对问题的进行识别和拆解呢？先说问题识别。
我们可以知道小 A 有很多问题，能力提升不了、做事不认真、跟领导关系变差、跟女朋友吵架、失眠等。然而小 A 真正的问题是当前工作上有大量的临时提数 需求 ，没有时间做专题分析。
针对这个问题，接下来就是怎么去拆解问题，如图所示。
首先问题是有大量临时提数需求，为什么有大量临时提数需求？两个原因。
1. 需求很多
业务繁忙：如果你一直持续业务繁忙，那必须增加人力。
业务方需求变来变去：两个原因，第一是业务方本身也是被动接受任务，他什么也没想就被动接受任务，向他提任务的那一方变了，他也变了，所以你也跟着变。第二个是业务方没想明白这件事。这两个实际上不一样，所以对于需求变来变去，最好是对这个需求进行拆解。
2. 自身效率低
- 对表不熟悉
如果对表不熟悉怎么办，那就多去找研发，聊多了，你就知道是什么表了。
- 对工具不熟悉
如果是对工具不熟悉，根据实际应用需求去学一个工具课程即可。
其中红色圈住的部分是较常见也最花费时间的问题。需求变来变去的真正原因是因为业务方自己都没明白这件事，所以小 A 在这个基础之上，要理解好业务。业务方没想明白，我们要帮他想明白，然后我们把核心指标体系给他。所以在大量临时提数需求这件事上，答案就是这样，我们一定要理解业务，与业务良好沟通，跟业务方打好关系。
实际工作过程中一共有四个层次，你可以对照一下这四个层次，看自己到了哪一层。
Level 1：对方提了很多需求，问题有没有找到？
Level 2：把问题拆到了第几层，大部分人拆解问题的深度不够。
Level 3：问题拆解到了最后一层，并且去执行了。而对于一些性格内向的人，就找研发沟通这件事，其次你做 得 好不好，效率高不高，这又是另外一种能力的培养。
Level 4： 掌握了以上所有方法，同时 可以 在工作中很快 地 发现别人的问题所在。同 时同 事之间经常会有一些相互指导 ， 当别人 让你给 一些指导时，你能够很好 地 去用这些方法去帮助他人。这个时候就已经代表这些方法已经在你的脑海里根深蒂固了 。
问题识别的方法论
我们再来看下问题识别的方法论，实际上很多书上都有介绍，这一块我就根据自己的思考然后结合书上的一些知识给大家讲下。
首先是二八定理的思考，遇到 N 多问题，其中必然有一个主要问题，一旦这个问题解决了，其他问题也迎刃而解，所以所有问题一定会有破局点。当我们去跟业务方沟通，他们可能说了十个问题，那必然有一个是主要问题。而这个主要问题就是你要去做的专题分析。
怎么找到这个主要问题呢？第一你先列出所有问题，自己头脑风暴。第二根据最大概率法则，一项一项来试，是否解决一个问题，其他都迎刃而解？如果你真的不会，那就请教你的 leader。在问题识别这件事上，一定要心静下来单独思考这件事，动笔画图。
所有的业务问题一定有破局点，怎么做就看问题的拆解。对于问题的拆解大家就更熟悉，很多书上说 MECE 原则------不重复不遗漏。其实这个原则说起来容易，实施起来太难。我做过很多次，我发现 MECE 原则有时候不好用。我后来想了一下，为什么实施起来不容易，就是因为两点，第一是因为信息的不对称性，MECE 原则是不重复不遗漏，但在实施中很难没有遗漏，因为业务方想的你还真不一定都知道。第二是因为开始做的时候，你真的很难去把握会不会重复，实际上重不重复对结果影响不大。
实际工作过程中，我把问题的拆解分为以下四步，这更具有实操性。
先快速按照你的理解去做拆解，不要管重复遗漏，能想到多少是多少。
拿着你的拆解去跟业务方（脑子灵活）的人对，请教他------这代表业务方在想。
修改第一步的思维导图，做完后，请教你的 leader------这代表你的 leader 在想。
再改一次，汇报给业务方 leader------这个时候问题不会很大，否则就不是否定你一个人了。
问题拆解例子
说完这个方法论之后，我们再来看一个案例。
案例背景：
某 APP 前期用户量一直在下跌，近期转型（新功能取代第一大功能），转型过了一段时间后，整体用户量大跌。业务负责人压力很大，希望数据部门能派人 100% 投入分析，然而数据方觉得大跌就是因为转型，没什么可分析。于是两个部门就对上了，数据方觉得产品太烂，业务方也不给数据方需求，数据方人员存在感不强，正在考虑是否跳槽。业务进一步下滑，业务方投诉数据部门，决策层在考虑找新的数据部负责人，然而不太好找，各方压力越来越大。
我们从案例里面识别问题，主要问题如下：
用户量大跌的排查；
数据方与业务方关系非常差；
数据方存在感不强；
找不到新的数据负责人。
在这些所有的问题当中，第一个问题是主要问题，也就是破局点。先说明，之所以现在你能一眼就看到最主要的问题是因为两点：一是因为案例本身对你来说没有代入感，毕竟当局者迷；二是因为这里描述的相对简单。真实工作中，在各种复杂因素下，还真不一定很容易就找到破局点。比如，你自己都觉得产品没啥戏了，再加上存在感不强，你可能就去找工作了。
所以问题的识别就是先罗列，然后按照最大概率法则一项一项排查。我们可以把用户下跌原因拆解成下图所示。
用户下跌的原因无非就两个。
1. 转型影响
- 新功能不好用
如果是新功能不好用，你需要做数据分析和用户研究。数据分析是分析新功能的用户留存和 CTR 怎么样，找到异常点分析。用户研究是对用户进行访谈加研究，对客户投诉较多的问题以及用户体验的槽点提出改进意见。
- 新功能不感兴趣
如果用户是对新功能不感兴趣，我们要看用户的行为路径，是不是当用户跳到这个功能之后，立马就切换了，这代表用户压根就不感冒。用户行为路径分析我们前面讲过，你可以去复习下。
2. 非转型影响
- 行业问题
如果是行业问题，要看整个行业（竞品数据）是不是都不太好，数据可以通过财务、公开数据、第三方公司查看。
- 本身问题
如果是本身的问题，我们就要看版本、用户等各方面数据。而且分析到后面还会有很多指标可以去做。
基于这样一套思维导图，我们要做的就很清晰。你如果把这一套逻辑性很强的思维导图给到业务方，那对方看完之后发现，可能觉得真的是转型影响或者是产品真的没有做好。那大家就一起把力往一处使，最终问题也不会太大。在一些时候，数据分析师一定要第一个跳出来，把问题逻辑梳理清楚，最终推动解决问题。
最后说一下我做问题拆解的感触，在做问题拆解之前，一定要找到真正业务方关心的点，他们到底想要什么，就是他们可能说了很多点，但是真正的破局点是什么，再对问题拆解。这样做的好处是能够让业务方清晰理解你的意思，如果你表达能力不是很好，就请画图。有了具体框架后，业务方会提出具体的建议，这个过程的价值是巨大的。
有些很多工作多年的人，始终不知道如何去提升自己，这个时候请获得他人的反馈，每次反馈都是对你内心的冲击，也只有这样，你才能真的提升。所以还是回归到那个点，就是我们这些知识点，大家一定要去分享。你一定要敢于抛出来跟别人分享，看别人怎么去看待这个知识点的。这个时候双方的交流就会让你有不一样的感受。