Всем привет. Так получилось, что у этой статьи сразу два автора, мы работаем в X5 Технологии и отвечаем за выстраивание процессов производства ИТ-решений. Учитывая масштаб и сложность нашей организации, задача эта нетривиальная. Мы подумали, что, возможно, наш опыт будет кому-то полезен и за пределами X5, так и появилась эта статья.
Всё сложно
Началось все с того, что в сентябре 2020 года X5 Group объединила несколько своих технологических подразделений в X5 Технологии — выделенную структуру, которая отвечает за цифровое развитие для всех компаний группы.
Структура получилась большой (3000+ человек) и сложной, объединив в себе:
Суровых ребят, отвечающих за развитие критичных и высоконагруженных core-систем из департамента информационных технологий.
Agile-команды, разрабатывающие продукты на базе нашей Big Data из дирекции по большим данным, которые привыкли работать в очень быстро меняющемся окружении.
Ребят из ИТ «Пятёрочки» и «Перекрёстка», которые всегда были максимально близко к бизнесу и всегда жили в парадигме – вижу цель, не вижу препятствий.
Так же мы получили:
Сложный и разнообразный стек технологий.
Большое количество инструментов, в которых команды ведут свою работу (огромная кастомизированная инсталляция Jira с сотнями проектов и десятками интеграций, легкий и гибкий Youtrack практически ни с чем не интегрированный, несколько Git-репозиториев, несколько инсталляций Sonar, разные CI/CD инструменты и т.д.).
Разный подход к работе в этих инструментах и созданию артефактов.
Разрозненные и не всегда актуальные знания в виде сотен вики-страниц на Confluence.
Какие проблемы мы решаем
Для сотрудников ориентироваться в этом окружении достаточно сложно, особенно если ты новичок. Но даже для опытного сотрудника при переходе в новую команду все может начаться с нуля, т.к. в ней могут использоваться для работы совсем другие инструменты и правила.
У команд создание и настройка всего необходимого окружения для работы (Jira, Git Lab, Sonar, Confluence, Allure) отнимает много времени, что может влиять на скорость разработки. А сложность поиска нужной информации может приводить к тому, что иногда приходится изобретать велосипед, делая функционал, который уже ранее был реализован в другом решении.
Для менеджмента важно, чтобы производственный процесс был прозрачным, управляемым и эффективным, поддерживал рост бизнеса и наш объем изменений.
Регламенты не работают
Во всяком случае, для нас это так.
Ведь перед нами стоит задача найти баланс, где с одной стороны — желание организации выстроить систему контроля работы тысяч ИТ-шников, а с другой — стремление команд быть максимально независимыми, но при этом получать от компании инструменты для удобной работы.
Регламенты можно написать (как правило сухим канцелярским языком), уведомить об их введении несколько тысяч человек (10% сотрудников их прочитают, еще меньше поймут что же на самом деле теперь от них хотят), поставить КПЭ менеджерам и дальше с какой-то периодичностью аудировать их выполнение. Но работать такая модель будет только на бумаге, не решая реальные проблемы, создавая иллюзию контроля у организации и ощущение посягательства на свободу у команд.
Мы решили пойти немного другим путем.
Производственный framework
Сейчас попробуем рассказать, что мы вкладываем в это понятие.
В X5 мы в основном разработку ведем силами выделенных команд (будь то продукт, проект или ИТ-система), а команды комплектуются из сотрудников определенных компетенций: java-разработчик, бизнес-аналитик, solution-архитектор, delivery-менеджер, data-аналитики и другие. В нашей структуре есть такое понятие как центр компетенций — подразделение, которое отвечает за найм, профессиональное развитие и выделение в команды сотрудников с определенной компетенцией.
Вместе с лидерами центров компетенций мы и начали решать нашу задачу.
1. Инструменты
Каждый день наши сотрудники используют в своей работе разнообразные инструменты и сервисы: Jira, Git, Sonar Cube, Confluence и DevOps-сервисы. Все долго перечислять, но есть основные, где работает большая часть сотрудников.
Напрашивалось решение, что инструменты могут стать тем разумным ограничением, которое позволит задать какие-то минимальные границы для команд. Конечно, кому-то больше нравится (условный) Trello, но сорри, у нас другой корпоративный трекер. Одинаковые инструменты зададут рамки, не позволяя песку рассыпаться за пределы песочницы.
2. Артефакты
В этих инструментах каждый день создаются разного рода артефакты. Это может быть commit в Git, issue в Jira, тест-кейс в Allure и так далее.
Задав в рамках каждой компетенции определенные правила создания таких артефактов, мы задаем второй разумный уровень ограничений, который понятен для команд.
3. Правила
Ну а когда ваш commit в Git привязан к issue в Jira, а тест-кейс в Allure завязан с acceptance критерием user story в Confluence, где-то плачет (от счастья конечно) менеджер среднего звена. Все понимают, что артефакты логически связаны между собой, но не все эти связи указывают в ходе своей работы.
Именно в этой связи и заключается последнее звено нашей модели: инструмент артефакт – взаимосвязь артефактов. Эта схема понятна и близка нашим сотрудникам.
Эта модель и легла в основу нашего производственного фреймворка:
Собрали все зарекомендовавшие себя практики работы с инструментами, требования к формату артефактов и их взаимосвязи.
Сгруппировали их по этапам производства: бизнес-анализ, разработка, тестирование и т.д.
Эту информацию в удобном и понятном виде разместили на внутреннем портале framework.x5.ru, где любой сотрудник может быстро найти нужную ему информацию.
Цифровой след
Теперь у нас есть набор базовых правил, которые всем понятны и доступны на красивом портале. Как теперь вовлечь всех участников процесса разработки и использовать знания, которые мы собрали на отдельном портале? Как понять, что все их используют в своей работе?
Надо позвать ребят из XSolla. Мы уже умеем собирать данные из наших
производственных инструментов (мы это называем цифровой след) в нашем кластере
Big Data.
А задавая в рамках фреймворка правила в виде систем, артефактов и их взаимосвязи, мы формируем цифровую модель производственного процесса. Анализируя цифровой след, команда и организация могут понимать, насколько правила фреймворка выполняются или нет. И если нет, то можно погрузиться в проблематику и понять, что пошло не так.
Lego или framework как сервис для команд
Итак, у нас уже есть понятные правила работы для команд, есть механизм отслеживания их исполнения через цифровой след. А как с этим работать команде? Как этим пользоваться в повседневной работе?
Сейчас мы разрабатываем сервис, который и должен ответить на эти вопросы.
1. Автоматизация или собираем конструктор
Как мы уже говорили выше, создание рабочего окружения для команды нетривиальная задача. А когда мы вводим дополнительные правила, то все становится еще сложнее. Но это если окружение создается как раньше, через несколько заявок, которые исполняются людьми, отвечающими за поддержку разных инструментов.
Когда же есть зафиксированный набор инструментов и понятные правила работы с ними в рамках каждого из этапов производства, автоматизация создания окружения становится достаточно понятной задачей.
Именно такой сервис мы создаем и сейчас пилотируем. Команда собирает под себя производственный процесс и получает настроенное окружение в рабочих инструментах.
2. Мониторинг
Тут все достаточно понятно. На уровне команды мы показываем насколько она соответствует фреймворку для каждого из этапов производства, в чем заключаются отклонения и что надо сделать, чтобы эти отклонения устранить.
Пока это MVP, но дальше — больше)
Что дальше?
Помимо введения производственного фреймворка в наши многочисленные команды, мы думаем над следующими вещами:
Библиотека типовых решений. Мы давно хотим систематизировать нашу кодовую базу и дать командам возможность экономить время, используя готовые библиотеки для решения типовых задач (мониторинг, авторизация и другое).
Метрики. Мы уже активно продвигаемся в этом направлении, но т.к команды, как правило, работают в разных инструментах и по разным правилам, дата сет оставляет желать лучшего. Внедрение фреймворка решает эту проблему и дает возможность собирать различные метрики производственного процесса как в разрезе команд, так и в агрегированном виде по этапам производства и центрам компетенций.
Геймификация. Правила фрейморка, метрики, типовые решения. Все это можно обернуть в игровые механики и сделать производственный процесс для сотрудников и команд интереснее. Будем пробовать.
Надеемся, было интересно и не очень занудно. Готовы ответить на ваши вопросы в комментариях, и, если тема зайдет, продолжить более развернуто в следующих статьях.
