大家经常找我感慨：“忙来忙去，感觉都是常规数据报表，连个拿得出手的项目都没有！”那到底高质量的数据分析项目该咋做？
怎样算高质量
想回答这个问题，得先明确：啥叫“高质量”项目。从本质上看，数据分析是个支撑型岗位，工作质量高不高，主要由被服务的部门决定。如果是在企业里工作的话，主要看管理层/业务部门的评价意见。如果在面试时，则主要由面试HR/用人领导评价。摸清对方的需求，击中对方的痛点才是关键。
经常有同学在这里犯迷糊，觉得：用了线性回归模型的（复杂的模型不会）/图表blingbling闪光的/查一个数sql 写了2000行的，才算是“高质量”，忽视了这些玩意对业务到底有没有用，结果自然是闹笑话了。
前几天还有个同学急匆匆来问，说他们建了流失用户预测模型，结果运营表示：“你们搞这干啥？预测了我也不知道咋用！”然后项目就黄掉了……这就是典型的闭门造车结果。
那要怎么弄，才能切中业务痛点呢？
找准核心需求
数据分析对业务，是个“随风潜入夜，润物细无声”的事，往往有数据看的时候大家不觉得很厉害，但是没数据看了，就有人会着急。
所以想找到业务的痛点，最好不要强行推销：“我有一个人工智能阿尔法大狗子模型，百测百准，客官您要不要试试！”而是先看，对方部门最关注什么问题，最缺什么数据。
常见的缺数据的情况有四种：
1、基础数据都没有，迫切想看到数
2、有数据但不知道怎么解读，干着急
3、有数据，有解读，想进一步验证想法
4、有数据，有解读，想进一步做预测
接业务方需求的时候，一定要清晰真实需求。比如“用户画像”，可能上项目时就是嘴上一说，到底是业务不清楚用户现状，还是想基于画像做啥动作，一定要了解清楚。项目开始时不清晰，中间过程也要逐步清晰，不然哼哧哼哧打了一堆标签再被人质疑“你这有啥用！”那就是哑巴吃黄连了……
报表型项目的要点
报表型项目数量最多，但最容易被数据分析师们忽视，很多新人总嫌弃它技术上不复杂。但实际上，报表型项目是最容易出成绩的，关键在于：做领导们关心的，领导们看得见的。接需求的时候，区分报表使用人，优先把领导们需求做可视化，让领导们直观感受到数据。
并且，通过报表型项目，可以有效鉴别业务方合作态度。如果业务方态度好，那么可以深入合作。既然已经有了业务监控报表，那么下一步就可以做业务走势异常分析。
先记录非业务主动行为产生的异常点，之后再深入分析：
- 多大幅度变化算异常
- 是什么因素导致的异常
- 如何通过数据提前发现异常
有了这些积累，就可以进一步做自动化异常提醒+问题诊断，让单纯的数据展示更上一层楼，同时能为后续深入分析打好基础。
分析型项目的要点
在很多人原始印象里，数据分析就应该是拿到一堆数字，然后般若妈咪哄一通分析，告诉业务三句话，让业务多赚18万！因此往往人们对分析型项目期望甚高。
但实际上分析型项目特别容易踩雷。对业务不够了解，缺少监控数据，缺少异常分析的经验，都会让问题分析流于表面。做项目时“雷声大、雨点小”是常态。
因此，分析型项目在报表型项目基础上孵化出来，成功率比较高。如果发现业务方对问题本身监控不足、认识不清，可以退回到报表型项目做起。有了一定积累后，想见效，最好的办法是先共识业务假设，搞清楚业务方到底对啥没信心，对啥有信心。证伪比证真容易，直接验假设更容易出结果。
如果问题涉及太多难以量化的疑难杂症，还有个解决思路，就是把问题转化成测试型项目。直接看业务方手头有什么解决问题的办法，然后测试哪种办法管用。这样也能输出解决问题的方案。
测试型项目的要点
测试型项目相对容易成功，本质上看，测试也属于“业务没数据，特别想看个数据”的情况。只不过要注意的是，到底要测啥，得事先想清楚了。在测试中最重要的就是：对影响结果的因素有前期了解，测试想测的关键因素，控制其他干扰项。
因此，一般页面设计测试容易成功，对消费结果测试容易乱套。因为页面设计测试点少，容易出准确、稳定的结果。但影响消费结果的因素太多了在做测试之前没想清楚，很容易因为测试方案之间可比性不高，参与测试群体差异大，关键干扰因素没排除等原因导致结果失灵。
所以，在做测试前，基础分析工作是很必要的，梳理清楚到底哪些因素会有影响，几套测试方案之间差异点到底有多大，能有效提升项目质量。
预测型项目的要点
预测型项目的关键在于：确认真实的预测需求，避免盲目赌命式的“我要100%精确”。不但做不到，而且没意义。
比如开篇讲的流失用户预测，如果运营是全量投放资源召回流失用户，那把目标改成预测：“哪些人自然会回流”这样就能节省经费。如果运营想获取最大效果，可以把目标改成：“用户预计响应哪种方式的召回”这样可以做多轮推送最大化唤醒用户。
总之，先搞清楚运营的计划再下手，比自己闭门造模型管用得多。
