Меня зовут Сергей Раскин.
Послужной список:
15 лет в Сбере - от руководителя проекта. до начальника управления
4 года в Альфе - РП
2 года в Билайне - аналитик
Внедрял крупные проекты и программы.
Сертифицирован IPMA
Даю практические советы от 1-го лица
Post #139
502
О согласовании требований к качеству данных при инициации проекта.
Когда определяется скоуп и границы любого проекта связанного с данными, будь то создание витрины данных, хранилища данных, или любое "взять много данных из вот этих источников, доставить и отобразить здесь",
одним из важных моментов является согласование требований к качеству данных с Заказчиком.
При этом, это тот самый случай, когда согласование достигается простыми шагами, а вот если этого не сделать - то риски у проекта сильно увеличиваются.
Практика показывает (да и у Gartner' а написано), что по теме качества данных у заказчика может быть разная степень зрелости:
1. Начальная. ☺️
Заказчик эти данные еще никогда не видел и рад будет увидеть. Он не может еще сформулировать требования к качеству данных - и это нормально.
Самое простое решение в таких случаях - прописывается, что
Заказчик с этим соглашается,
причем для него это будет действие, примерно как для нас прожать галочку "Я прочитал лицензионное соглашение" - автоматически и без раздумий.
И ударяем по рукам. 🤝
Если есть опыт подобных проектов и ты знаешь типовые проблемы, можешь заказчику предложить добавить в скоуп нужные проверки и инструменты - но это уже на твое усмотрение, главное, зафиксируйте✍️.
2. Продвинутая 👨🎓
Заказчик уже знает, что в исходных данных содержится то, что его беспокоит и он хочет это улучшить. И тогда
И ты уже начинаешь управлять этими требованиями, как и любыми другими требованиями проекта: принимаешь, согласовываешь, предлагаешь альтернативы и т. д.
По итогам, у тебя уже есть стартовый материал для будущей методики тестирования и даже для критериев приемки результатов проекта.
Действие простое, а помочь может очень сильно. 🦺
Если об этом не договориться,
то заказчик из группы 1, который на начальном этапе требования к КД сформулировать не мог, увидит в первых результатах данные, качество которых его не устроит и тут же предъявит это как проектный дефект. 👿
А особенно, если ты - подрядчик, а проект - на коммерческой основе.
И аргумент, что так в источнике - работать уже не будет,
Заказчик будет давить бизнес-метриками, напирать на то, что продуктом пользоваться нельзя, KPI срывается и и поэтому он вообще ничего не заплатит, пока не поправишь. 💸
А выполнение требований существенно повысит затраты в проекте, более того, такие требования могут продолжаться вплоть до бесконечности 💰💰💰
Поэтому,
на старте проекта, когда определяется скоуп работ, и особенно, если подписывается контракт,
не забывай достичь простыми шагами соглашение о качестве данных. 👆
Telegram Data Quality | Качество данных С чего начать?
Какие проверки важнее - технические или бизнесовые? Какие кидаться реализовывать в первую очередь? За что хвататься, когда впереди поле непахано?
Недавно ко мне пришёл коллега за советом, с чего начать копать в части качества данных. Бизнес… Когда определяется скоуп и границы любого проекта связанного с данными, будь то создание витрины данных, хранилища данных, или любое "взять много данных из вот этих источников, доставить и отобразить здесь",
одним из важных моментов является согласование требований к качеству данных с Заказчиком.
При этом, это тот самый случай, когда согласование достигается простыми шагами, а вот если этого не сделать - то риски у проекта сильно увеличиваются.
Практика показывает (да и у Gartner' а написано), что по теме качества данных у заказчика может быть разная степень зрелости:
1. Начальная. ☺️
Заказчик эти данные еще никогда не видел и рад будет увидеть. Он не может еще сформулировать требования к качеству данных - и это нормально.
Самое простое решение в таких случаях - прописывается, что
качество данных в витрине (хранилище, экранной форме, вот там где они используются) соответствует качеству данных в системах-источниках.
Заказчик с этим соглашается,
причем для него это будет действие, примерно как для нас прожать галочку "Я прочитал лицензионное соглашение" - автоматически и без раздумий.
И ударяем по рукам. 🤝
Если есть опыт подобных проектов и ты знаешь типовые проблемы, можешь заказчику предложить добавить в скоуп нужные проверки и инструменты - но это уже на твое усмотрение, главное, зафиксируйте✍️.
2. Продвинутая 👨🎓
Заказчик уже знает, что в исходных данных содержится то, что его беспокоит и он хочет это улучшить. И тогда
в разделе "требования к качеству данных" прописываются те требования, которые заказчик формулирует.
И ты уже начинаешь управлять этими требованиями, как и любыми другими требованиями проекта: принимаешь, согласовываешь, предлагаешь альтернативы и т. д.
По итогам, у тебя уже есть стартовый материал для будущей методики тестирования и даже для критериев приемки результатов проекта.
Действие простое, а помочь может очень сильно. 🦺
Если об этом не договориться,
то заказчик из группы 1, который на начальном этапе требования к КД сформулировать не мог, увидит в первых результатах данные, качество которых его не устроит и тут же предъявит это как проектный дефект. 👿
А особенно, если ты - подрядчик, а проект - на коммерческой основе.
И аргумент, что так в источнике - работать уже не будет,
Заказчик будет давить бизнес-метриками, напирать на то, что продуктом пользоваться нельзя, KPI срывается и и поэтому он вообще ничего не заплатит, пока не поправишь. 💸
А выполнение требований существенно повысит затраты в проекте, более того, такие требования могут продолжаться вплоть до бесконечности 💰💰💰
Поэтому,
на старте проекта, когда определяется скоуп работ, и особенно, если подписывается контракт,
не забывай достичь простыми шагами соглашение о качестве данных. 👆
- 👍 2
- 💯 1
