Полина Константинова
Алексей Дарвин, руководитель отдела разработки и сопровождения продуктов больших данных X5 Retail Group, рассказал, как меняются IT-департаменты и процессы создания продуктов в крупных компаниях из-за развития новых технологий.
Как развитие технологии Big Data меняет состав IT-команды
Алексей Дарвин
Структура IT-департаментов редко сохраняет неизменность дольше нескольких лет: развитие технологий вызывает к жизни новые задачи, которые требуют новых ролей и новых связей между ними. Это приводит к периодическому «переформатированию» устоявшихся процессов взаимодействия и появлению новых.
Если посмотреть на статистику по вакансиям за 2013 и 2019 годы, еще пять лет назад самыми быстрорастущими IT-позициями в Москве были программист JavaScript и SEO-специалист, а запрос на DevOps-инженера и Data Scientist был настолько мал, что даже не попал в список.
Эти две специальности я упомянул неслучайно: хотя первое упоминание о Data Science и DevOps на habr.com появилось только в 2017 году, сейчас они вошли в топ самых востребованных специальностей, улучшив свои позиции за 2 года на 226%(!) и 70% соответственно.
Такой высокий спрос вызвало активное развитие технологий Big Data, которое привело к очередному «переформатированию» IT-команд в компаниях. Но несмотря на все эти изменения, расширяющие возможности команд, традиционные роли сохраняют свое значение — так, разработчики, тестировщики и бизнес-аналитики продолжают оставаться одними из ключевых элементов в процессе создания IT-продукта. Посмотрим, что в таком случае изменилось.
От лодки до океанского лайнера: специализация ролей
В любом IT-подразделении вне зависимости от его задач, отрасли и размера процессы по разработке решения строятся по общим принципам — поэтому структура ролей в команде во всех компаниях будет практически идентична. Но есть некоторые нюансы: так, в рамках стартапа из нескольких человек одному специалисту приходится брать на себя несколько ролей сразу. К примеру, разработчик одновременно может быть и аналитиком, и верстальщиком, и даже тимлидом.
Чем больше компания и сложнее продукт, который она развивает, тем более узкой специализации сотрудников она будет требовать.
Так, если перед вами стоит задача, не требующая сложных и точных инженерных решений, — например, построить лодку — функции проектировщика, инженера, строителя и эксперта вам, скорее всего, придется объединить в одном лице.
При создании же такого сложного проекта, как круизный лайнер, требования к каждой роли повышаются, и за каждый процесс начинают отвечать узкие специалисты.
Современные тенденции с учетом новых ролей
Классический процесс создания IT-продукта можно было поделить на три основных составляющих:
управление процессами,
инфраструктура,
разработка.
С появлением новой предметной области (больших данных) и нового подхода к процессу поставки решений (DevOps) в эту схему добавились еще два блока:
управление данными + развитие данных,
управление поставкой решения (DevOps).
Можно сказать, что специалисты по управлению и развитию данными стали отвечать за их инвентаризацию и правила последующего использования. У нас этот блок включает в себя следующие роли:
Архитектор данных (Data Architect) занимается проектированием детального слоя big data: его задача — создать такую систему, которая сможет обработать тонны данных. Он умеет работать с командной строкой, создавать отказоустойчивые решения и анализировать состояние системы.
Специалист по контролю данных (Data Quality) отвечает за их качество и проверяет, можно ли их использовать для поставленных целей.
В обязанности дата-аналитика и дата-сайентиста входит непосредственная работа с данными: они создают алгоритмы для анализа массивов данных и проводят этот анализ для решения конкретных бизнес-задач. Именно эти специалисты могут извлечь из данных максимум пользы.
Наконец, управлять таким количеством процессов без автоматизации сборки, тестирования и установки функционала стало невозможно — эта задача перешла специалистам DevOps (development + operations).
Новое и классическое: трансформация
Но даже в «традиционных» блоках новые процессы привели к трансформации существующих ролей. Появление нового инструментария для работы с Big Data (Apache Hadoop) потребовало наличие специалистов, которые отвечали бы за новую инфраструктуру — инженеров Hadoop.
Кроме того, в разработке появилась функция ETL (Extract, Transform, Load), которая подразумевает извлечение данных из источника, их трансформацию и загрузку в хранилище — за эти задачи стал отвечать ETL-разработчик.
В целом процесс разработки IT-продукта в новых реалиях выглядит так:
Ключевые изменения коснулись интеграции новых ролей в процесс. В остальном процедура разработки осталась достаточно классической:
архитектор проектирует архитектуру высокого уровня;
системный аналитик отвечает за ее декомпозицию на отдельные задачи;
разработчики реализуют приложение: backend-программисты разрабатывают логику приложений, frontend-отдел — пользовательский интерфейс;
тимлид управляет всем процессом по распределению ролей;
и, наконец, специалист по контролю качества тестирует решение, после чего задача вновь переходит в отдел по управлению процессами.
Как это на практике
Попробую показать это на примере наших задач: мы разрабатываем продукты, основанные на анализе больших данных, но продукт не может быть реализован без всех элементов технологической цепочки — от сбора требований до реализации пользовательского интерфейса.
Так, недавно мы запустили портал поставщика — инструмент, который поможет поставщикам использовать анализ данных для улучшения показателей бизнеса. В целом описание технологического процесса разработки портала можно описать следующим образом.
Команда ETL-программистов собирает данные по диагностике категории, источниках продаж, миграции покупателей, которые необходимы для анализа, и загружает их в систему.
Специалисты data quality проверяют его на полноту и консистентность.
Затем на сцену выходят дата-аналитики и дата-сайентисты: проанализировав информацию, они разрабатывают математическую модель, которая позволяет анализировать изменение продаж и других ключевых показателей, выявлять источники изменения продаж и переключений, определять ротацию покупателей бренда и изменение их потребления.
Теперь нужно реализовать эту модель в виде удобного приложения, которым смогут пользоваться менеджеры компании. Здесь наступает очередь отдела разработки: программисты вместе с архитектором проектируют структуру будущего приложения, backend-отдел создает его логику, а frontend — интерфейс, и после тестирования приложение передается в работу.
Максимально быструю реализацию всей этой задачи обеспечивают инженеры DevOps, которые автоматизируют процесс сборки и установки функционала.
Тенденции и перспективы
Появление новых технологий Data Science и DevOps дало жизнь новым областям специализации — сбору данных, их анализу и обработке, ускорению процесса поставки новых идей. Как и любая новая технология, Data Science и DevOps проходят стандартный жизненный цикл (известный как Gartner Hype Cycle) от стремительного взлета к тотальному разочарованию и только потом переходят в фазу продуктивного использования:
Сейчас Data Science и DevOps находятся на пике кривой, что объясняет повышенный спрос на специалистов в этих областях, — процесс же разработки с использованием классических инструментов уже дошел до плато производительности (хотя и продолжает трансформироваться, например, в части появления ETL-разработки).
Любые технологии будущего ждет тот же путь: они дадут жизнь новым процессам и ролям, которые будут постепенно встраиваться в общую систему, занимая в ней свое место. И главное, чему нужно уделить внимание на «переходных» этапах, чтобы ускорить наступление фазы производительности — гармоничная интеграция новых ролей в текущие процессы.
При этом следует помнить, что цикл постоянно повторяется и в будущем нас ждут новые технологии, которые будут проходить тот же цикл развития.
Фото на обложке: Unsplash
Источник:
