资料可以是资产、也可以是负债。

当组织积累了太多无用、甚至错误的资料时，资料不但不能提供价值，反而需要花更多力气与时间去储存、除错、整理它，变成了负债。

为了让资料能更好的被使用、更快产生出价值，一份 DataOps 宣言由此诞生。

透过第一手在组织、工具、以及产业中与资料工作的经验，我们发现更好的方式来开发以及交付分析成果及分析工具，我们称这种方式为 DataOps。

承袭了敏捷宣言对软件业的目标以及影响，DataOps 宣言提出了五个重要的价值：

• 个人与互动重於流程与工具
• 可用的分析重於详尽的文件
• 与客户合作重於合约协商
• 实验、迭代以及回应重於大量的前期设计
• 跨部门的营运所有权（Ownership）重於独立的责任。

现今的资料产品和软件开发脱不了关系，前面三则是和敏捷宣言一模一样，就不再多做解释，将目标放在後面两条，这也凸显了资料产品和一般软件开发不同之处。

实验、迭代以及回馈重於大量的前期设计

在做软件开发时，很少会听到「实验」这个字眼，但实验对於资料产品开发来说是不可缺少的部分。这几天来一直在说明一个观念，「资料产品必须由下至上逐层叠起」，这个特性让上层的资料产品需要更长的开发以及迭代流程，同时资料产品往往又很难模拟，需要靠真实的**「上线」**才有办法得到真实的反馈，这也是资料产品在开发中的最大风险来源。如果最後发现无法解决问题，也不太能轻易地打掉重练，因为下层的资料产品又会和其他系统牵扯、甚至被其他的资料产品所使用。

这时候「实验、迭代、取得回馈」就变得更为重要。

理想上希望透过小规模的 POC，在不影响到其他现有产品的情况下，快速打通各层资料产品後，透过 A/B 测试或金丝雀部署上线观察状况。透过这样的过程快速取得使用者反馈，看看是不是少了什麽使用者行为没有收集到、模型的选用上是不是有更好的做法等等，会比前期设计来得重要的多。

跨部门的营运所有权（Ownership）重於独立的责任

资料产品比其他软件更特别的事情就在於跨部门营运了。举个简单的例子，如果一个电商公司依据营运功能分成业务、行销、IT 三个部门好了，IT 会主要负责电商网站的开发和维护，业务跟行销会跟 IT 提相关的功能需求，业务负责业绩、行销负责让更多人来使用网站，那在这个分工下问题来了，「资料产品要归谁管？」

业务和行销提需求，IT 负责建立网站、设计 Table Schema，使用者透过行销操作导入到网站，资料被蒐集下来後进入资料仓储，接着又被行销和业务拿去做业绩报表，网站上还有自动推荐系统。可以看到资料从「需求」开始，就在各个部门、甚至使用者之间穿梭来往，每一层的资料产品也会互相影响，非常不适用传统一刀切的分工方式。

因此资料产品会比其他业务更讲求「跨部门的 Owenership」，亦即在资料产品中牵涉到的人和部门都需要对这个资料产品负责。有些公司会另外成立专职的资料团队来处理这些资料，实务上资料团队也需要持续跟各部门保持紧密的合作。

References

https://dataopsmanifesto.org/en/