最好的技术人员解决错误的问题注定会失败和沮丧。然而，我们经常看到伟大的Python开发人员和SQL专家创造出出色的技术，但对业务几乎没有什么价值。在某些情况下，情况要糟糕得多。这些解决方案的价值并不值得商榷，而是耗尽了资源，混淆了业务流程。作为数据工程师，我们有责任充分理解我们的解决方案所支持的业务流程。

作为高级数据工程师，我们应该非常了解业务，我们建议如何提高效率和增强工作。一个大胆的声明，但我会舒舒服服地死在这把剑上，和任何不同意的人战斗。当然，打个比喻，因为我没有剑，与其说是斗士，不如说是个情人。关键是，我们需要了解业务，有一个重要的工具可以帮助我们实现这一目标。

在我们开始之前，读一下朱利安·科维齐克的这句精彩的话，它简洁地指出了问题：

“如今，通过理解底层数据和与之相伴随的业务流程来塑造数据似乎不如移动数据的能力重要。”

他在这里说的是，我们太忙于将数据从那里转移到这里，以及我们可以使用的所有酷的工具，我们忘记了我们首先做这一切的原因。数据工程师从多个来源收集原始数据，并创建可供人和机器有效使用的可消耗软件包。对我们的消费者来说，介于两者之间的一切都是一个黑匣子。为什么我们把大部分时间和精力都花在黑匣子上，而不是消耗性的包装上？

愤世嫉俗的观点会说，这是因为黑匣子是有趣的部分。虽然这可能是等式中的一个因素，但我相信我们中的许多人只是不太了解业务流程，无法有效地将时间花在改进可消费软件包上。让我说清楚。更好地理解业务是你的工作和责任。不容易啊。在一个完美的世界里，我们会有很好的文档可以依赖，但是…嗯…你知道的。这就是我们数据工程工具箱中最重要的工具。

这是什么基本工具？

问题。就在那儿。问题。很多。好的。坏的。尴尬的那些。所有的问题！这对你来说足够强调了吗？你想从好到好吗？问问题并充分理解您支持的业务流程。我怎么强调都不为过，与一个只关心技术的数据工程师交谈是多么令人沮丧，而我是一名数据工程师。想象一下，你是一名财务分析师、人力资源主管或销售人员。他们需要可消耗的数据包，但可能不理解技术术语。除了他们使用的特定工具之外，他们可能对技术知之甚少。

因此，仅仅提出问题是不够好的。相反，我们需要用企业理解的语言提出正确的问题。忘掉表、数据源和主键吧。这些事情来得更晚，往往是由对更多人的更多问题决定的。相反，询问人们在日常工作中做了什么。询问业务目标是什么。工作如何通过各种系统流动。问，直到你完全理解公司使用的业务流程。然后记录下来。

编写业务文档。当然，做这件事是他们的工作，但你才是需要它的人。创建流程图，包括业务使用的任何工具。包括人们与流程交互的地方。然后和业务一起审查，问更多的问题。您可能会发现没有一个人能理解所有的事情，所以您将与几个人交谈并最终统一业务流程。您编写的文档将成为业务中有价值的工件。砰！你对公司来说是无价之宝。我敢说，你刚成为一名高级数据工程师？

已经打包

作为数据工程师，理解我们的解决方案支持的业务流程是我们的责任。如果不充分了解这些过程，我们注定会受挫和失败。我们生活的这个不完美的世界通常没有很好的记录，而我们数据工程师是需要弄清楚这一切的人。通过提出大量的问题，我们可以更好地理解我们的解决方案支持的业务流程，这使我们能够不断改进我们工作的影响。所以，开始吧。质疑一切！