关注并将「人人都是产品经理」设为 ★ 星标
每天早上更新，与你一起成长
在数据分析中，如何提出有效的策略性建议？本文通过一个简单的例子，展示了如何运用数据思维，深入挖掘问题背后的原因，并提出具体的、可操作的建议。
你不要光报数字！要做策略性思考！要提出可行的建议！
很多做数据的同学都被领导、同事这么吆喝过。然而，什么是策略性思考？？？往往一听到这种词，就有同学急不可耐地掏出《麦肯锡方法》之类的镇山法宝，或者在网上搜《底层思维》、《核心逻辑》、《分析框架》之类的文章。
结果除了“裂变”“痛点”“颠覆”这些似懂非懂的词以外屁都没有记住，下次写报告还是继续同比、环比、三年比，低了要搞高……
咋办？!
看个简单的例子，今天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：上个月李芊颖同志太辛苦，建议免于处罚。
看到区别木有，无论是业务方的领导和下属，都不关心具体的数字是什么，更不关心得出数字的模型是什么。
他们关心的是可以做什么。
做的事情要有依据，能服人就更好了！
所谓建议，是业务部门可以做的一个具体动作。这个动作和业务工作流程有密切关系。要能够达到一个大家认可的结果。
所以在推导建议的时候，不要单纯在数字上纠结，特别是不要在类似题目的这种“结果数字”上纠结。
单纯纠结结果，就会变成“你说我偷懒，我说我没懒”这种小孩磨牙式争吵。
要想办法深入到问题发生的过程中，才能找到答案。
破题的思路
联系到具体过程，我们就能发现：数据对于量化过程、锁定问题有巨大帮助。
比如最简单的一个建议：“早点出门”，听起来是个理，实际上至少存在三个漏洞：
早到几点出门不清楚，6点？7点？8点？空口说“早点出门”跟没说一样，需要量化。
有没有特殊原因，不清楚。很有可能小姑娘哭得梨花带雨的：“人家前一天加班到半夜，第二天起不来很正常吗！！！要求正装出席，出门前化妆不很正常吗！！！又要人家忙又怪人家，呜呜呜”……不区分具体场景的量化，根本说不服人。
特殊原因真的假的，不知道。鬼知道她是真在忙，还是前天出去嗨到半夜去了。更纠结的是，可以直接推导出答案的数据可能是缺失的。你又不是人家男朋友，你怎么知道人家前一天晚上是出去嗨了还是加班了。
没有直接证据的情况下，就得一步步来：
先清理出来可用的数据，建立一个基本分析框架
再看怎么挖掘具体场景，排除异常情况
这样才能做到有理有据，以理服人。
答题的顺序
第一步，先搞清有什么数据可以用。
通勤这件事，我们其实并不需要那么多隐私信息：
第二步，建立基础的分析框架。
基础的分析框架中，不考虑各种意外情况、特殊场景，就看业务最基本的数据逻辑。
比如通勤这个事，只要选好了起点（李芊颖住的小区）终点（公司），打开高德地图都能看到：
距离多远
坐地铁需要多久
坐车需要多少钱，需要多久
有了这些基本信息，就能判断出来：这个距离是否真的太远，从而剔除很多借口/猜疑（如下图）：
第三步，讨论可以量化的特例。
不要一看到小姑娘漂亮就想八卦人家的隐私，除了引发争吵外没啥好处。先把能收集到数据的，明面上的问题，比如加班、打车算清楚。
这样一来能看到：是不是真的分工不均，委屈别人了；二来也能堵住找借口的嘴（如果确实没加班的话）。
第四步，推导建议。
有了以上的铺垫，推导建议就能有理有据了，而且非常具体（如下图）：
回到现实工作
当然，上边只是一个逗比的小例子，但是清晰地反映了现实中问题：
业务部门往往处于本位主义思考，提的建议都是对自己有利/自己想表达的，懒得顾及事实，更懒得细致分类。
数据部门往往陷入数字游戏，过于关注数字计算，忽视业务过程，最后就数论数，止于数字。
这样都是不利于得出正确的结论和建议的，最好的做法，就是从过程出发，层层推进，构建起逻辑树。
然而这两年算法模型概念广为流传，一下让业务方和数据都以为，只要LR，CNN，XGBOOST呼啦啦往上怼，电脑就能开口说话：“李芊颖呀，我是全知全能的阿尔法大狗子，这个月迟到都怪你自己哦”……于是就惹出更多笑话了。
当然，这些都建立在一个基本前提上：你得能分清看到的是结果数据还是过程数据。曾经有个同学问陈老师：“老师，我要如何提升策略性思考能力，你看我们现在明明一切做得很好，可转化率就是上不去，为啥嗯？”
答曰：你们现在就是李芊颖呀，嘟着粉红小嘴一脸委屈的：“我明明每天很积极上班了，可咋就是迟到了呢”……想找到答案，光纠结结果没啥用，得深入过程中哦。
所以不要单纯地堆砌数字，或者摆一堆圈圈框框，具体问题具体分析才是正道。
题图来自 Unsplash ，基于 CC0 协议
