Как повысить эффективность децентрализованных команд. Рассказываем на примере BI Community

Исторический экскурс

На протяжении долгого времени все задачи, связанные с BI, решались департаментом информационных технологий. Процесс разработки BI-инструментов был слишком долгим: встречались проблемы с приоритизацией запросов, а с ростом компании единый центр data-компетенций вообще стал узким горлышком. Сотрудники не успевали сделать все отчеты, которые требовались. Ситуацию можно было описать словами «кто громче крикнул — того и ресурсы».

Но в 2019 году структура компании изменилась. На смену стандартным департаментам пришли домены. Почитать про это подробнее можно здесь. Нам важно понимать, что домен — это структурная единица, которая объединяет продуктовые и операционные команды. Каждый домен покрывает определенный стратегический участок бизнеса: платежи, HR, развитие товарных рынков, управление данными и т. д.

За каждым набором задач закреплена автономная единица, а составная структура компании позволяет гибко настраивать процессы и эффективнее расходовать ресурсы. Всего доменов в компании 22. Для дальнейшего рассказа нас интересует тот факт, что теперь задачи BI стали решаться каждым из них отдельно.

Децентрализованный подход

После перехода на новую структуру BI-аналитики распределились по продуктовым и операционным командам доменов. А вместо централизованной разработки отчетов появился self-service-подход (или парадигма «обслужи себя сам»).

У этого есть очевидные плюсы.

• Теперь задачи решаются быстрее и эффективнее — домены сами определяют приоритетность и скорость разработки. Единая дирекция перестала быть узким горлышком.
  
• Аналитики стали ближе к бизнесу, поскольку создают отчеты только для своего домена.
  
• Отчасти бизнес начал обслуживать себя сам.

Однако децентрализация принесла и несколько минусов. Рост потребности в разработке отчетов привел к тому, что число BI-разработчиков резко увеличилось. В рамках единого департамента BI-аналитиков не было вообще, а их функции были размыты между несколькими data-специалистами. Теперь же число сотрудников, так или иначе связанных с визуализацией данных и созданием отчетов, превысило 100 человек. Отсюда:

• разный уровень компетенций в командах разных доменов;
  
• недостаточный уровень синхронизации между командами;
  
• дубли отчетов — специалисты из разных команд не всегда знают, что интересующий их отчет уже разрабатывается коллегами;
  
• разная версия правды — когда для одной и той же метрики команды разных доменов выдают отличающийся результат;
  
• различный UX/UI для пользователя;
  
• трудности с масштабированием изменений: например, чтобы изменить методологию расчета ключевой бизнес-метрики, нужно лично встретиться со всеми командами, которые с ней работают.

В 2021 году перед бизнесом встала задача нивелировать возникшие после реструктуризации минусы, сохранив плюсы.

BI Community

После перехода на доменную структуру ситуация с BI-отчетностью стала выглядеть иначе.

• Несколько десятков команд и более сотни сотрудников, практикующих разработку (из них около 40 — full-time профессионалы, а еще 70 — специалисты, которые практикуют создание отчетов по мере надобности; это возможно благодаря self-service-подходу).
  
• Несколько BI-сервисов (Tableau, Power BI, MS SSRS, SuperSet).
  
• Более 30 тысяч уникальных пользователей; одна из особенностей бизнеса — большая автономность магазинов и доступ к отчетам у сотрудников всех уровней, от менеджмента до продавцов.
  
• Более 1000 отчетов, анализирующих разные процессы.
  
• А главное — отсутствие взаимодействия между командами и каких-либо единых стандартов разработки.

Сотрудников с разным уровнем компетенций становилось все больше, а адекватной платформы для коммуникации между ними не было. Тогда в 2022 году решили создать BI Community, в рамках которого объединились все, кто имеет отношение к аналитике и визуализации данных. Не только BI-специалисты, для которых создание отчетов — профессия, но и умельцы из других сфер, в том числе со стороны заказчиков.

Первым шагом стала организация группы в корпоративной соцсети, где фиксируются ключевые темы и новости про BI внутри компании, а также существует чат для обмена опытом: каждый может без стеснения задать свой вопрос или ответить на чужой.

Следующим этапом стала организация регулярных встреч, даты которых бронируются в календаре на год вперед. Ежемесячно на площадку приходит более полусотни человек — как профессионалы, так и те, кто только развивается в профессии и хочет получить новые знания и компетенции.

На встречах озвучиваются важные новости и поднимаются темы, имеющие отношение к BI-разработке, — как технические, так и бизнес. Например, изменение правил публикации отчетов, запуск процесса входящего ревью, особенности работы с DWH, инструменты DQ/DG. На этих же встречах мы проводим мастер-классы и обучение от опытных разработчиков.

В какой-то момент наработок сообщества стало слишком много. Появилась необходимость их качественно агрегировать, и тогда базу знаний перенесли в Wiki. Туда выкладываются все гайды, записи BI Talks, обучающие материалы и лекции, а также важные для разработки инструкции (онбординг, доступы и т. д.).

Экспертная группа

Довольно быстро стало понятно, что для адекватного развития сообщества необходимо, чтобы инициатива исходила изнутри.

Тогда в 2022 году из числа наиболее вовлеченных и экспертных представителей профессии, а также специалистов ключевых ролей, влияющих на BI (devrel, менеджер BI-сервиса, руководитель практики), собрали экспертную группу. Первыми проектами, за которые она взялась, были стандарты разработки (чек-листы) в части UX/UI и производительности дашбордов.

Со временем экспертная группа стала одним из главных драйверов изменений BI в компании. Именно она отвечает за обучение членов сообщества, исследование и тестирование различных инструментов для повышения качества разработки, выбор целевых BI-сервисов. При этом экспертная группа не является административной единицей. Ее назначение скорее функционально: это своеобразный кружок по интересам, или «совет джедаев», который не управляет остальными специалистами, а создает для них понятные условия работы и делится знаниями, опытом и идеями.

Сообщество и экспертная группа помогли не только углубить и расширить связи между всеми BI-разработчикам, но и подобраться ближе к главной цели — повысить качество отчетов и сделать жизнь пользователей лучше. Но для реальной стандартизации, ввода «минимального уровня разработки», этого было недостаточно.

Читайте также

Что такое deepfake и почему это проблема?

Какие методы обнаружения deepfake существуют? Какие возможности могут предоставить большие языковые модели (LLM) для генерации и обнаружения дипфейков? Расскажем о технологии aIDeepfake для борьбы с фальсифицированным контентом.

Review

В будущем тему ревью мы планируем осветить в отдельной статье. А пока скажем лишь пару слов о том, что оно собой представляет.

В 2023 году случилась миграция с облачного Power BI SAAS на локальный Power BI RS. Вместо одной среды появилось две (тест и прод) — так миграция позволила ввести процесс Входящего review. Идея в следующем.

• Ревью проходят не все существующие отчеты, а только те, которые соответствуют определенным критериям — например, имеют более 10 пользователей.
  
• Для большинства отчетов ревью не становится узким горлышком и не замедляет процесс выкатки в прод: на ревью можно податься уже после публикации, в течение двух недель.
  
• Проверки ревью сформулированы в виде чек-листа — таким образом, чтобы их мог выполнить даже джун, а каждый пункт не занимал больше 5-7 минут.

Для более сложных кейсов — отчетов c непростой бизнес-логикой, моделью данных и «многоэтажными» DAX-формулами — проводится «экспертное ревью». Наиболее опытные специалисты, входящие в экспертную группу, детально анализируют отчет и дают автору рекомендации, что и как можно оптимизировать. Но это только по запросу или в ситуациях, когда отчет сильно влияет на общую производительность сервиса.

Навигатор отчетов

В процессе реструктуризации все сотрудники, которые имеют дело с BI-отчетностью, — как пользователи, так и специалисты — прошли опрос удовлетворенности. Чаще всего люди жаловались на поиск необходимого отчета: их так много, что найти нужный бывает слишком сложно (если не невозможно). Знания о том, где хранится необходимый отчет, передавались сотрудниками практически из уст в уста: для этого существовали кустарно созданные таблицы в Excel, сайты и майндмэпы. Стала очевидна необходимость в понятном инструменте, который помог бы внести в процесс ясность. И этим инструментом стал Навигатор отчетов.

По сути, Навигатор отчетов — это каталог, который объединяет данные об отчетах. Информация поступает в сервис двумя способами.

• Парсер собирает метаданные — например, название отчета, BI-сервис, дату последнего обновления, статистику по пользователям, технического владельца и т. д.
  
• Разработчик отчета в процессе подготовки к ревью вручную вносит сведения о принадлежности инструмента к конкретной теме или бизнес-процессу, краткое описание, ключевые показатели, заказчика и прочую информацию, доступную автору.

Внедрение Навигатора отчетов упростило работу с отчетами не только для пользователей со стороны бизнеса, но и для разработчиков — теперь вместо того чтобы создавать дубликаты, специалист может выполнить поиск и выяснить, что необходимый ему отчет уже существует. Временных ресурсов тратится меньше, а эффективность работы растет.

Обновленная матрица компетенций

Процесс миграции сотен BI-отчетов с SAAS на RS, а также новый процесс ревью подсветили отличающийся уровень компетенций в разных командах. Кто-то из аналитиков прошел через изменения легко, у кого-то они вызвали большие трудности. v Это побудило сообщество и экспертную группу актуализировать матрицу компетенций BI-разработчика. Чтобы она, с одной стороны, подсвечивала сотруднику вектор развития, а с другой — опиралась на потребности бизнеса (так, мидлы должен обладать навыками проведения ревью, сеньоры — dwh-разработки).

Но на этом решили не останавливаться. Теперь навыки data-грамотности все чаще входят в матрицы компетенций различных должностей. Компания также стала проводить обучение для представителей бизнеса — рассказывать, как использовать и создавать отчеты (overview-объяснение того, что находится «под капотом», путь данных от источника к BI). Так у пользователей, которые часто являются заказчиками и участвуют в группе разработки, появляется понимание технических этапов. Бизнес и разработчик начинают говорить на одном языке.

Вместо итогов

Изначально сообщество задумывалось как пространство, где специалисты могут обмениваться опытом, задавать вопросы и узнавать новости. Однако со временем роль стала гораздо шире — сейчас сообщество выступает платформой, через которую можно раскатывать обновления и новые стандарты, внедрять глобальные изменения в части BI-разработки, а также менять культуру разработки в целом.

За счет создания экспертной группы появились единые стандарты, гайды и библиотеки, дизайн-системы и требования к визуализации. Со временем их число будет только расти — параллельно изменению требований бизнеса.

Благодаря ревью и Навигатору отчетов, создание и поиск отчетов стали процессами более понятными и прозрачными. Теперь разработчики реже создают разные версии правды и не дублируют работу друг друга, а пользователи могут оперативно найти интересующую их информацию.

Наконец, сообщество стало толчком к усилению институционализации профессии BI-разработчика: итоги встреч и работы экспертной группы вылились в обновленную матрицу компетенций. Сотрудники понимают, чего ждут от специалистов разного уровня, имеют четкий карьерный трек, а также осознают, каких навыков им не хватает для смены профессии или направления. И более того, теперь компания ожидает наличия data-навыков еще и у специалистов, которые связаны с созданием отчетов лишь косвенно.

Что будет дальше?

В планах на ближайшее время — синхронизировать матрицу компетенций с планом обучающих встреч и марафонов, чтобы давать разработчикам возможность приобрести новые навыки, необходимые для успешной работы BI-специалиста. А еще — выпуск первого тестового потока студентов внутренней школы BI, где учатся бизнес-пользователи, желающие сменить свою роль. Но это совсем другая история.

Если же говорить в общем, это далеко не все, о чем мы хотели бы сказать в рамках BI-сообщества. И в следующих статьях мы продолжим делиться своим опытом выстраивания BI-ландшафта, в том числе подробнее сфокусируемся на упомянутых в статье аспектах и их перспективах.