Зачем существуют профессиональные конференции? Зачем одни подают заявки на доклады, стремятся поделиться практическим опытом или личным мнением относительно того или иного вопроса? Зачем другие платят не маленькие деньги, покупают билеты, слушают, о чём говорят первые?

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

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

В чём проблема

Для понимания проблемы следует рассмотреть организационную структуру департамента. 

• Департамент состоит из множества дирекций, во главе которых стоят технические директора (СТО). У каждой дирекции свой СТО. 

• В подчинении СТО находятся менеджеры (ИТ-Лидеры), которые управляют кросс-функциональными командами. 

• Команды, в свою очередь, состоят из специалистов разных компетенций, в т.ч. системных аналитиков, разработчиков, тестировщиков. 

Таким образом, в каждой дирекции сосредоточен свой пул системных аналитиков со своими руководителями.

Данная структура приводит к тому, что системные аналитики развиваются преимущественно в рамках своего структурного подразделения. У них формируются собственные локальные решения — стандарты, модели и инструменты. В результате приходится поддерживать во многом похожие X стандартов, Y моделей и Z инструментов. Причём не редко возникают и конфликтные ситуации.

Возьмём Дирекцию А и Дирекцию В. Обе занимаются развитием одной и той же Системы.

• Дирекция А считается платформенной, она задаёт стандарты и инструменты разработки для Системы.

• Дирекция В является продуктовой, она использует Систему для доставки продуктов клиентам банка.

Дирекция B решила использовать подход Docs as Code для ведения проектной документации на Систему — ставка на ревью изменений и версионирование артефактов. Дирекция А использует Confluence — ставка на WYSIWYG и скорость внесения изменений. В результате для ведения документации на Систему используются разные инструменты. 

Попытки Дирекции А перевести Дирекцию В на другой инструмент ожидаемо встречают сопротивление.

• Во-первых, уже много документов написано с использованием подхода Docs as Code. Перенос их в Confluence потребует незапланированных затрат.

• Во-вторых, «мы самостоятельная дирекция и сами решаем, как нам жить».

Как же избежать создания «велосипедов», сократить количество конфликтов и начать работать на общее благо?

Было решено запустить сообщества, которые объединяли бы носителей одной компетенции независимо от их структурного подразделения — сообщества по компетенциям. Это неформальные структуры, в которых отсутствуют отношения «руководитель — подчинённый». Главными двигателями сообщества являются общение и компромисс.

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

Этап I. Сообщество системных аналитиков

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

Для достижения поставленной цели были запущены ежемесячные встречи, на которых участники сообщества (aka системные аналитики) и коллеги от смежных направлений (devrel, архитектура, безопасность) выступали с докладами и отвечали на вопросы сообщества. Встречи позволили:

1. Познакомиться со спикерами и их инициативами.

2. Сэкономить время на распространение информации (один доклад на сообщество вместо N докладов на N подразделений).

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

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

Лайфхак: На основе материалов, выносимых на встречи сообщества, в рамках развития Tech-бренда можно готовить выступления для внешних площадкок: митапов и конференций. В частности, вот доклад того самого Спикера N на TAGES Analytics MeetUp 2023.

Вначале были сложности. Потенциальные спикеры не знали, о чём рассказать. У них не было ни времени, ни мотивации для подготовки выступлений. В первом квартале 2023 нам не удалось найти даже одного спикера. Однако впоследствии ситуация изменилась. И если раньше лидеры сообщества активно искали спикеров как внутри, так и вне департамента, то теперь участники сообщества и смежных направлений всё чаще сами предлагают темы выступлений.

Этап II. Площадка для координации

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

Изначально совместно планировать инициативы по развитию компетенции предполагалось на уровне технических лидеров системного анализа. Однако эта модель не подтвердила свою жизнеспособность.

• Во-первых, технических лидеров было сравнительно много (несколько десятков на одного лидера компетенции). Наладить и поддерживать контакт со всеми с учётом кадровых перестановок и текучки было затруднительно.

• Во-вторых, не всегда технические лидеры даже одной дирекции могли договориться друг с другом. Что уж говорить про то, чтобы договориться с остальными дирекциями?

Решением данной задачи стало выделение в каждой дирекции по одному главному техническому лидеру.

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

Главные технические лидеры (за редким исключением) начали появляться в четвёртом квартале 2024. А уже вначале 2025 были запущены еженедельные встречи, на которых обсуждаются вопросы развития компетенции, планирование и координация общих инициатив. Таким образом, например, была спланирована раскатка унифицированной модели оценки знаний и навыков системного аналитика на весь департамент.

Этап III. Специализированные площадки

За полгода взаимодействия на уровне главных технических лидеров дирекции смогли выровняться по ключевым инициативам. Вместе с этим начал ощущаться недостаток ресурса для развитие существующих (RUN) и создание новых (CHANGE) общих решений.

Поэтому было решено начать запускать отдельные специализированные площадки для проработки той или иной инициативы.

На недавно прошедшем митапе Alfa AnalyzeIT 2025 Summer моя коллега рассказывала про ассессмент системных аналитиков в Альфа-Банке. Он строится на базе модели компетенций, определяющей перечень знаний и навыков, которыми должен обладать системный аналитик банка.

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

Данный формат является экспериментальным.

Договариваться с людьми непросто. Особенное, если это незнакомые люди из других подразделений со своим видением «как должно быть». Это настоящий вызов для участников рабочей группы, особенно её лидера. Однако если всё пройдёт успешно, специализированные площадки будут создаваться и для других общих инициатив, коих у нас довольно много.

Подводя итоги

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

В статье поделился собственным опытом построения сообщества по компетенции системный анализ. Возможно, часть из вас найдёт его познавательным. Возможно, другая применит что-то из описанного в своей организации.

Те же читатели, кто сами сталкивался с задачей построения профессионального сообщества, поделитесь в комментариях, как оно было устроено? С какими трудностями пришлось столкнуться? Как удалось их преодолеть? 

Рекомендуем статьи:

Подписывайтесь на Телеграм-канал Alfa Digital. Рассказываем о работе в IT и Digital, делимся полезными советами, новостями, видео с митапов, краткими выжимками из статей и многим другим, иногда шутим.

Подписывайтесь на блог Альфа-Банка на Хабре, впереди много хороших статей.