Когда я возглавил отдел разработки в Sape, вокруг меня появились интересные, классные ребята со своими сильными сторонами. У нас было много неформальных практик: общение, обмен опытом, поддержка, но не хватало измеримости. И мы начали постепенно внедрять и оцифровывать процессы.

В этой статье я расскажу, как мы это сделали: от структуры команд и регулярных архитектурных встреч до неожиданных инструментов вроде новогодних книжных подарков. Покажу, как встречи один на один помогают каждому сотруднику найти свой вектор развития, а Performance Review превращает разговоры о развитии в реальные планы. Все с конкретными примерами из нашей практики.

Структура команд отдела Link Building

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

Вертикаль определяет уровни ответственности у лидера кластера, юнит-лидов и тимлидов, а оперирует в конечном счете с кросс-функциональными командами:

Вместе с тем, существует и горизонтальный уровень, который соответствует функциональным командам: frontend, backend, QA, UX, DevOps. У каждой из них есть свой лидер, хотя на практике эти роли могут совмещаться:

Теперь познакомлю с нашими практиками. Налейте себе чаю и устраивайтесь поудобней!

Встречи по архитектуре и технологиям

Такие встречи зародились в 2022 году, когда созрело понимание: необходимо собрать всех разработчиков компании, чтобы поговорить о том, как мы строим архитектуру приложений (на тот момент уже появилась внутренняя Платформа разработки), обсудить базовые технологии, а для многих ребят — в принципе познакомиться с ними.

Первые 10 встреч проходили в формате лекций с презентациями 1 раз в спринт. Мы говорили о тестируемости кода, принципах проектирования баз данных, платформенных компонентах (системе внутренних событий, аутентификации, Sape Platform). Кстати, появившиеся на Хабре материалы Как проектировать спецификации OpenAPI для SPA: теория и практика и Конечные автоматы на практике: Symfony Workflow основаны на этих лекциях.

Со временем формат начал меняться. У разработчиков сформировалось общее понимание базовых вещей, и мы смогли двигаться дальше. Мы расширили аудиторию и стали приглашать сотрудников QA, продуктовых менеджеров, DevOps, тимлидов — всех, кто хочет быть в курсе технологической повестки компании. На встречах мы обсуждали новые тенденции в мире IT: построение Data Lake и Data Mart, федерализацию данных, облачные базы данных, Functions и многое другое. При этом не забывали и о том, что появляется в корпоративной Платформе, а значит, становится доступно для использования всеми. Разработчики видели потенциальные инструменты, менеджеры — их применение в продуктах, а системные администраторы оценивали, как это все будет жить на их серверах.

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

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

Книги на Новый год

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

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

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

Регулярные встречи разработчиков: фронтенд и бэкенд

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

Фронтендеры встречаются в формате обсуждения новых технологий и инструментов. Например, использование Cursor для разработки получило широкое распространение именно благодаря таким встречам: кто-то показал, как он автоматизирует написание кода, и коллеги подхватили. Участники с большим опытом приносят «на посмотреть» новые сборщики (так мы перешли на Vite) и фреймворки (когда-то с этого началось наше знакомство с Composition API во Vue и внедрение TypeScript). В случае с TypeScript было важно, чтобы «гильдия фронтендеров» коллективно приняла нововведения и была готова тратить силы на освоение.

У бэкендеров встречи проходят в формате публичного code-review. Есть 2 варианта обсуждения:

• берем уже состоявшееся интересное ревью и оба участника делятся впечатлениями, а остальные задают вопросы;

• выносим на ревью то, что еще никто не смотрел, и проводим его совместно. 

На этих встречах часто осваиваются новые конструкции языка, потому что обязательно находится тот, кто начинает их использовать. Так мы внедряли строгую типизацию в PHP, конструкции с match, enum’ы и многое другое.

Периодичность встреч — 1 раз в спринт. Здесь важно то, что ребята выравниваются в образе мышления и понимании качества кода (которое нельзя охватить статическими анализаторами). Формируется общее представление о нормальном в коде, что ускоряет проведение ревью и избавляет команды от конфликтов.

1-to-1 в функциональных командах

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

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

Вот выдержка из корпоративной wiki:

1. «Свободный микрофон» для сотрудника. Как идут дела? Как настрой? Есть ли какие-то сложности? Особенно важно отметить зону риска – системную неудовлетворенность работой, риск ухода из компании. В случае обнаружения такого риска нужно связаться с руководителем.

2. Обсуждение хода развития сотрудника. Что изменилось с прошлой встречи? На что можно нацелиться в плане развития? Если есть запрос на направленное обучение, его нужно запросить через HR BP и включить в план.

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

Среди инструментов, которые показывают куда развиваться разработчику, у нас есть инфополе по «соприкосновению с технологиями». В задачах Jira мы указываем в качестве компонентов те подсистемы или модули системы, к которым эти задачи относятся. Благодаря этому мы понимаем, с чем ребята работали и когда:

Лид может предложить разработчику поработать по продуктовой задаче или по багу с чем-то, с чем тот еще не имел дела. Это тоже способ расти.

Встречи и их результаты фиксируются в корпоративном портале, поэтому у меня как руководителя отдела есть возможность видеть, насколько своевременно они проводятся:

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

Performance Review

Систему Performance Review мы позаимствовали у коллег из Avito, поэтому не буду пересказывать ее в деталях, если интересно — вот оригинал. На мой взгляд, они отлично описали этот фреймворк, а актуальная версия поддерживается на Github.

По результатам составляется примерно такая карточка сотрудника:

Нормативная периодичность проведения — раз в полгода.

Выводы

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

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

Желаю всем тимлидам вырастить свою самую мощную и дружную команду!