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

В этом посте мы поговорим о том, как формат сообществ (чаптеров) помогает нам в работе. Для этого мы подробно побеседовали с Михаилом Благовым, лидером чаптера инженеров данных. Еще нам помогали Николай Безносов (чаптер Data Science) и Артём Смирнов (Data Analytics).

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

Первый — формат центров компетенций (ЦК). Это специальные подразделения внутри компании, в которых концентрируются все знания в конкретной области. Собственно, отсюда и название. В случае с инженерами данных — это все знания по анализу и обработке данных.  И когда у кого-то из коллег возникает задача, требующая, скажем, продвинутой аналитики, то все знают — надо просто сходить в соответствующий ЦК, там вам и помогут.

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

Второй — работа в продуктовых командах. Главное отличие от ЦК тут вот в чем — в формате продуктовых команд сотрудники на все 100 погружены в бизнес-задачу, а владелец продукта при этом сам управляет своей командой. Решение задач в области телекома, таких как, например, улучшение работы колл-центра, работа с оттоком клиентов, оптимизация качества сети и борьба с мошенничеством требуют быть на оперативной связи с владельцем бизнес-процесса.

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

Но здесь на помощь приходят чаптеры.

Зачем чаптеры, если есть продуктовые команды?

Можно сказать, что необходимость структуры чаптеров возникла из-за ключевого недостатка Agile и чисто продуктового подхода — из-за сложности обмена знаниями между независимыми командами.

Просто представьте — допустим, у вас один большой дружный департамент. Типовые процессы, типовые вопросы. Любые проблемы быстро решаются. Если кто-то придумывает какую-то полезную штуку, скажем, улучшенный мониторинг ML-моделей, то это можно быстро раскатать и внедрить у остальных.

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

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

Структура чаптера

Чаптер — это горизонтальная структура. Сообщество, которое объединяет спецов одного профиля. Например, миссия наших чаптеров — рост и развитие (как профессиональное, так и карьерное) членов чаптера, накопление и распространение экспертизы по ML, анализу и инжинирингу данных, продвижение в компании data driven-подхода. Такие себе профсоюзы-2023 :) Только без членских взносов.

Главное, что должно быть у чаптера — это лидер. Он и драйвит весь процесс. Лидер чаптера (он же «глава чаптера») зачастую даже не является административным руководителем для нижестоящих сотрудников. Он именно лидер самого чаптера как сообщества, но при этом не входит в систему административного или функционального подчинения. 

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

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

Задачи, которые решает чаптер

Телеком — это просто прорва различных задач, потому что бизнес изначально многогранен, вот лишь часть:

• прогнозирование спроса на устройства в салонах связи, 

• определение новых потенциальных точек для расширения покрытия, 

• оптимизация качества сети, 

• борьба с оттоком, классические задачи рекомендаций,

• обработка обращений клиентов в колл-центрах,

• видео- и аудиоаналитика,

• антифрод;

• антиспам,

• геоаналитика,

• предсказание проблем на сети,

• автоматизация и улучшение взаимодействий с клиентами и контрагентами,

• построение продуктовой аналитики,

• многое другое.

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

Что важно — чаптер не решает за такого сотрудника его задачи, чаптер учит тому, как решить их самостоятельно.

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

Самих данных, с которыми надо работать, у нас сотни петабайт, так что используем классический BigData-стек — код пишем на Python и Scala, данные храним в Hadoop, в общем, здесь без неожиданностей. Стараемся держать инфраструктуру поближе к K8S. Конечно, работа не обходится без взаимодействия с экосистемой хранения данных компании — это различные реляционные и NoSQL-базы данных, шины и очереди сообщений, API и файловые хранилища.

Организация работы чаптера

Так как людей много, и они активно приходят, важно на самом старте создать в удобной для всех системе Welcome Guide и другие документы для быстрого онбординга и погружения в тему.

Документация — это очень важный элемент в работе специалистов по данным, мы стараемся поддерживать ее в максимально актуальном состоянии (хотя бы по ключевым вопросам). 

Что касается бытия лидером чаптера, тут важно делегировать. Например, со временем часть собеседований можно делегировать другим опытным сотрудникам. Собеседование, кстати, это не просто про набор людей — это очень важный этап, и процесс собеседований надо выстраивать максимально эффективно. У нас были случаи, что на собеседовании кандидат выбирал билайн, а не конкурентов, именно потому, что ему понравился сам процесс интервью (всестороннего) и команда. 

Не забывайте, что все хотят работать в сильной команде, и именно собеседование — ваш шанс доказать кандидату, что вы из таких.

Развитие участников чаптера

Мы активно организовываем митапы и встречи по обмену опытом, так что это избавляем нас от ситуации, когда кто-то оказывается в пузыре и не знает, чем заняты коллеги.

Потому что одна из главных задач чаптера — это рост и развитие сотрудника. Каждый хочет понимать, как из джуна вырасти в мидла и что конкретно для этого сделать. Или как стать тимлидом. Для всего этого мы внедрили максимально прозрачную систему оценки. Каждый сотрудник оценивается по трем параметрам:

1. Hard Skills — владение определенными инструментами и технологиями, нужными для работы (Scala или Python, Spark, знание экосистемы, ML или Deep Learning).

2. Soft Skills — насколько человек активен, самостоятелен, ответственен.

3. Performance — для бигтеха стандартная метрика, формата «соответствует ожиданиям», «превосходит ожидания» и подобное. Это про отражение вклада сотрудника в чаптер в целом.

Для hard&soft-скиллов у нас есть матрица компетенций с оценками от 0 до 5, и для ясности мы прописали ожидания для каждого балла. То есть у сотрудника тут не будет вопросов, почему у него 4, а не 5, например. 

Оценка проходит примерно раз в полгода (иногда раз в год). Сотрудник проходит самооценку по этим трем параметрам, затем эксперты чаптера оценивают его hard skills, а руководители продуктовых команд — soft skills + performance. Из комбинации этих оценок и складывается итоговый уровень сотрудника (от Junior до Expert).

Ложка (чайная) дёгтя — минусы чаптеров 

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

Стоит активно следить за матрицей компетенций, потому что если отойти от неё в сторону, то рост чаптера по профессиональным компетенциям может замедлиться.

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

Важным остается фактор нагрузки на лидера чаптера — иногда, когда людей в чаптере много (как и задач), чисто физически не всегда получается уделять всему этому 100% внимания.

И главное: чаптер — это не центр компетенции. Он не поможет вам с выделением бюджетов или с предоставлением инженеров в формате «спец на час».

Кому чаптеры подойдут, а кому — нет

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

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

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

Ведь без этого очень сложно развиваться.