在解决问题时，总是能听到一个词叫做“结构化分析”，实际上，结构化分析并非只有“分析”一步，它还包括了许多步骤。让我们来向作者学习一下吧~

很多同学都好奇，那些高大上的咨询公司背后，有没有什么神奇方法。也有同学买了《金字塔原理》，可这本书看起来颇为晦涩。很多同学看完了，就记得开篇的：食品分成单奶、水果、蔬菜三类。然而这个玩意和数据分析有啥关系？到底该如何进行结构化问题分析？

整本书很长长长，今天挑重点，用最通俗的语言给大家分享一下。实际上，结构化分析，并非只有“分析”一步。而是包含了梳理问题、分析问题、解决问题三个步骤。所谓“好的问题是成功解答的四分之三”，正是此道。

一、梳理问题

梳理问题的时候，最大的忌讳，就是：提问人说啥，回答者傻乎乎记啥。很有可能对方只提及了问题某一方面，漏掉了一些信息。想要系统化梳理，可以用SCQA方法。

SCQA，即：

• S：Situation 情景
• C：Complication 冲突
• Q：Question 问题
• A：Answer 答案

进一步，又可以分作：

• 现状
• 困扰
• 非期望结果（R1）
• 期望结果（R2）
• R1和R2的差异，产生冲突（C）

通过梳理，把问题放置在一起具体场景里，就能看清楚：

• 到底有没有问题？
• 到底是多大的问题？
• 解决到啥程度算结束？

举个简单的例子，一个完整的问题描述，如下所示。相比之下，我们最常听到的：“为啥DAU又双叒降了？”就是一个典型的三无问题。

然而，很多公司的数据分析，就是从这种不清楚的问题开始，然后把宝贵的时间消耗在无休止的排查中，最后发现：

“这是正常波动”

“埋点动了，没人上报”

“推送系统bug了，没人上报”

甚至分析ppt还没写完，指标就涨回去了……

╮(╯▽╰)╭

因此梳理问题的第一步，就是确保S和C足够清晰。现实工作中常见问题是：

• 有现状，无困扰
• 无现状，有困扰
• 有困扰，无预测
• 有预测，无期望

总之，问题描述丢三落四，也难怪做分析的时候无法形成假设，找不到评价标准了。这一点大家切记切记。

二、分析问题

在开展分析的时候，最重要的区分是：是否有初始假设！有假设和无假设，完全是两个思路。

在无假设的时候，就像大海捞针，并不知道问题的根源，也不知道能怎么解决问题。此时想解决问题，只有用：标杆分析法。

1. 树立标杆：行业内标杆是谁？
2. 分解标杆：标杆是怎么做的?
3. 对照标杆：参照标杆，我司差距在哪里？
4. 形成方案：如果条件足够，直接抄标杆做法。如条件不够，参照标杆的思路。
5. 评估方案：如果可行，设监控指标，投入执行；如不可行，更换标杆。

这套方法，是最适合分析人员解决问题的方法。因为分析人员强在分析，弱在执行。如果能找到合适的标杆直接复制，就节省了分析人员学习业务的过程，那是最合适不过的了。

这种方法的缺点也很明显：缓慢、笨重、经验主义。很有可能分析人员总结了半天，自以为收获满满，结果在业务看来，这都是“常识”“我早知道了”。并且，不是所有的问题都能找到标杆，也不见标杆都管用。

所以，一般情况下都更推荐有假设的方法。

1. 提出假设：对问题来源/解决方案提出假设
2. 分类假设：构建分析问题的逻辑树，把假设归类
3. 验证假设：利用数据/实验，验证假设真伪
4. 得出结论：撇除证伪假设，聚焦能论证的问题
5. 形成方案：针对已论证的问题

这种方法能避开业务已知的情况，直插重点。并且，站在分析的角度，证伪比证真更容易，因此能更快形成分析结论。

当然，这种方法也有缺点，就是需要业务对问题有足够的认识，能提出假设。同时，需要分析人员，有足够强的逻辑能力，梳理假设。因为业务直接扔给你的假设，很有可能是自相矛盾，混乱不堪的……（如下图）

此时需要用MECE分析法，把问题逻辑梳理清楚。之前已有类似分享，有兴趣的戳：麦肯锡在用的MECE分析法，到底是什么？

三、解决问题

分析完毕之后，可以着手解决问题。注意！并非所有时候，业务部门都是束手无策的，有可能他们已有应对预案。因此想解决问题，首先要知道业务部门的工作状态。

这里有四种基本状态：

1. 完全不知道怎么办？
2. 有ABC方案，不知道选哪一个？
3. 有A方案，但是不确定行不行？
4. 有A方案，确定不行！还能有什么方案！

这四种状态下，解决问题的思路是不同的。

显然，最难搞的是状态1，完全没想法，只能先找想法。此时可以把分析阶段整理好的思路用上：

1. 不带假设情况下，看标杆是怎么做的，尝试复制标杆做法
2. 带假设情况下，先把假设指向的问题来源解决掉，再看问题还存在不

第二难解决的是状态4。知道XX方案不行，也算是半个答案，起码它缩小了探索方案的范围，知道哪些方案是明确不行的。此时操作和应对状态1是一样的，用标杆分析法或者MECE分析法。探索解决方案

第三难解决的是状态3。在已有方案情况下，检查2点：

1. 方案本身可行性（时间、成本、质量）
2. 方案是否能解决问题（预测结果）

其中，方案本身可行性检查较为简单，熟悉业务的话可以很快确认清楚。预测方案是否能解决问题，有2个基本方法：要么，看历史数据，如果历史上有类似项目，可以把当时的效果拿来做参照。要么，做测试，先测试一下，看看效果是否达预期，再大规模推广。经过分析如果方案可行，能解决问题，直接上就完事了。如果不行的话，再退回到状态4，探索其他方案。

状态2是最容易解决的，已有三个方案，直接比较三个方案的可行性与预计效果即可。

当然，很有可能探索方案的过程不是一帆风顺的，而是一个：发现线索-验证-失败-再发现的循环，因此上述分析过程，可能会循环往复，开展多轮，直到结果让人满意为止（如下图）。

四、小结

长期以来，人们对分析工作有深深的误解，以为做分析的都是身穿道袍、脚踏祥云、仙风鹤骨的神仙，无需别人多言，只要掐指一算就能得出答案……似乎会分析的人是不需要做具体工作，不需要了解细节的。

恰恰相反！正儿八经的分析工作，恰恰是建立在非常细节地梳理问题，非常细致地梳理假设，非常详细地拆解标杆的基础之上的。

工作做得越细，收集的真实信息越多，越容易接近真相。工作做得如此之细，以至于不懂行的人会问“至于吗？有必要吗？我看差不多啦！”而很多优质的分析，正是建立在拒绝“差不多啦”之上的。

做分析的本质是建筑工，要一砖一瓦的打地基，不是算命师傅，切记切记。

然而在今天，还有另一个趋势，就是把算法当做神仙法器，总觉得只要输入几个简单的数据，法力无边的算法就能得出超牛逼的商业洞察……

作者：接地气的陈老师；微信公众号：接地气的陈老师

本文由 @接地气的陈老师 原创发布于运营派，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议。