0x00 前言
问题
数据研发大多数工作都是在提数，如何破局？
话题整理者：未期，某不知名大学透明本科生，GIS背景。画过地图，写过代码，热爱统计。目前在数据科学的道路上缓慢前进，希望与大家共同学习~
问题描述
听上去很高大上的大数据研发工程师/数仓仓库工程师，日常工作很多时候就是给产品/运营跑一下数据，他们要什么我们就提供什么，感觉枯燥且乏味。想请教一下，有没有什么更好的办法，既可以提高工作效率，又可以达到技能上的提升，最好能举几个例子。
0x01 讨论内容
讨论1
vlvd
深入了解业务诉求，想得比对方更深入，避免因纬度不够重复抽取数据
抽象常用数据纬度指标，搭建数仓表，通过数据平台工具配置报表，可以节省一部分常用报表统计
培养产品运营自己提数的能力，脚本写好给她们，他们如果只是改些渠道日期范围，自己改下就好了
主动挖掘业务潜在需求，引用行业专业合理的数据分析统计方法，比他们更早考虑数据变化，提升自己的思考力，业务对你们信任感增强，你可以主导需求，零碎的诉求可能会减少些
提数这个过程是无法避免的，主要看如何把重复工作工具化
讨论2
Qing
培养数据使用方自助提数的能力
提供更好用的中间表
提供更好用的数据提取和分析工具
尽量提高自己在分析方面的专业度，这样，提数类无价值的活就会被安排给别人了
讨论3
搞数据的成为提数工具人是没办法避免的吧，我觉得可以有两个方向发展吧。
固化模型，减少重复工作，业务翻来覆去看的东西应该是差不多的。
发掘新工具，学习下新工具的使用。最近公司用了metabase，帮业务培训下如何使用之后，从很多提数工作中解放了。
讨论4
居士家族：虚线居士
作为数据从业者，提数是最基础的工作，算是了解业务的开始，大家貌似都很排斥提数，我也有那么一点，不过我是个小菜鸡，我还做不到每个提数需求都可以很快很完美的呈现给需求方，我还需要思考，有时提数对我来说还是一种成长（当然这种想法对于多年工作的大佬们可能不太适用）。提数是避免不了的，我们高级经理都还会做这种事情，我们并不觉得提数多低级。只不过长时间工作中除了提数就是提数的话，还是需要尝试改变下吧，和领导沟通工作内容问题，要不就换一份工作（其中换工作可能会有点不好，但是亲身经历，同事基本天天提数，想做别的工作公司领导不给批，后来一组人除了他都忙得不得了，疫情开始就被辞退了）。
讨论5
居士家族：东方居士
古牧兄的观点我觉得挺好的，引用一下：
80%的通用性需求可以固化到产品上；
系统思考提前准备，应对需求方的散点式需求；
避开外行；
站在对方的角度，思考对面会提出什么样的有价值问题。
讨论6
居士家族：憋七居士
我这边和你一样，我提了两年的数，支持过众多产品、运营、分析师、算法、以及各级领导，我来说下我这边是怎么做的：首先不能逃避问题，要去解决问题
前期提数，工作低级，要做的是理解业务，和学习业务逻辑，我觉得这点非常重要，我现在会参与业务产品的指标规划，因为我的优势是给多个业务线出过需求，知道每个业务线看指标的角度，可以给出更合理化的建议，这不光是理解业务，也是在打通你在公司的人脉和话语权
理解业务，沉淀数据，把数据都沉淀到数仓中，这一点也很重要，这就是要用到数据仓库能力了
开放hue或其他查询平台，提供运营，分析师，产品进行数据查询，我们这之前分析师的人要比数仓多好几倍，我们的做法就是开放平台，培训sql，这里需要注意报表权限和资源管控
数据可视化，业务方提需求看数据，是用做数据分析，还是支持工作系统，数据分析、大盘监控，那就开发平台产品；支持其他业务系统数据，那就开发接口，此时需要数据开发的能力
这是我经历的变革，现在数据提取不需要数据仓库的，但是仓库人员一定要紧跟业务变动，配套设计数据治理方案，也随着业务发展改变仓库模型设计。所以我现在可以满足任何一个项目或者需求到我这里，我可以给出合理的解决方案，以及张口就来的业务逻辑，还有ceo要紧急数据，也能完美支持，所以遇到问题，解决问题，不要慌，都有这个过程的。
讨论7
居士家族：影子居士
抗拒提数是很正常的。工作模式上单调乏味，技术上长时间接触同一种模式。同时对业务一知半解。我将工作分为技术和业务两个方向。取数只是技术的很小一部分，但和其它更侧重技术的方向相比，优势在于它会牵涉到很多业务逻辑。想不成为取数机器，如果从技术深挖，你可以开发查询平台(针对常用的多个报表)，沉淀数据，好好利用数仓的优势，同时给业务人员提供SQL培训(巨有用)。上面也说到，数据和业务衔接紧密，如果从业务方面深挖，多和运营产品或者财务交流(不懂就问)，看看他们的模式是怎样的。要知道，技术是实现业务的方式，同时也是业务的保障。
讨论8
居士家族：人造居士
如果仅仅只是回应业务端的需求，提一点数据，当然没有太多的提高，关键是怎样理解业务的核心逻辑，以及如何进一步将这些核心点呈现出来。比如一个线下业务，那么销售人员所提交的有哪些信息？有哪些信息的埋点？需不需要增加/减少？通过这些信息埋点，可以提示我们什么？有没有进一步挖掘的空间？比如产品的品类/销量/客单价之间的分布、关系。又比如渠道之间的产品分布差异有没有提示渠道本身成交的逻辑和方式有差别？这些差别有没有综合或者优化或者相互借鉴的地方？这些可能都需要与业务端反复沟通，才能真正理解业务闭环，进而进一步理解真正的商业逻辑和商业逻辑的实现途径。有了这样的理解，哪怕换一个公司，也是大有可为的。
0xFF 总结
本期讨论来源于数据从业者常有的困惑，参与讨论的朋友们结合自身的不同工作阶段、经验的思考总结给出了非常详尽的观点，下面是讨论内容的简单总结：
强化认知，理解业务和学习业务逻辑
提数作为数据从业者的基础任务，是接触业务的开始。前期的提数工作更重要的是理解数据背后的业务逻辑。面对业务人员提出的需求，积极思考，构建更完善、有深度的分析流程 ，提高自己在工作中的参与感，更完美地满足需求，理解业务闭环 。这无论是对个人成长，还是提高在公司的话语权，都大有益处。
固化模式，将通用性需求移交他人
在对业务有了一定程度的理解之后，总结出一套相对固定的模式来满足通用性需求，移交到业务方或者固化到产品上 ，将自己从大量重复性的提数工作中解脱出来。
沉淀数据，注重数据模型的设计
对于数据仓库工程师而言，要充分利用数据仓库的优势，沉淀数据，抽象常用数据指标，设计出更灵活的数据模型来支持多样性的分析提取需求 。同时，紧跟业务，对仓库模型设计做出相应变动。
发掘工具，开发自助产品
对数据研发工程师，侧重工具的建设。一方面，开发贴近业务相关的自助产品，提供SQL培训，提高业务人员自助提数的能力 ；另一方面，针对业务方提出的不同需求，如果是支持数据可视化、大盘监控，就开发平台产品；如果是提供其他业务系统数据，就开发相应接口。
主观能动，主动挖掘潜在需求
如果一直被动地满足需求，最终不可避免沦为提数工具。在工作过程中，要时刻保持主观能动性，例如：深入思考业务诉求，站在对方角度，提前系统地准备以应对不时到来的零散性需求；培养自己的思考力和发现问题的能力，主动给业务方提供思路，持续跟进效果并给予及时反馈，尽量做到主导需求，而不是被需求支配 。
以上就是本期问题讨论的内容啦！
在本期讨论中：
虚线居士获赠《Python极客项目编程》
憋七居士获赠《商业智能数据分析》
人造居士获赠《实用机器学习》
欢迎大家积极提出问题以及参与后续讨论！
讨论地址，也可以在 阅读全文 中查看：https://t.zsxq.com/FEYvzvf