Системный аналитик DWH — кто это? Как объяснить так, чтобы поняла даже бабушка?
На мой взгляд, это волшебник, который превращает хаос в нечто упорядоченное и понятное. Уменьшает энтропию в бесконечных потоках информации внутри компании и не только, даёт бизнесу возможность принимать основанные на данных, то есть имеющие под собой опору, решения.
Получая от бизнеса задачу, системный аналитик погружается в пучину информационных потоков, изучает имеющиеся, ищет новые и подключает их к хранилищу данных (что такое хранилище обсудим чуть позже). В процессе работы активно взаимодействует не только с бизнесом, но и с архитекторами, дата инженерами, девопсами и ещё огромным количеством людей. Он легко находит общий язык с каждым.
Ежедневно мир обрастает петабайтами новой информации (полезной и не очень). Системный аналитик помогает не сойти с ума и не даёт заблудиться в озёрах данных. Даёт возможность найти нужное и использовать найденное максимально эффективно, превращая качественные данные в основу для принятия бизнес-решений.
#системный_анализ
На мой взгляд, это волшебник, который превращает хаос в нечто упорядоченное и понятное. Уменьшает энтропию в бесконечных потоках информации внутри компании и не только, даёт бизнесу возможность принимать основанные на данных, то есть имеющие под собой опору, решения.
Получая от бизнеса задачу, системный аналитик погружается в пучину информационных потоков, изучает имеющиеся, ищет новые и подключает их к хранилищу данных (что такое хранилище обсудим чуть позже). В процессе работы активно взаимодействует не только с бизнесом, но и с архитекторами, дата инженерами, девопсами и ещё огромным количеством людей. Он легко находит общий язык с каждым.
Ежедневно мир обрастает петабайтами новой информации (полезной и не очень). Системный аналитик помогает не сойти с ума и не даёт заблудиться в озёрах данных. Даёт возможность найти нужное и использовать найденное максимально эффективно, превращая качественные данные в основу для принятия бизнес-решений.
#системный_анализ
Метод '5 почему' поможет раскрыть истинные потребности бизнеса
Поговорим о том, как понять, что именно нужно бизнесу, когда он приходит с вопросом "хочу того — не знаю чего".
Рассмотрим сценарий: продуктовый аналитик требуют какие-то метрики, основанные на данных, которые вроде бы есть, а вроде и нет в хранилище. Как удовлетворить потребности максимально точно? Есть метод, который помогает раскрывать настоящие потребности заказчика. Этот метод — "5 почему".
Суть метода заключается в том, чтобы понять, что именно бизнес хочет получить задавая вопросы. Конечно, не обязательно спрашивать именно "Почему". Вместо этого, перефразируем вопросы в соответствии с запросом заказчика.
Возможные шаги:
— Определяем запрос бизнеса. Просим заказчика ясно сформулировать, что именно ему нужно.
— Задаем вопросы, которые позволят выявить детали запроса. Подходим к делу креативно.
— Создаём цепочку из вопросов (не ставим строгую планку "пять", как в оригинале метода). Постепенно детализируем каждый аспект запроса, записывая ответы, чтобы лучше видеть картину. При сложных запросах здесь классно поможет использование майнд-карт.
— Проверяем формулировку вопросов на точность. Если вдруг застреваем на каком-то этапе, перефразируем вопросы.
— При необходимости привлекаем других заинтересованных лиц. Разнообразные точки зрения и мнения — это сила.
Так благодаря системному анализу и методу "5 почему," построение DWH становится более точным и эффективным, помогая бизнесу получить от данных то, что действительно нужно.
#soft_skills #системный_анализ
Поговорим о том, как понять, что именно нужно бизнесу, когда он приходит с вопросом "хочу того — не знаю чего".
Рассмотрим сценарий: продуктовый аналитик требуют какие-то метрики, основанные на данных, которые вроде бы есть, а вроде и нет в хранилище. Как удовлетворить потребности максимально точно? Есть метод, который помогает раскрывать настоящие потребности заказчика. Этот метод — "5 почему".
Суть метода заключается в том, чтобы понять, что именно бизнес хочет получить задавая вопросы. Конечно, не обязательно спрашивать именно "Почему". Вместо этого, перефразируем вопросы в соответствии с запросом заказчика.
Возможные шаги:
— Определяем запрос бизнеса. Просим заказчика ясно сформулировать, что именно ему нужно.
— Задаем вопросы, которые позволят выявить детали запроса. Подходим к делу креативно.
— Создаём цепочку из вопросов (не ставим строгую планку "пять", как в оригинале метода). Постепенно детализируем каждый аспект запроса, записывая ответы, чтобы лучше видеть картину. При сложных запросах здесь классно поможет использование майнд-карт.
— Проверяем формулировку вопросов на точность. Если вдруг застреваем на каком-то этапе, перефразируем вопросы.
— При необходимости привлекаем других заинтересованных лиц. Разнообразные точки зрения и мнения — это сила.
Так благодаря системному анализу и методу "5 почему," построение DWH становится более точным и эффективным, помогая бизнесу получить от данных то, что действительно нужно.
#soft_skills #системный_анализ
❤1
Системный анализ: от хаоса к пониманию через качественные требования
На Хабре вышла неплохая, но немного хаотичная статья про важность качественных требований в системном анализе и их влияние на итоговый продукт. Ведь работа системного аналитика — это не только понимание данных, архитектуры хранилища и умение писать SQL-запросы. Немалую часть времени занимает общение со всеми участниками процессов и создание грамотной документации.
Техническое задание — один из ключевых документов в работе системного аналитика. Бизнес-заказчики редко приходят с кристально ясным видением своей идеи. Задача аналитика — превратить эти размытые образы в четкий план действий.
Процесс сбора и уточнения требований — это настоящее искусство. Оно требует терпения, внимательности и умения задавать правильные вопросы. Каждый упущенный нюанс может обернуться часами лишней работы или, что еще хуже, разочарованием заказчика.
Четкие требования — основа успешного проекта.
В статье же раскрыты такие важные моменты при работе с требованиями, как:
1. Цель аналитика: обеспечить удовлетворенность конечного пользователя через точные и понятные требования.
2. Качество требований: что такое качество и как его можно повысить для улучшения требований.
3. Типы мышления: какие из них своейственны для системного аналитика.
4. Важность ясности мышления и его развития.
5. Роль саморевью: постоянное саморевью и ревью коллег для улучшения требований.
6. Обратная связь: активное взаимодействие с коллегами и заказчиками для уточнения и улучшения требований.
В статье подчёркивается: для повышения качества своей работы, системному аналитику стоит развивать различные типы мышления, следить за своим состоянием и практиковать управление знаниями.
Сочетание ясного мышления и умения формулировать четкие требования — это не просто профессиональные навыки, а настоящее искусство. С их помощью можно гораздо легче создавать продукты и формировать процессы, которые радуют пользователей и приносят пользу бизнесу.
#системный_анализ #документация
На Хабре вышла неплохая, но немного хаотичная статья про важность качественных требований в системном анализе и их влияние на итоговый продукт. Ведь работа системного аналитика — это не только понимание данных, архитектуры хранилища и умение писать SQL-запросы. Немалую часть времени занимает общение со всеми участниками процессов и создание грамотной документации.
Техническое задание — один из ключевых документов в работе системного аналитика. Бизнес-заказчики редко приходят с кристально ясным видением своей идеи. Задача аналитика — превратить эти размытые образы в четкий план действий.
Процесс сбора и уточнения требований — это настоящее искусство. Оно требует терпения, внимательности и умения задавать правильные вопросы. Каждый упущенный нюанс может обернуться часами лишней работы или, что еще хуже, разочарованием заказчика.
Четкие требования — основа успешного проекта.
В статье же раскрыты такие важные моменты при работе с требованиями, как:
1. Цель аналитика: обеспечить удовлетворенность конечного пользователя через точные и понятные требования.
2. Качество требований: что такое качество и как его можно повысить для улучшения требований.
3. Типы мышления: какие из них своейственны для системного аналитика.
4. Важность ясности мышления и его развития.
5. Роль саморевью: постоянное саморевью и ревью коллег для улучшения требований.
6. Обратная связь: активное взаимодействие с коллегами и заказчиками для уточнения и улучшения требований.
В статье подчёркивается: для повышения качества своей работы, системному аналитику стоит развивать различные типы мышления, следить за своим состоянием и практиковать управление знаниями.
Сочетание ясного мышления и умения формулировать четкие требования — это не просто профессиональные навыки, а настоящее искусство. С их помощью можно гораздо легче создавать продукты и формировать процессы, которые радуют пользователей и приносят пользу бизнесу.
#системный_анализ #документация
❤1
База — кринж или мастхэв?
Много статей в моём блоге посвящено самым основам, которые кажутся очевидными и «ну уж это то все знают». А мне кажется — знать хорошо, а не забывать и использовать знания ещё лучше.
В системный анализ и аналитику данных часто приходят люди из совершенно разных сфер и многие статьи-курсы делают упор на знания SQL, что, конечно, важно. Но также важно понимать где и как ваши данные лежат изначально, как они связаны друг с другом, как оптимизировать их использование. Ведь порой источник — это настоящий ящик Пандоры.
Связи, первичные ключи, нормализация — это не просто теория, а практический инструмент для системного аналитика DWH. Когда вы глубоко понимаете, как связаны данные о продажах, клиентах и товарах, вы можете точнее перевести требования бизнеса на язык хранилища. Например, для отчета по продажам в разрезе клиентских сегментов вы сразу знаете, какие объекты понадобятся и как их связать.
Нормализация критична при интеграции новых источников. Допустим, нужно загрузить из источника данные о программе лояльности. Вы анализируете структуру исходной таблицы и решаете, нормализовать ли данные при загрузке или оставить как есть. Всё это безусловно зависит от задачи, особенностей хранилища и требований к производительности.
Знание нормализации и денормализации помогает оптимизировать работу хранилища и создавать эффективные витрины. При разработке вы выбираете лучшие источники: нормализованные таблицы ods-слоя или, в каких-то случаях, денормализованные таблицы emart-слоя.
И, опять же, основы помогают эффективно общаться с инженерами и бизнесом. Вы становитесь "переводчиком" между бизнесом и IT, быстро оценивая сложность задач и необходимые изменения в структуре данных.
Поэтому не пренебрегайте базовыми знаниями — они ключ к успешной работе.
#системный_анализ
Много статей в моём блоге посвящено самым основам, которые кажутся очевидными и «ну уж это то все знают». А мне кажется — знать хорошо, а не забывать и использовать знания ещё лучше.
В системный анализ и аналитику данных часто приходят люди из совершенно разных сфер и многие статьи-курсы делают упор на знания SQL, что, конечно, важно. Но также важно понимать где и как ваши данные лежат изначально, как они связаны друг с другом, как оптимизировать их использование. Ведь порой источник — это настоящий ящик Пандоры.
Связи, первичные ключи, нормализация — это не просто теория, а практический инструмент для системного аналитика DWH. Когда вы глубоко понимаете, как связаны данные о продажах, клиентах и товарах, вы можете точнее перевести требования бизнеса на язык хранилища. Например, для отчета по продажам в разрезе клиентских сегментов вы сразу знаете, какие объекты понадобятся и как их связать.
Нормализация критична при интеграции новых источников. Допустим, нужно загрузить из источника данные о программе лояльности. Вы анализируете структуру исходной таблицы и решаете, нормализовать ли данные при загрузке или оставить как есть. Всё это безусловно зависит от задачи, особенностей хранилища и требований к производительности.
Знание нормализации и денормализации помогает оптимизировать работу хранилища и создавать эффективные витрины. При разработке вы выбираете лучшие источники: нормализованные таблицы ods-слоя или, в каких-то случаях, денормализованные таблицы emart-слоя.
И, опять же, основы помогают эффективно общаться с инженерами и бизнесом. Вы становитесь "переводчиком" между бизнесом и IT, быстро оценивая сложность задач и необходимые изменения в структуре данных.
Поэтому не пренебрегайте базовыми знаниями — они ключ к успешной работе.
#системный_анализ
👍5✍3
Системный аналитик DWH — кто ты?
Интернет заполнен рекламой курсов по дата инженерии и мы уже более-менее разобрались кто эти ребята и чем занимаются. С дата аналитикой, кажется, тоже плюс минус всё понятно. Но кто такие системные аналитики DWH (SA DWH), зачем они нужны и можно ли обойтись без них?
Очень давно я уже писала пост о SA DWH, где сравнивала эту роль с волшебником, который превращает хаос данных в упорядоченную структуру. Сегодня хочется рассказать более предметно о том, что же это за зверь и за что получает свою зряплату.
В России исторически закрепилась вертикальная структура компаний, где каждый отдел имеет «ответственное лицо» за свою область. Так у хранилищ данных и появились «системные аналитики DWH», которые:
🔵 согласовывают требования с бизнесом
🔵 расписывают модели данных
🔵 передают задачи дата-инженерам.
По сути, системный аналитик — входная точка в хранилище данных. Да, во многих зарубежных компаниях выделенных SA DWH нет: эти обязанности совмещают Data Warehouse Architect, Data Solutions Analyst, Technical Data Analyst, Analytics Engineer (поговаривают, что эта роль потихоньку уходит в прошлое, но это не точно), ETL или Data Engineer. Однако в российских реалиях системные аналитики DWH — это связующее звено между бизнесом и техническим миром. Правда, иногда их тоже называют дата-инжеренами, выделяя в отдельное направление (как, например, в одном жёлтом банке).
Чем же занимается SA DWH?
Все мы понимаем, что всё меняется от компании к компании, но примерно так:
🔵 общается с бизнесом и командами разработки, собирает требования к данным
(то есть координирует взаимодействие и выступает «переводчиком» между бизнесом, DevOps, ETL, BI и другими участниками дата-процессов).
🔵 проектирует схему хранилища: создает и документирует структуру таблиц, представлений, витрин (включая CDC, STG, ODS, EMART и другие «слои» DWH).
🔵 разрабатывает концепцию обработки данных: какие пайплайны нужны, как реализовать CDC и репликацию, и т.д.
🔵 ведёт анализ данных (и копается в куче legacy 🥲 )
🔵 продумывает качество данных (иногда в составе отдельного подразделения по качеству, если позволяет масштаб компании)
🔵 создает стратегии по работе с историческими данными (сколько хранить, как обновлять, как архивировать)
🔵 планирует развитие DWH: какие таблицы добавить, какие поля стоит убрать, как обогатить данные, ...
🔵 проектирует витрины и описывает требования к ETL-процессам, чтобы дата-инженеры могли чётко реализовывать логику загрузки
🔵 разбирается с интеграцией легаси-систем (нередко это самый сложный блок).
🔵 ...
На самом деле список задач SA может сильно отличаться от команды к команде. Например, в идеальной ситуации есть выделенный DWH-архитектор, который строит целостную архитектуру и отвечает за масштабирование. Но если в компании такой роли нет, эти обязанности часто берёт на себя системный аналитик.
Для меня работа SA всегда где-то на грани творчества, экспертизы и здравого смысла. В этом и вся прелесть профессии.
Позже расскажу какими инструментами мы пользуемся в своей работе.
А что ближе вам — техническая внутрянка или работа с бизнес-контекстом и логикой?
#системный_анализ
Интернет заполнен рекламой курсов по дата инженерии и мы уже более-менее разобрались кто эти ребята и чем занимаются. С дата аналитикой, кажется, тоже плюс минус всё понятно. Но кто такие системные аналитики DWH (SA DWH), зачем они нужны и можно ли обойтись без них?
Очень давно я уже писала пост о SA DWH, где сравнивала эту роль с волшебником, который превращает хаос данных в упорядоченную структуру. Сегодня хочется рассказать более предметно о том, что же это за зверь и за что получает свою зряплату.
В России исторически закрепилась вертикальная структура компаний, где каждый отдел имеет «ответственное лицо» за свою область. Так у хранилищ данных и появились «системные аналитики DWH», которые:
По сути, системный аналитик — входная точка в хранилище данных. Да, во многих зарубежных компаниях выделенных SA DWH нет: эти обязанности совмещают Data Warehouse Architect, Data Solutions Analyst, Technical Data Analyst, Analytics Engineer (поговаривают, что эта роль потихоньку уходит в прошлое, но это не точно), ETL или Data Engineer. Однако в российских реалиях системные аналитики DWH — это связующее звено между бизнесом и техническим миром. Правда, иногда их тоже называют дата-инжеренами, выделяя в отдельное направление (как, например, в одном жёлтом банке).
Чем же занимается SA DWH?
Все мы понимаем, что всё меняется от компании к компании, но примерно так:
(то есть координирует взаимодействие и выступает «переводчиком» между бизнесом, DevOps, ETL, BI и другими участниками дата-процессов).
На самом деле список задач SA может сильно отличаться от команды к команде. Например, в идеальной ситуации есть выделенный DWH-архитектор, который строит целостную архитектуру и отвечает за масштабирование. Но если в компании такой роли нет, эти обязанности часто берёт на себя системный аналитик.
Для меня работа SA всегда где-то на грани творчества, экспертизы и здравого смысла. В этом и вся прелесть профессии.
Позже расскажу какими инструментами мы пользуемся в своей работе.
А что ближе вам — техническая внутрянка или работа с бизнес-контекстом и логикой?
#системный_анализ
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤3
Помню, что задолжала пост про инструменты в руках системного аналитика.
Но много думала об этом и выходит слишком скользкая тема) ведь главное — это не инструменты, а результат. А любой инструмент — это всего лишь путь к нему. Поэтому от компании к компании, да даже в рамках одной компании инструменты будут постоянно меняться.
Можно, конечно, поковырять всего понемногу из какой-нибудь таблички как на примере выше😬 , но сначала спросите себя "зачем". Быть в курсе трендов и быстро меняющегося мира данных — ок, знать всё обо всём без практической применимости — достижение уже спорное. Так или иначе, в работе вы будете погружаться в новые для вас инструменты и технологии.
Когда я приходила на свою первую работу без DWH бекграунда, то знала что такое airflow чисто теоретически из пары обзорных видео. Но жизнь заставила быстро разобраться что к чему. На текущей работе также пришлось моментально погружаться в Snowflake, про который каждый из коллег знал примерно столько же (так как зарождение DWH в компании началось с нас).
Выходит, что лучший наш инструмент — это мозг и умение (и что важно — желание) учиться и адаптироваться. Смотреть на мир широко и системно. Не фукать на что-то новое (частенько встречаю такое в IT-мире). Развивать софт-скиллс. Не зря всё чаще в статьях и конференциях упор делается именно на развитие мягких навыков, которые дополняют техническую экспертизу (или у меня это иллюзия частотности?🤨 ).
Возвращаясь к инструментам. Чем пользуюсь в работе ежедневно сейчас: snowflake, airflow, kafka, tfs, базы различных наших источников (MS SQL, PostgreSQL и прочее), а также множеством самописных фреймворков (в том числе etl), разработанных нашими инженерами, тестирую новые загрузки через питон+тетрадку, исследую сторонние апи через постман (или ту же тетрадку). Заглядываю в датахаб и табло. Периодически сталкиваюсь с чем-то новым. В прошлом месте инструментарий был совсем другой) например, был гораздо более плотный опыт взаимодействия с Oracle, Greenplum и ClickHouse. Какие-то популярные решения, типа dbt ещё не было возможности потрогать в бою) только в качестве личного "факультатива".
Так что инструменты приходят и уходят, а мозг остаётся с нами всегда😀 наше лучшее вложение 🤑 🤫
#системный_анализ
Но много думала об этом и выходит слишком скользкая тема) ведь главное — это не инструменты, а результат. А любой инструмент — это всего лишь путь к нему. Поэтому от компании к компании, да даже в рамках одной компании инструменты будут постоянно меняться.
Можно, конечно, поковырять всего понемногу из какой-нибудь таблички как на примере выше
Когда я приходила на свою первую работу без DWH бекграунда, то знала что такое airflow чисто теоретически из пары обзорных видео. Но жизнь заставила быстро разобраться что к чему. На текущей работе также пришлось моментально погружаться в Snowflake, про который каждый из коллег знал примерно столько же (так как зарождение DWH в компании началось с нас).
Выходит, что лучший наш инструмент — это мозг и умение (и что важно — желание) учиться и адаптироваться. Смотреть на мир широко и системно. Не фукать на что-то новое (частенько встречаю такое в IT-мире). Развивать софт-скиллс. Не зря всё чаще в статьях и конференциях упор делается именно на развитие мягких навыков, которые дополняют техническую экспертизу (или у меня это иллюзия частотности?
Возвращаясь к инструментам. Чем пользуюсь в работе ежедневно сейчас: snowflake, airflow, kafka, tfs, базы различных наших источников (MS SQL, PostgreSQL и прочее), а также множеством самописных фреймворков (в том числе etl), разработанных нашими инженерами, тестирую новые загрузки через питон+тетрадку, исследую сторонние апи через постман (или ту же тетрадку). Заглядываю в датахаб и табло. Периодически сталкиваюсь с чем-то новым. В прошлом месте инструментарий был совсем другой) например, был гораздо более плотный опыт взаимодействия с Oracle, Greenplum и ClickHouse. Какие-то популярные решения, типа dbt ещё не было возможности потрогать в бою) только в качестве личного "факультатива".
Так что инструменты приходят и уходят, а мозг остаётся с нами всегда
#системный_анализ
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8