Гораздо приятнее руководить командой опытных разработчиков, а не командой новичков. Однако на рынке труда очень мало опытных разработчиков, у них большие запросы и за них огромная конкуренция. Что делать? Один из способов — вырастить своих сеньоров из мидлов и джунов. В этой статье я опишу свои методики как можно ускорять профессиональный рост сотрудников. Это не окончательный список, не какой-то стандарт, а просто описание моего опыта руководства двумя командами разработки. Методы работают у меня, значит возможно сработают и у других. Просьба коллег тоже делиться своими подходами в комментариях. Итак, поехали.

Наставничество

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

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

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

Встречи один на один

Какие-то обсуждения нельзя или нецелесообразно выносить на общие встречи. Для этого существует разговор тет-а-тет. Обычно я начинаю с общих вопросов, например узнаю, как у сотрудника дела. Бывает, что человек приуныл или есть значимые проблемы. Такие встречи помогают снизить кадровые риски и избавиться от недопонимания. Можно отправить человека в отпуск, сменить задачи, посоветоваться со смежниками или что угодно ещё. Здесь же доносятся зоны роста сотруднику по принципу «хвалить публично, ругать наедине».

Так же я обычно собираю предпочтения по задачам. Например, если Васе нравится конфигурировать сборку, а Пете раскрашивать кнопки, и у нас есть и те и другие задачи. Разумно распределить им задачи учитывая их предпочтения. Снижаются кадровые риски, растёт вовлечённость и стремление профессионально развиваться.

Личный план развития

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

Часто мы вкладываем много сил в процессы, которые и так хорошо работают, и не замечаем, что нас тормозит. План развития помогает предотвратить это.

Архитектурные встречи

У меня есть теория о трёх уровнях развития разработчика:

1. на первом уровне разработчик осваивает синтаксис, знакомится с основными конструкциями языка. Этот уровень проводит границу между неразработчиком и джуниор-разработчиком. Нам это не очень интересно: те, кто прошёл собеседование, уже преодолели начальную ступень
2. на втором уровне разработчик осваивает логические конструкции и алгоритмы. Он умеет дробить код на модули и функции, собирать из набора функций работающее решение. Здесь пока не рассматривается вопрос масштабируемости, расширяемости, отказоустойчивости, гибкости и т.п… Этот уровень отделяет джуниора от мидла. Рост легко достигается наставничеством и код-ревью
3. на третьем уровне разработчик начинает задумываться об архитектуре программы. Тут приходит осознание целесообразности паттернов, слабой связанности, разделения ответственности компонентов и т.п… Этот этап самый долгий, он отделяет мидла от синьёра, разработчика, который может просто писать фичи и разработчика, который может сам с нуля спроектировать и запустить новый большой сервис. Для того, чтобы обеспечить рост разработчика на этом уровне и нужны архитектурные встречи. Расскажу, что это такое

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

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

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

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

Чтения кода

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

Мы начали устраивать встречи с чтением исходников популярных опенсорс-решений нашего стека. На них мы разбираем, какие подходы помогли этим решениям стать успешными, и обогащаем свой арсенал решений. Встреча длится час, первые 10 минут каждый разработчик выбирает участок кода, файл или папку, которую будет анализировать. Далее на 15-20 минут все отключаются и анализируют код. Потом мы снова собираемся и по очереди рассказываем с демонстрацией экрана, что интересного нашли на своём участке.

Первое что меняется в головах — рушатся мифы и суеверия о лучших практиках. Например, разработчик где-то слышал, что очень плохо мутировать переменные, но и React, и TypeScript и VS Code и много других решений делают это у себя под капотом, до сих пор живы, и даже очень успешны. Видимо, эта рекомендация не критична для хорошего решения. Далее от проекта к проекту начинают замечаться похожие принципы, новые подходы к организации логики. У разработчика расширяется арсенал концепций и решений.

Есть ещё два очень практических следствия:

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

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

Пишите в комментариях, если было интересно или есть что дополнить. Было бы очень интересно послушать, кто какие ещё способы применяет. Желаю успешного профессионального развития и талантливых коллег!