梳理问题的时候，最大的忌讳，就是：提问人说啥，回答者傻乎乎记啥。很有可能对方只提及了问题某一方面，漏掉了一些信息。想要系统化梳理，可以用SCQA方法。
SCQA，即：S：Situation情景C：Complication冲突Q：Question问题A：Answer答案
进一步，又可以分作：
1、现状2、困扰3、非期望结果（R1）4、期望结果（R2）5、R1和R2的差异，产生冲突（C）
通过梳理，把问题放置在一起具体场景里，就能看清楚：到底有没有问题？到底是多大的问题？解决到啥程度算结束？
举个简单的例子，一个完整的问题描述，如下所示。相比之下，我们最常听到的：“为啥DAU又双叒降了？”就是一个典型的三无问题。
“这是正常波动”
“埋点动了，没人上报”
“推送系统bug了，没人上报”
甚至分析ppt还没写完，指标就涨回去了……
╮(╯▽╰)╭
因此梳理问题的第一步，就是确保S和C足够清晰。现实工作中常见问题是：
有现状，无困扰无现状，有困扰有困扰，无预测有预测，无期望
（如下图）
总之，问题描述丢三落四，也难怪做分析的时候无法形成假设，找不到评价标准了。这一点大家切记切记。
在开展分析的时候，最重要的区分是：是否有初始假设！有假设和无假设，完全是两个思路。
在无假设的时候，就像大海捞针，并不知道问题的根源，也不知道能怎么解决问题。此时想解决问题，只有用：标杆分析法。
1、树立标杆：行业内标杆是谁？2、分解标杆：标杆是怎么做的3、对照标杆：参照标杆，我司差距在哪里？4、形成方案：如果条件足够，直接抄标杆做法。如条件不够，参照标杆的思路。5、评估方案：如果可行，设监控指标，投入执行；如不可行，更换标杆。
这套方法，是最适合分析人员解决问题的方法。因为分析人员强在分析，弱在执行。如果能找到合适的标杆直接复制，就节省了分析人员学习业务的过程，那是最合适不过的了。
这种方法的缺点也很明显：缓慢、笨重、经验主义。很有可能分析人员总结了半天，自以为收货满满，结果在业务看来，这都是“常识”“我早知道了”。并且，不是所有的问题都能找到标杆，也不见标杆都管用。
所以，一般情况下都更推荐有假设的方法。
这种方法能避开业务已知的情况，直插重点。并且，站在分析的角度，证伪比证真更容易，因此能更快形成分析结论。
当然，这种方法也有缺点，就是需要业务对问题有足够的认识，能提出假设。同时，需要分析人员，有足够强的逻辑能力，梳理假设。因为业务直接扔给你的假设，很有可能是自相矛盾，混乱不堪的……（如下图）
分析完毕之后，可以着手解决问题。注意！并非所有时候，业务部门都是束手无策的，有可能他们已有应对预案。因此想解决问题，首先要知道业务部门的工作状态。
这里有四种基本状态：1、完全不知道怎么办？2、有ABC方案，不知道选哪一个？3、有A方案，但是不确定行不行？4、有A方案，确定不行！还能有什么方案！
这四种状态下，解决问题的思路是不同的。
显然，最难搞的是状态1，完全没想法，只能先找想法。此时可以把分析阶段整理好的思路用上：
第二难解决的是状态4。知道XX方案不行，也算是半个答案，起码它缩小了探索方案的范围，知道哪些方案是明确不行的。此时操作和应对状态1是一样的，用标杆分析法或者MECE分析法。探索解决方案
第三难解决的是状态3。在已有方案情况下，检查2点：
其中，方案本身可行性检查较为简单，熟悉业务的话可以很快确认清楚。预测方案是否能解决问题，有2个基本方法：要么，看历史数据，如果历史上有类似项目，可以把当时的效果拿来做参照。要么，做测试，先测试一下，看看效果是否达预期，再大规模推广。经过分析如果方案可行，能解决问题，直接上就完事了。如果不行的话，再退回到状态4，探索其他方案。
状态2是最容易解决的，已有三个方案，直接比较三个方案的可行性与预计效果即可。
当然，很有可能探索方案的过程不是一帆风顺的，而是一个：发现线索-验证-失败-再发现的循环，因此上述分析过程，可能会循环往复，开展多轮，直到结果让人满意为止（如下图）。
长期以来，人们对分析工作有深深地误解，以为做分析的都是身穿道袍、脚踏祥云、仙风鹤骨的神仙，无需别人多言，只要掐指一算就能得出答案……似乎会分析的人是不需要做具体工作，不需要了解细节的。
恰恰相反！正儿八经的分析工作，恰恰是建立在非常细节的梳理问题，非常细致的梳理假设，非常详细的拆解标杆的基础之上的。
工作做得越细，收集的真实信息越多，越容易接近真相。工作做得如此之细，以至于不懂行的人会问“至于吗？有必要吗？我看差不多啦！”而很多优质的分析，正是建立在拒绝“差不多啦”之上的。
做分析的本质是建筑工，要一砖一瓦的打地基，不是算命师傅，切记切记。