前两篇文章聊得都比较抽象，实诚些的朋友可能都已经没有耐心了：“啥时候能来点干货？”坦白讲，我虽然有几年从业经历，但远不觉得自己能够指点江山、为人师表。所以事先声明，前面的文章算是打打嘴炮，若是要说干货，这篇文章也就只是聊聊我个人经历中的一些偏实用向的体会，但也绝不是“7天教你成为一个优秀的数据科学家”这种所谓的版本答案。
新入行的朋友经常纠结的一个问题是：怎么给我自己的数据技能树加点？不管是学校毕业还是从别处转行，总感觉已经学了一堆东西（或者总有无穷无尽的东西可以学），但也不知道学了有没有用，入行以后也不知道怎么继续升级。说说我自己的一些观察吧：
数据技能树
1-建模
建模能力无疑是数据科学家的核心能力：
建立基于经验数据的数理模型，这个数理模型从一定程度上刻画了世界运作的规律，然后通过求解这个数理模型，我们得到的答案可以帮助我们在现实世界中做出决策
这里的模型可以是统计模型（比如贝叶斯、KDE）、时间序列、机器学习、整数/非整数数学规划、离散事件模拟（DES）、随机过程等等。世界上的问题千千万万，建模方法也多如牛毛。你可以根据自己的兴趣或者工作性质来选择自己想走的“流派”——ML流、仿真流、优化流、贝叶斯流等等（这些名字都是我自己随便起的，你自己起自己喜欢的名字就好）。
有选择困难症的朋友要问了：“有这么多技术方向，我是应该学得越多越好，还是在某个领域学得越深越好？”这一类如何平衡深度和广度的问题，我基本的思路都是：打造T型结构的技能包。就是说，选择一个垂直领域做得越深越好（T的竖），然后在其它领域尽可能广泛涉猎（T的横）。有能力的话，逐渐进化成TT或者TTT也无不可。比如我自己读书时候学的是运筹学，所以走的是优化流，80%的时候用的都是数学规划模型（mathematical programming），但是别的工具也都有接触，要是临时接个锅做个需求预测的项目，我也能赶鸭子上架。
工具方面：在理论基础上，熟知各种Python包是基本操作了。取决于你的专攻方向，可能还会有专用的工具——比如优化建模就绕不开Gurobi/CPLEX。
2-工程
除了对数据模型需要有扎实的理论知识，一个优秀的数据科学家通常也是一个写码的高手。这里有几个不同的方面：
- 快速迭代：建模的过程通常是个实验和试错的过程——试试这些个方法行不行，不行再换一批。这就需要数据科学家能够快速写码、快速更迭、快速意识到自己是傻冒……不能在一个bug上被卡半天。具体来说，就是你debug快不快，代码写得是否足够模块化，代码的容错率是不是够高等等。
- 处理工程问题：理论虽然美好，现实中总有各种稀奇古怪的问题挡住我们的去路。有时候是数据量过大，加载起来太慢；有时候是数据格式不匹配；有时候是服务器和本地不同步。这些繁杂的工程问题几乎每次都会出现，在这方面有经验的数据科学家就可以更加游刃有余。
- 手搓模型：虽然现在各种Python包可以说是层出不穷，但很多时候一个特定问题需要一个特定的模型，市面上未必有现成的，这时候就要手搓模型了，那就是要考验各位的写码能力了。我之前工作中碰到过一个项目，发现需要用Ornstein-Uhlenbeck随机过程建模——这玩意儿光看名字就知道市面上没现成的……也就不得不自己手搓（搞了个破产版的）。
工具方面：需要一个趁手的IDE能够实现所有写码和debug的功能（比如VS Code或者PyCharm）；另外就是熟悉Databricks/Snowflake之类的数据平台
3-协作
在现实工作中，一个人单打独斗搞定一个项目的情况几乎不存在。绝大多数情况下我们都需要和同事合作，要么一起建模，要么有上下游的分工（比如一个人处理数据另一个人建模）。这种情况下，和同事合作的能力就变得很重要了。细微处比如版本管理和代码协作（commit/push/pull…），宏观处比如找到各自擅长的领域进行分工，都是需要积累的经验和技能。这一点尤其是对于新入行的朋友尤为明显——如果是在学校通过上课习得的专业知识，一般都习惯单打独斗，会需要一个适应团队协作的过程。
工具方面：Git
4-讲故事
能把整个数据项目的故事讲得好听其实是一项非常重要的技能。可能大家作为技术人员，往往会觉得：“我把事情做好就行了，不用吹得天花乱坠，那样反而浮夸”。但在现实中，一个项目做得成不成功，本身底子自然重要，但是故事是怎么讲的同样也重要。所谓一图胜千言，有时候一张酷炫的图可以省下无数的口舌。
坦白讲，这一点上MBB确实是行家，一手PPT做的是花里胡哨，让数据模型的结果显得更加令人信服。所以，你想想MBB是怎么忽悠你和你老板的，拿出相同的力气去包装你的数据项目吧。
工具方面：PowerBI/Tableau等可视化工具；善用PPT
技能加点攻略
以上这些在我看来算是必备技能了。那么如何加点呢？
1-建模可以在任何时候无脑按照T型结构加点。这个是吃饭的家伙，永远不嫌少。2-工程和3-协作可以点到够用的程度就行。尤其是3-协作，上手了之后基本就没什么需要深造的了。4-讲故事其实也可以一直加点，因为在整个职业生涯里永远用得上。但是，点得多了容易跑偏，逐渐偏离数据科学家的本职，变得更适合去当领导了。
这里可以顺便说一下AI对数据科学行业的影响。很多人在讨论数据科学会不会被AI取代。在我看来，AI能够造成巨大冲击的主要是2-工程——你可以借助AI快速写出高质量的代码。但是，至少到现在为止，我们依然是需要数据科学家来定义正确的模型的。当面临一个模糊的现实问题时，如何将其转化为合适的定量模型，依然是AI很难取代的数据科学家本命。这就好比，数学家不会因为计算器的发明而被取代。计算器有助于数学家进行计算（就像AI有助于数据科学家进行写码），但真正核心的理论实践，还是需要人来操作。
解锁隐藏技能：做出题者，不做解题者
最后再讲一个我个人认为的高阶技能。我观察到不少小伙伴，前面说到的技能一应俱全，但还是经常深陷数据项目的泥沼，没有觉得自己很“成功”。其中一个很重要的特质是：很多人始终抱有解题的思维，而一个优秀的数据科学家往往是给自己出题出得好的人。
举个例子吧：我之前给一个客户做过中国奶粉市场的品类预测，即整个市场未来几年的体量，其实说到底就是预测新生儿数量。这个预测模型很难做——数据量本来就很有限，说不定还掺了水分（国内相关的数据质量，你懂的），各种奇怪的因素又很多（比如龙年大家好像莫名就更愿意生小孩了）。模型做出来之后，客户也是各种挑刺：有没有考虑这些那些因素，为什么是预测增长10%不是增长12%等等。说到底，要做出一个能用数据支撑、回测准确度高、解释性高的模型是一个十分困难的任务。
于是我们转换了思路，不再解这道“把新生人口预测模型做得更准”的题，而是把题目重新定义为“做个什么东西可以对客户有用”。琢磨了一番之后，我们搭建了一个基于育龄女性+生育意愿的框架，让客户自己发挥。育龄女性基本可以由已有的人口分层进行推断；而生育意愿和受教育程度、收入水平等因素高度相关，可以通过其它国家的数据建立关联。最重要的是，我们不再试图给出一个精准的预测（比如2030年中国新生儿人口会是xx万），而是说：这套框架给你们了，你们可以自己代入你相信的育龄女性数量和生育意愿指数，获得你自己认为合适的估计。毕竟，企业拿着这个预测也不是为了去赌准确率，而是为了有些定量的依据来决定是不是要调整未来的产量，他们也只需要逻辑上说得通（高管听了能相信）、量级上不要差太多就行。
在这个例子里，前面说到的所有技能点我们都已经用过了，还是不足以让这个项目成功。真正点石成金的部分，是定义我们真正要解决的问题。选对了问题，难易程度就天差地别。如果困在解题思维里，那我们就会无限和“预测新生人口”这个难题死磕。很多时候，一些数据问题本身是很难解决的——比如这个例子里预测人口，或者是预测整个金融市场等等——但是我们要创造价值未必需要解决这个问题，而是可以通过解决其它问题来达到目的。我在做优化类项目的时候也经常碰到这种情况：很多时候我们习惯性地想要死磕最优解，毕竟读书的时候解的每道题都是在求最优解。但其实在现实中，只要找到比现有情况更有一点的解就足够了。也就是，“找到一个更优解”的难度要远低于“找到全局最优解”。
从这一点上来说，数据科学其实有非常大的操作空间。我们有各种衡量效果的指标（比如可以直接计算数值预测的准确度，也可以衡量预测偏差带来的经济影响），可以自己选择预测的目标是什么（是离散的还是连续的，是直接用历史数值还是经过处理，比如取一阶差值），等等。在这些诸多选择之中，定义清楚我们真正需要解决的问题是什么，而避开哪些我们很难解决的问题，是一个优秀数据科学家所需要做出的选择。