数据分析的 8 个状态
共 2707字，需浏览 6分钟
·
2021-08-01 19:46
看了刘思喆老师写的「数据分析师的生存手记」，其中把数据分析的工作流程分成 8 个状态，我觉得很有启发。
下面谈一谈我对这 8 个状态的理解和思考，为了方便理解，我修改了原文中一些状态的名称。
1. 新的需求
数据分析工作流程的第 1 个状态，就是忠实地记录新的需求，纯粹地站在需求方的角度，不加任何评判地收集原始的需求。
这个状态借鉴了 ORID 焦点讨论法的第 1 步，也就是真实地记录客观的事实。
关于 ORID 焦点讨论法，我从网上查了一些相关资料，看到下面这个例子，感觉比较恰当。假设昨天晚上在下班的路上，我遇到一条狗（O 事实），当时我很害怕（R 感受），心想应该怎么办（I 思考），为了避免被狗咬，我最终决定绕路走（D 决定）。
2. 需求确认
需求确认是分析任务成败的关键，针对不同的情况，应该采取不同的对策。
第 1 种情况：需求方无法清楚描述问题。
刘思喆老师说，这类需求方的专业技能不合格，会祸害上下游，「fire」掉就可以了，绝对不可以手软。
关于「fire」这个英文单词，有「开除」的意思，不过我理解刘思喆老师在这里表达的应该是「拒绝」。
对于一般的数据分析师而言，需求方可能就是自己的老板，恐怕没有「开除」的勇气。遇到这种情况，我个人建议加强沟通交流，主动多问一问具体情况，搞清楚需求方的真正意图。
第 2 种情况：需求方将很多问题混杂在一起。
这种情况非常普遍，数据分析师需要应用 MECE 原则，帮助需求方梳理业务，变成相互独立、完全穷尽的问题，并了解其中的主要矛盾和次要矛盾。
第 3 种情况：需求方无法和数据进行映射。
这种情况也相对比较普遍，一般企业是通过「角色前置」来缓解这个问题，比如设置「产品经理」的岗位角色。不过有的时候，前置的角色可能不合格，这就需要数据分析师在「数据确认」环节给予专业的建议。
第 4 种情况：需求方提出了错误的数据需求。
想象一下，数据需求本身就不对，你作为数据分析师，居然漂亮地执行完成了……结果需求方不满意，又提了一遍，后面可能还有第三遍……最终需求方可能很不满意，数据分析师吃哑巴亏。
当出现这种情况时，建议数据分析师在执行之前，先进行合理的沟通，指出数据需求本身的不当之处。
第 5 种情况：需求方无法预判可能的分析结果。
这种情况很正常，毕竟很难碰到非常完美的需求方。我认为此时数据分析师应该多一些包容和理解，多站在对方的角度看问题，自己先学会预判，然后再帮助对方学会预判，为对方排忧解难。
假如遇到需求方不仅掌握业务和数据之间的关系，而且懂得利用数据分析的结果，来指导下一步的行动，那么数据分析师应该好好珍惜。
3. 数据确认
当需求确认清楚之后，接下来需要确认数据源，可能会遇到 3 个问题。
第 1 个问题：期望的数据没有存储。
作为数据分析师，如果你能帮助改善这个问题，让企业的数据更加完备，那么你的影响力将会得到提升。
第 2 个问题：数据分散在不同的位置。
在传统企业，这个问题非常普遍，可能还没有建立数据仓库。对于互联网企业，这个问题体现了数据仓库设计的不完备。
如果不是经常性的问题，临时解决即可。如果是经常性的问题，建议数据分析师主动了解底层的数据逻辑，编写自动化的代码，在可能的情况下，交付给数据仓库团队。
第 3 个问题：数据源错误。
这个问题非常致命，如果数据源不对，后面的分析结果可能造成误导，让需求方做出错误决策，后果不堪设想。
所以，数据分析师提高数据敏感度也很重要，在做数据分析之前，一定要先确认一下，数据源是正确无误的吗？
4. 实现中
在需求实现的过程中，数据分析师要管理好自己的分析代码。
以 Python 为例，尽量使用 Numpy、Pandas、Matplotlib 等比较成熟的包，用 Git 做好代码的版本控制，特别注意代码注释和提交信息的可读性和完整性，让数据处理的每个步骤都清晰易懂。
另外，配合使用 Jupyter Lab 之类的工具，能大大提升数据分析的工作效率。
一方面，我们要把好的经验和方法，沉淀为固定的流程步骤，实现工作的流程化。比如一个数据报表，用怎样的格式和规范，读者容易抓住其中最有价值的信息？
另一方面，我们还要实现流程的工具化。因为总有人会「偷懒」，总有人会逾越流程，总有人会偷偷地绕过流程。所以，我们要适应用工具来辅助流程的执行。
如果流程工具用起来不适应，怎么办？
华为早年引入集成产品开发 （简称 IPD）的流程，大家刚开始也不适应。
任正非说了一句话：先僵化、后优化、再固化。
5. 交付
突出主要分析结论，这是数据分析交付的重要内容。
如果分析没有结论，就不能称之为交付。
交付的内容，包括文字、表格、图形等要素。文字表述要条理清晰，表格制作要标准规范，数据可视化的图形要选择合理。
6. 复盘
很多数据分析工作，最终停留在「交付」这个状态，数据分析师交付结果之后，往往没有去跟进后续的效果情况，没有对分析的价值进行判断，没有进行复盘总结。
交付之后，不妨思考一下，我们通过数据分析，帮助需求方做出了哪些正确的决策？给企业带来了哪些价值？与当初预期的目标相差多少？关键因素有哪些？假如重新再做一遍，怎么做才能做得更好？
在复盘总结的过程中，可以锻炼数据分析师对业务的理解能力和对价值的预判能力。
7. 等待
当你发现目前还不具备分析的条件时，那么可以选择等待一下。
比如说，当需求还没有确认清楚的时候，应该等待需求方有空的时候，把需求沟通确认清楚。当缺少必要的数据源时，因为巧妇难为无米之炊，所以也需要耐心等待。
当然，在等待的时候，可以先思考一下大致的分析方向，以便让后面的实现过程更加快捷。
8. 拒绝
当需求肯定无法实现的时候，要明确地予以拒绝，不要给人模棱两可的答复，此时要避免让需求方有很大的期待，结果因实现不了而导致失望。
最后的话
本文总结了数据分析工作流程的 8 个状态，
为了避免被贴上被动、低价值、重复劳动的标签，数据分析师要主动完善自己的工作流程，优化自己的工作状态。
最后，我把数据分析的 8 个状态之间的流转，用一张流程图串联了起来。
以上，希望能够对你有所启发。
相关文章：数据分析学习指南V2.0
关注林骥，更多干货早知道。