Почему Data Quality не должен жить отдельно от продукта

Почему Data Quality не должен жить отдельно от продукта 📊 Сходила на Data Decoded в Лондоне - про само мероприятие расскажу отдельно, когда появятся фотографии 📸 А пока хочу поделиться одним из докладов, который мне очень откликнулся. Он был про Data Quality - но не в формате инструментов и best practices, а скорее про то, как вообще устроена ответственность за качество данных И вот что было очень точно подмечено: ➡️ Data Quality часто сваливают на какую-то отдельную команду (например, дата-инженеров или тех, кто отвечает за сбор и доставку данных). При этом: 🔹 бизнес ожидает, что данные уже корректные 🔹 команды, которые строят пайплайны, считают, что их задача - доставить данные 🔹 аналитики оказываются посередине и ловят все расхождения И в итоге возникает тот самый gap Отдельно поймала себя на мысли, что часть Data Quality на самом деле уже существует - просто в другом слое. У разработчиков, например, есть свои технические дашборды и метрики: они смотрят на вернувшиеся статусы, нагрузку, количество запросов, стабильность сервисов. И по сути они отвечают за свою часть качества данных , но это почти не пересекается с тем, как на данные смотрим мы. В итоге получается, что разные команды как будто делают похожую работу, но в изоляции и иногда даже дублируют друг друга 📄 Очень понравилась аналогия с законами Ньютона: 1 если ничего не делать - плохое качество данных сохраняется 2 чем больше накопилось проблем, тем сложнее их сдвинуть 3 если говорить с бизнесом на техническом языке - получаешь сопротивление, а не понимание Но для меня самое ценное было даже не это Я поймала себя на том, что мы обычно делаем Data Quality для себя: строим проверки, дашборды, алерты - чтобы самим видеть, что что-то поехало и уже потом идти разбираться, почему. И чаще всего это выглядит так: сначала делаем дашборд, потом вспоминаем, что нужно бы ещё DQ прикрутить . То есть Data Quality живёт как отдельная задача, а не как часть процесса А идея из доклада - в том, что это должно быть наоборот: 💡 Data Quality - это не слой сверху: это часть продукта и процессов, главное - его нужно переводить на язык бизнеса (метрики, деньги, влияние) И тогда это перестаёт быть внутренней кухней аналитиков и становится чем-то, что действительно влияет на решения Наверное, главный takeaway для меня: перестать делать Data Quality на всякий случай и начать встраивать его сразу в логику того, что мы делаем 🧩 Кстати, у спикера есть книга - Data Quality ROI (Gaurav Patole), кажется, стоит добавить в список на почитать 📚