最近几年，大数据行业的迅猛发展带动了数据分析师需求量的增加。数据分析师迅速成为了求职市场上的香馍馍。
造成一些圈外人认为数据分析就是企业的灵丹妙药，通过数据分析能解决一切问题。产品改版，营销策略，市场定位，战略决策，哪一项不需要数据分析。连战略决策都要靠分析师，能不重要么?
但理想很丰满，现实很骨感。真正做过数据分析的同学一定能体会到，同其他行业一样，分析师在工作中会遇到各种的窘境，导致自己寸步难行，郁闷迷茫。其中有些问题甚至难以改变。
手里没有数据
很多人很奇怪，数据分析师怎么可能没数据呢?全公司的数据都在这个部门啊。实际情况可真不是这样
没有数据主要有三个原因：
一是公司数据体系不健全，缺失很多关键数据。比如某些互联网行业公司，埋点系统有缺陷，很多关键数据抓不到;又比如某些传统行业公司，由于内部系统断层，造成数据孤岛。我就经历过一家公司，CRM系统、财务系统、业务系统各自一滩，数据没有打通，没有形成数据链条，根本没有办法串联起来做分析。
针对这种情况，数据分析师首先要正视现状。数据体系建设，内部系统打通向来是公司的大难题，需要投入大量的资源才能有明显的改善。不要指望很快完成。二是在数据有限的情况下，还是要尽量的提供分析价值，这也是区别分析师段位的地方(你想想，如果所有的数据全到位的的情况，分析师的价值就弱化了)。同时能够清晰说明，由于数据的缺陷导致哪些分析陷入瓶颈。通过有效的反应，推动底层数据逐步完善。
二是组织结构问题，数据散落在不同的业务部门手中。业务部门不愿意合作，不提供数据。这种问题分两种情况处理。如果分析师在公司层面的分析团队，还是要靠公司层面去建立统一的底层数据平台;如果分析师在业务团队，则需要通过部门之间的配合来解决这个问题，在局部范围做数据共享。
三是没有数据工程团队支持，分析师团队的底层数据建设不完善。这种情况，最好的办法就是组建支持分析师团队的工程团队。术业有专攻，分析师和工程师这两个工种还是有区别的。仅从使用的工具方面来说，分析师擅长的是SQL，Python，Excel，BI;工程师擅长的是Hadoop各种组件。所以说专门支持分析师团队的工程人员还是很有必要的。关于这个团队的规模，可视具体情况而定。最不济的情况，分析师就自身提高能力，承担数据工程建设任务，这对于分析师自身的发展也是一件好事。
分析的结果，业务不买账
这也是常遇到的问题。分析师费好大劲做的分析结果，业务却不买账。要不觉得分析结论都是大家知道的常识，没有任何建设性意见;要不觉得分析结论违背常识，分析师只是纸上谈兵，根本不懂业务。
造成这种情况，主要有两个原因，一是分析师确实不懂业务，只是对着数据做各种计算。不懂业务，就难以判断手里的数据是否能够分析问题。并且对于分析结论没有判断力。好不容易找到数据，拿到数据就用，由于对业务不理解，导致对错误结论不敏感，这也是在给自己挖坑。最好的办法，就是和业务“混熟”。先把自己定位为服务，而不是管理。服务前先学习，学习也是为了更好的服务
第二是虽然懂业务，分析结论也还不错，但由于展示方式有问题，导致对于业务的影响力不够。比如分析出广东省销售额不好的主要原因在于没有标杆企业。但对于这个结论的论证逻辑不够清晰，展示不够醒目，给人一种不疼不痒的感觉，这就很难推动业务做出动作。这就涉及到了另一个问题，有结论但并没有把结果”晒“出来。虽然我不赞成PPT文化，但有效的利用PPT把结论展示出来，确实也是区分数据分析师的段位的一个标准。
职业发展受限
分析师的另一个窘境就是职业发展。虽然现在数据分析师这个职业很火，各公司都在招聘数据分析师，且薪酬不菲。但数据分析师是一个典型的入门容易精进难的职业。所以长江后浪推前浪的感觉很强，35岁危机感也会存在，尤其是在互联网行业。这里有两个建议，第一是技术和业务两手都要抓，哪门都不要荒废。分析师基本的工具，Excel，SQL，Python，BI要熟练掌握，这是一个保障。
当然如果对于Hadoop和算法有涉猎，就可以做为加分项了。业务要精通，不懂业务的分析师一定不是好的分析师。并且对于业务的掌握尽量全面。比如从业务场景分为为B端业务，C端业务，从分析模型角度看，比如AARRR，RFM等等。
另一个建议是在一个行业深耕，做这个行业的数据专家。比如金融行业，K12行业，视频行业。做这个行业中最懂数据的，做数据中最懂这个行业的。两方面的双重加成会让路走的更远。
