“数字化转型” 这个词想必大家并不陌生，那么作为一名数据搬砖工注定要解决的那就是"落地"的问题。在实践的过程中可谓是收获满满，那么就针对个人所在的项目做个简单的总结吧。
主数据PS：不足之处欢迎大家指正。
作为一名 RD ，每天无时无刻不在和数据打交道。主数据、基础数据、事务数据、业务数据等大家并不陌生了。这里还是非常有必要说一下"主数据"，其实对于主数据系统的建设和管理已经有很多成熟的方案值得大家参考了。
主数据噩梦主数据问题，是一个比较吐血的问题。主要表现为以下几点：
数据入口多，重复录入、一物多码、多码一物；组织内不能就一个主数据源达成一致；数据质量问题引发的业务流程的失败；不正确或丢失数据造成合规性和绩效管理的问题；决策者做出基于错误数据的错误决定。 构建并管理主数据
如何构建并管理主数据这里就不提了，对于这一系列问题网上很多博客可以参考。
模型上下游变更没有一成不变的业务、也没有一成不变的流程，数据模型的变更也是时有的。
影响范围评估针对模型变更之前，应对影响范围进行一个整体评估。
策略致胜针对目前现状、制定好的对策，这样被业务方可接受的机会也就越高。
组织流程保障良好的组织流程保障，模型变更前应提前通知项目组或者走 OA。
业务口径的变化对于业务口径的变化，主要表现为以下几点：
业务方试探性的一个过程；需求很明确，业务复杂度高或梳理不全面等导致计算上的偏差；领导临时变化性的决策；数据效果与目标不符，分析效果不够理想。 低成本验证
不管是业务侧还是产技侧，都没有办法一步到位，所以需求是变化的，如何满足需求也是变化的。为了能够更好的应对方方面面的变化，就需要尽可能延迟做不可调整的决策的时间。
对于业务侧的需求，需要经过层层筛选，最终才需要考虑进行系统化实现：
如果能够证明需求是伪需求，那么什么都不需要做；如果需求只需要定性分析，那么不需要依赖数据；如果需求只是偶发的、临时的，那么可以采用线下分析的方式来实现；如果需求的分析方法还未成型，那么可以先用线下分析的方式来摸索；如果需求的分析方法已经基本成型，但不经常使用，那么可以固化线下的分析流程；如果需求的分析方法已经成型，且需要经常依赖分析进行决策，才需要考虑将整个数据分析流程线上化。 从技术到业务
在工程进展中常发生互相推诿扯皮的现象，从而造成无效成本，乃至进度拖延。那么真的是技术方技术力量薄弱又或者是业务方频繁变更需求导致的吗？
规范业务还是规范技术业务抽象程度高、复杂度高，通过技术手段对系统进行改造是比较困难的。不仅需要领导层的大力支持，其改动的周期都会对当前业务产生也可能产生一定的影响。那么怎么做才能最快产生成效呢？这里我认为：规范前端业务最容易在短期内快速见效。
永远对不完的数大多数数据人的现状：查数、对数、查数、对数，无限循环。怎样才能早点下班？
诚信度业务线上的同学对数一定要走心，不能只是形式主义。发现任何问题应及时反馈。
研发对数据负责PS：之前和业务线上的老师对数的时候出现最多的几个词：大概、差不多、整体对的上，着实令我捏了一大把汗。
数据工程师要对自己开发的代码负责、自我校验的流程必不可少，这样才能避免 BUG 的产生。
业务、产技理解上的偏差PS：可别自信心爆棚，最后啪啪打脸。
导致沟通障碍的三个原因：
得到的信息不同：产品同学和业务同学关注的是业务需求，开发同学关注的是一个个具体的需求列表，功能点，是实现层次的细节信息；思维方式不同：产品同学关注业务/需求的合理性，产品逻辑，用户体验；而开发同学关注方案的可行性，实施成本，系统稳定性等；沟通语言不同：产品同学用描述性的语言，语言的模糊会导致不同角色理解的不同；而开发同学习惯使用技术语言。不同角色交流的时候，会因为语言不相容，难以沟通。 如何达成真正的共识(RD角度)
不懂就问，避免走弯路；多以业务方的角度思考问题，理解指标含义及概念；必要的业务沉淀，形成知识库(脑图、Word、Makedown等)。
坚强的信念能赢得强者的心，并使他们变得更坚强。 —— 白哲特
