数据分析报告，【建议】部分该怎么写？永恒岛怎么去

来源|接地气的陈老师

很多做数据的同学都被领导、同事这么吆喝过。然而，什么是策略性思考？？？往往一听到这种词，就有同学急不可耐地掏出《麦肯锡方法》之类的镇山法宝，或者在网上搜《底层思维》、《核心逻辑》、《分析框架》之类的文章。

结果除了“裂变”“痛点”“颠覆”这些似懂非懂的词以外屁都没有记住，下次写报告还是继续同比、环比、三年比，低了要搞高……

咋办？!

看个简单的例子，今天HR的小妹妹李芊颖同学被领导骂哭了，因为身为HR，她本人这周的考勤表，长这样：

SO，作为数据分析师的同学们，看到这个咋提建议？

很快，4个做数据分析的同学都给了答案。

同学1的答案：

• 本月共22个工作日，迟到11个工作日，迟到率50%

• 迟到最多的是第二周，共迟到4天，迟到率80%

• 迟到最少的是第三周，共迟到1天，迟到率20%

同学2的答案：

• 迟到次数太多，建议不要迟到。

• 特别建议周一不要迟到。

同学3的答案：

• 数据来源是……

• 建模过程是……

• 经过回归模型分析，预测下个月迟到12天。

• 建议减少迟到。

同学4，还没给答案：

他正在网上找《员工迟到分析模型》。找了一上午没找到，但是加了五个数据分析讨论群，每个群里都在问：

• 有没有数据分析高手？

• 有没有HR行业的数据分析师？

• 有没有HR方面分析的书，最好PDF版的？

• 急！可付费！在线等！

问，以上四个同学，哪个能及格？

显然，以上四个都不合格哈！

不合格不仅仅因为他们说的都是空话、废话。

更因为他们都犯了同一个问题：就数论数，脱离过程。

作为HR经理，想听到的建议是：

• 建议1：早点出门。

• 建议2：该打车就打车，省那钱干啥。

• 建议3：犯了错就认罚，哭有屁用！

作为李芊颖小妹妹，想听到的建议是：

• 建议1：减少给李芊颖同志的工作量

• 建议2：由于李芊颖同志住得太远，建议多批几天特例

• 建议3：上个月李芊颖同志太辛苦，建议免于处罚

看到区别木有，无论是业务方的领导和下属，都不关心具体的数字是什么，更不关心得出数字的模型是什么。他们关心的是可以做什么。做的事情要有依据，能服人就更好了！所谓建议，是业务部门可以做的一个具体动作。这个动作和业务工作流程有密切关系。要能够达到一个大家认可的结果。

所以在推导建议的时候，不要单纯在数字上纠结，特别是不要在类似题目的这种“结果数字”上纠结。单纯纠结结果，就会变成“你说我偷懒，我说我没懒”这种小孩磨牙式争吵。要想办法深入到问题发生的过程中，才能找到答案。

联系到具体过程，我们就能发现：数据对于量化过程、锁定问题有巨大帮助。

比如最简单的一个建议：“早点出门”，听起来是个理，实际上至少存在三个漏洞：

1、早到几点出门不清楚，6点？7点？8点？空口说“早点出门”跟没说一样，需要量化。

2、有没有特殊原因，不清楚。很有可能小姑娘哭得梨花带雨的：“人家前一天加班到半夜，第二天起不来很正常吗！！！要求正装出席，出门前化妆不很正常吗！！！又要人家忙又怪人家，呜呜呜”……不区分具体场景的量化，根本说不服人。

3、特殊原因真的假的，不知道。鬼知道她是真在忙，还是前天出去嗨到半夜去了。

更纠结的是，可以直接推导出答案的数据可能是缺失的。你又不是人家男朋友，你怎么知道人家前一天晚上是出去嗨了还是加班了。没有直接证据的情况下，就得一步步来：

• 先清理出来可用的数据，建立一个基本分析框架

• 再看怎么挖掘具体场景，排除异常情况

这样才能做到有理有据，以理服人。

第一步，先搞清有什么数据可以用。

通勤这件事，我们其实并不需要那么多隐私信息：

第二步，建立基础的分析框架。

基础的分析框架中，不考虑各种意外情况、特殊场景，就看业务最基本的数据逻辑。

比如通勤这个事，只要选好了起点（李芊颖住的小区）终点（公司），打开高德地图都能看到：

• 距离多远

• 坐地铁需要多久

• 坐车需要多少钱，需要多久

有了这些基本信息，就能判断出来：这个距离是否真的太远，从而剔除很多借口/猜疑（如下图）：

第三步，讨论可以量化的特例。

不要一看到小姑娘漂亮就想八卦人家的隐私，除了引发争吵外没啥好处。先把能收集到数据的，明面上的问题，比如加班、打车算清楚。这样一来能看到：是不是真的分工不均，委屈别人了；二来也能堵住找借口的嘴（如果确实没加班的话）。

第四步，推导建议。

有了以上的铺垫，推导建议就能有理有据了，而且非常具体（如下图）：

当然，上边只是一个逗比的小例子，但是清晰地反映了现实中问题：

• 业务部门往往处于本位主义思考，提的建议都是对自己有利/自己想表达的，懒得顾及事实，更懒得细致分类。

• 数据部门往往陷入数字游戏，过于关注数字计算，忽视业务过程，最后就数论数，止于数字。

这样都是不利于得出正确的结论和建议的，最好的做法，就是从过程出发，层层推进，构建起逻辑树。然而这两年算法模型概念广为流传，一下让业务方和数据都以为，只要LR，CNN，XGBOOST呼啦啦往上怼，电脑就能开口说话：“李芊颖呀，我是全知全能的阿尔法大狗子，这个月迟到都怪你自己哦”……于是就惹出更多笑话了。

当然，这些都建立在一个基本前提上：你得能分清看到的是结果数据还是过程数据。曾经有个同学问陈老师：“老师，我要如何提升策略性思考能力，你看我们现在明明一切做得很好，可转化率就是上不去，为啥嗯？”

答曰：你们现在就是李芊颖呀，嘟着粉红小嘴一脸委屈的：“我明明每天很积极上班了，可咋就是迟到了呢”……想找到答案，光纠结结果没啥用，得深入过程中哦。

所以不要单纯地堆砌数字，或者摆一堆圈圈框框，具体问题具体分析才是正道。