作者
CaptainMilo
首先得说，以下内容应算作认知型总结。虽然不拿数据说话是职业大忌，但是我推崇在碎片化阅读场景里，要获取认知感而不是严谨的知识。
另一方面，从最后的结论可以看到，我倾向于认为，这是一个总体走向消亡的行业，所以无意再拿数据制造“真实的假象”，提高所谓的职业焦虑感。不过有一点需要诸君了解的是：
“消亡”未必是结束，也可能是新生。
01“数据分析”岗形成原因
“数据分析”这个岗位的形成，大概有这么两个场景的助推：
用户端从消费功能到消费数据企业端面临流量封顶，伴随精细化需求举两个例子说明：一是刷不断重复的信息流（内容消费）、吃突然走红的零食（生活消费）、用脸借钱还不用额外征信（金融消费）；二是一个用户吃了我的外卖，我还要让你打我的车，去睡我的酒店。
我个人是从第二个场景入行的，而今随着大数据和人工智能技术的演进，赋予了数据的存储和使用的能力，于是企业主要面临两个问题：谁来承担数据分析职能？如何衡量数据分析效益？
02数据分析工作的分类
为了说清这两个问题，要看看现实中数据分析究竟在做什么，和不能做什么。依然是讲我所接触到的，先看工作分类：
以产品为主体一般存在于单一产品或多产品单一业务生态的公司。数据分析的核心是面向产品建设的，toC多是用AARRR等产品模型做用户分析（用户分层、用户行为、用户运营），toB多是用统计原理辅助功能模块验证和迭代。
以组织（事业群、集团公司）为主体一般是多个业务生态的公司，分为商业分析、策略分析、战略分析三大部门。商业分析分为经营和财务两条线，由于结果对上负责，最容易沦为“表哥”和“跑数的”；策略分析我见过运营策略和安全策略，多用业务经验做事，好一点的可以运用一些算法结构化策略，差一点的就是凭借资历“拍脑袋”；战略分析接触最少，只知道会分析行业和公司目标，多是咨询行业出身或是多年的业务大牛。
还有一种家喻户晓的分类，但我略有不同见解：
业务向我个人的判断是，是否对绩效负责，是否参与一线，是否部门间协调做事多而自己独立做事少。并不存在不会技术就是发展业务向，除非这个岗位设定还比较初级。值得留意的是，这种一线业务、小步快跑的环境中，在其他职业可以用“排期”作为理由合理安排自己的任务时，数据分析没有像产品生命周期、软件设计理念的行业共识可用，只能被迫快速出结果，几乎没有实践和修炼各种技术的空间。
技术向一般对抽象的目标负责，利用ETL、机器学习建立模型，为上下业务部门提供用例。我刚工作的时候这种分析师比较稀有，只能由程序员转型或者肯自学的初级分析师自我拓展。目前观察到的是，大批计算机科学相关专业的硕士及以上学历的职场新人，一出校园直接承接这个岗位的大量需求，于是技术业务脱钩的现象更严重了。
这就是我想探讨的一个核心现状：数据分析的技术与所服务的业务正在逐渐分离。
03数据分析技术和思维模式
探讨“技术业务分离”的现象，基本就触到数据分析职责的局限性所在了，先从硬性技术说起：
Excelv.s.Python说起来，一个办公软件和一门编程语言原本没有可比性，但是去调查各大招聘源的职位描述，会发现Excel+SQL是标配，你在各大数据分析教程上学到的“Python数据分析”，顶多只是加分项，假如不是强结构化数据领域（如金融征信）的面试，连考都不会考你。起初我找工作时，也是如此一脸懵逼的。
个中原因我的猜测是，一开始的数据分析内容，多是产品经理和职能部门的职责溢出，加上彼时还是以“数据孤岛”为主要生产环境的小数据时代，看个短周期变化率就好，几乎不做长周期规律的探索。而新设专职岗位后，一般还是会以这些过渡的人员来面试，或以他们做过的事情来定义岗位职责。久而久之，选拔标准就这么继承下来了，正如“梅西”若出生在我国，也会因为个子矮而踢不上球一样让人无语。
关于被技术拖累，我亲眼见过同事用Excel捣鼓千万条数据时，打开文件速度如拨号上网时代浏览网页。且每个操作完就需保存一次，因为多次巨量缓存会使软件突然崩溃，只得重启；也亲眼见过同行分析师用Excel做线性回归，因为无法加入微参数修正局部，只好充入假数据使结论看起来可解释。
不过效率和处理方法都不是核心，我要说的是视野：Python提供面向对象的处理技术是让你对数据的印象更加还原真实生活。你知道自己模拟了人类生活，不会把因果分析就简化为有因必有果，所以你会考虑看到一群人聚集的特征是促销，多群人聚集没准就是疫情下的挤兑呢，别再看到销售指标上涨就给运营提策略：我们要提价提价提价！
但是回到现实，还是上面这个疫情例子：你在一个典型商业模式的互联网公司，你有一个做Excel出身的增长老大，现在你另一分析师同事看到短期销量上升，认为涨价赚钱机不可失，而你做了长周期销售时序分析，发现业务是首次出现这个幅度的上涨，想申请时间和资源去分析竞品的历史提价，看看流失用户的相关性与这个周期的购买率是否显著相关，以避免不可挽回的远期流失风险——机智如你，觉得你的老大会采纳谁，公司又会采纳谁？
SQL+PPT，你甚至可以创业开一句玩笑话：如果拿“柱饼线图”包装一下表格里存在的数字也叫可视化分析的话，你还真可以拿这些PPT去试试toSBvc了。
简单地说，有免费的图表展示软件无脑用就是了，或者matplotlib+seaborn+pywidget做可交互也是很香的！数据库数据不过是大一点的“数据孤岛”，用研问卷怎么评分标准化，竞品数据怎么爬取，这些考虑都该在如何把图表做的好看之上，如果天天左手一百行SQL，右手PPT，那是数据建设部门的“懒政”，不是你应该把SQL当做编程去研究的理由。
从硬性技术上，看得出数据分析工作具有针对性，仿佛用技术解决问题的转化率可以很高。这正是前文所讲的“局限”出现了，它的软性技术——思维模式，根本不允许在局部环节使用，所以最终实际落地常常一地鸡毛，做技术和做业务的两拨人不得不分道扬镳，各自自保。
下面提供我工作时的方法论，可见一斑：
数据闭环（输入、输出、反馈调节）老生常谈的词，实现难度在基本素质和部门协调上。首先，输入讲究来源的普适性，不仅可以接入数据库结构化的数据，也可以接入爬虫爬取或者人工上传的数据，这就需要设置具有一定的标准化处理能力的接口；输出讲究可解释性强和“黑箱操作”，接到的输出结果一定是可执行的行动或者可以看出问题的报告，处理数据的流程也需要是既定的，不允许非数据分析师人员的干预；同时“黑箱操作”使得反馈数据变得可信度更高，可以依此在下次迭代时修改变量。如果不热衷于获取反馈调节的数据分析师，就得不到任何业务素养的积累，堪比“跑数机器”——但是再问一问机智的你，让业务方提供可用的数据反馈？你觉得，一个甲方有多大程度会考虑配合乙方呢？
驱动决策“99%公司不可能实现之痛点”，实现难度在话语权上。数据分析价值应该是提供/修改/拓展决策，而不是解释决策——不好意思，现实中这工作多半是解释决策，诸如今天下雨了所以卖得不好了，领导有私人目的了让你提个数支持一下等等。
一个决策的成功是实施的功劳大还是策划的功劳大？不直接参与盈利，如何取得话语权？不取得话语权，如何产出工作价值？这就成了先有鸡还是先有蛋的问题了。
直接放我的驱动决策的成功案例：我做过一个运力策略给公司带来每月上百万的当期净利润，有不同事业群的四个部门十多名员工通力配合我，线下团队几百人每周都在执行流程和反馈数据给我用来修改策略，而我职级普通，没有任何管理权。为何能做到呢？
独立在三点：
开放式命题分析，完全没有先例、没有方向、没有资源的三无任务。我通过历史数据回溯大胆提出假设，和快速学习运筹学知识来定位方案。而方案，算法，流程，各个环节其他人都缺少知识和经验去评价，只能看我秀操作，插不上嘴。在算法部门给不出方案，开发部门解决不了时间复杂度的情况下，我自己编写模型和重构算法，把一个可能被权威人士“拍脑袋”、“攒经验”式的策略（没有第一点的环境，一般数据分析基本止步于此）做成了靠算法运行、数学理论支持、让数据在运行中去反哺修正参数的策略。基于以上两点，在阶段性成果和收益分析上也只能我来做，所以这几百万利润里算法贡献多少，运营SOP贡献多少，线下地推又贡献多少非常明晰，不存在让部门角力的机会。但这样的案例可遇不可求，没有领导的存心刁难，没有自己刻意挑战自我，是不会有柳暗花明的结果的。
怎么证明这个可贵不是我主观评价呢？在我多次面试经历中，这个项目没人会质疑盈利百万，因为听过具体实施规模的，去保守估计下也是这个数。而是几乎都质疑，我一个人主导项目，并且能在两三个月内做的出成果来。因为在大公司往往面临部门内耗、以上治下、以及螺丝钉工作制，无法与数据分析的软性技术——也就是以上两个方法论组成的思维模式所相适。
自动化成熟策略要试图用代码构建可复用的产品，脱离线下手工。这也是个人工作哲学吧，程序设计带给我的灵感受用无穷，希望这一点以后能成为数据分析的范式。