Одна из задач тимлида — помогать каждому в команде развивать профессиональные навыки. Однако, накопив за годы определённый опыт, мы часто начинаем думать, что окружающие тоже всё это знают. На самом деле для сеньоров и других лидов это зачастую так, но разработчикам же с меньшим стажем всегда есть чему поучиться и куда расти. Как же помочь развитию сотрудников?
Подходы, которые я использую для развития своей команды, можно условно разделить на два направления: индивидуальное развитие и обмен знаниями.
Индивидуальное развитие
Регулярные встречи 1:1
Постановка целей (SMART)
Условия для роста (ИПР, время на обучение)
Матрица компетенций
Регулярные встречи один на один (1:1). Личные встречи с каждым разработчиком позволяют не только поговорить по душам, но и в спокойной обстановке выяснить, в каком направлении человек хочет развиваться и с какими проблемами сталкивается. Если в процессе работы возникали сложности, на такой встрече можно дать конструктивную обратную связь и обозначить точки роста — то есть области, на которые, по вашему мнению, ему стоит направить усилия. Даже если видимых проблем нет и улучшать, казалось бы, нечего, стоит спросить самого разработчика, чего бы ему самому хотелось достичь.
Постановка целей. Очень важно следить за тем, чтобы личные цели разработчика соотносились с целями бизнеса. Так рост навыков пойдёт на пользу и специалисту, и компании: сотрудник прокачается в нужных областях и станет более ценным кадром. Определив цели, помогите найти способы их достижения — например, подходящие курсы, книги, мастер-классы. Здесь тимлид выступает в роли ментора, который делится опытом и направляет подопечного. Цели при этом должны быть достаточно небольшими, чтобы их реально было достичь за адекватное время. Чтобы цель была достижимой и понятной, удобно применять шаблон SMART — так вы не поставите невыполнимых или размытых задач. Правильно сформулированные цели имеют сроки и измеримые ключевые результаты (в числовом выражении: проценты, показатели, возможно даже деньги).
Условия для роста. Разработчик не сможет развиваться, если его полностью завалить рутинной работой или требовать учиться лишь в свободное время. Обязательно выделяйте под развитие небольшой процент рабочего времени и явно оговорите это с командой. Если для достижения цели нужны платные курсы или мероприятия — логично, чтобы их оплачивала компания. Это часть вклада бизнеса в развитие специалиста и показатель реальной заинтересованности. По результатам обучения можно дать сотруднику задачу (или несколько), в которых он применит и закрепит новые знания на практике.
Собрав все точки роста и утвердив цели, вы формируете для сотрудника гибкий индивидуальный план развития (ИПР). В будущем этот план позволит наглядно показать прогресс специалиста.
Матрица компетенций. Порой сложно сразу понять, как увязать цели развития конкретного инженера с задачами компании. В таком случае может помочь матрица компетенций. Возьмите стек технологий, который используется (или планируется к использованию) в проектах вашей компании, и на его основе составьте список знаний и умений, которыми должен обладать разработчик по каждому направлению. Вовсе не обязательно, чтобы тимлид досконально знал все эти технологии сам — определить необходимый стек и требования к знаниям могут и сами сотрудники на общем обсуждении. Задача лида при этом – убедиться, что в списке только действительно востребованные технологии, без излишних крайностей. Готовую матрицу компетенций полезно обсудить на 1:1 с каждым разработчиком. Такой разговор покажет, где у человека есть пробелы и хочет ли он их заполнить. В итоге вы вместе определите персональные точки роста и составите чёткий вектор развития для каждого разработчика в команде.
Но стоит учесть, иногда разработчик хочет расти в одном направлении, а проект — про другое. В таких случаях я стараюсь найти точку пересечения: задачи, в которых можно развивать нужные навыки без ущерба продукту. Но если пересечения нет — важно честно признать это. Бывает, что текущий проект просто не подходит под цели конкретного человека. Это нормально.
Обмен знаниями в команде
Внутренние митапы и сообщества
Документация и статьи
Перекрёстные задачи и ревью
Парное программирование и менторство
Культура делиться опытом. Нужно стараться создать атмосферу, в которой разработчики чувствуют потребность и возможность обмениваться знаниями. Яркий пример из моей практики — создание внутреннего комьюнити (сообщества) по интересам, где специалисты регулярно собирались, чтобы обсуждать накопившиеся вопросы и совместно искать решения. Если актуальных тем нет, можно предложить разработчику просто поделиться, чему он научился — как решил сложную задачу, закрыл цель из ИПР или, например, написал библиотеку, которую теперь можно использовать в других проектах. Остальные участники сообщества могут дать обратную связь, высказать идеи или просто задать вопросы. Если кто-то из сотрудников чувствует в себе достаточно опыта и уверенности, можно поощрить его провести внутренний митап и рассказать о своих достижениях более широкой аудитории — например, всей компании.
Доклад, статья или код — формат не так важен, главное — польза. Отлично работает практика внутреннего inner-source (когда код и наработки открыты для всей компании) и ведение технических статей. Полезно также по всем важным процессам и технологиям развивать внутреннюю документацию. Это поможет не только будущим поколениям разработчиков, но и самим авторам — оформить свой опыт на бумаге, лучше структурировать и углубить знания.
Все эти инициативы по обмену знаниями со временем приводят к заметным результатам. В моей команде специалисты начали сами подтягивать друг друга в изучении нового. Коллектив выровнялся по уровню скиллов, ребята прокачали навыки взаимодействия. Как следствие, повысилось качество кода и решений, которые команда выдаёт в задачах.
Конечно, построение полноценного внутреннего сообщества — шаг непростой (отдельная история, о которой я как-нибудь расскажу подробнее). Однако есть и более простые приёмы, доступные любой команде для ежедневного обмена знаниями:
Перекрёстные задачи. Разработчики периодически меняются зонами ответственности или участками кода. Это улучшает погружение каждого в разные части проекта, заставляет команду постоянно взаимодействовать и совместно искать оптимальные решения.
Перекрёстное ревью кода. Инженеры ревьюят код друг друга, знакомясь с чужими подходами. Важно при этом не перегибать палку: ревью не должно превращаться в тормоз для задачи или повод для бесплодных споров — у каждого ведь свой стиль написания кода.
Парное программирование. Двое разработчиков садятся за одну задачу и решают её совместно. В процессе такой сессии они обмениваются приёмами и идеями, перенимают друг у друга полезные практики. Но, важно не навязывать формат — лучше предложить его в качестве эксперимента.
Менторство. Наставничество одного сотрудника над другим. Более опытный коллега, объясняя материал, сам глубже погружается в тему, а начинающий специалист получает ценные знания, которые сразу может применить в работе.
Иногда может выглядеть так, что все эти активности отнимают слишком много рабочего времени. Но на практике они только улучшают показатели. Команда растёт профессионально, технический долг сокращается, сложные проблемы решаются сообща и гораздо быстрее.
Отношение бизнеса к развитию разработчиков
Опытные программисты обычно сами следят за трендами и знают, куда хотят расти — им никакие подсказки или формальные ИПР не особенно нужны. А вот деньги нужны всем: разработчики хотят повышения зарплаты. Тогда они приходят к руководству с таким запросом, а если не получают желаемого, то просто уходят туда, где платят больше.
Бизнес, конечно, заинтересован в повышении эффективности, но при этом не слишком хочет раздувать расходы. Поэтому нужно как-то аргументировать, почему программисту нельзя сейчас поднять зарплату — и желательно так, чтобы он ещё и понял, что пока рано. В дело идут аттестации, грейды, performance review, индивидуальные планы развития. Сотруднику предлагают показать, чему он научился за последнее время и как выросла его ценность по сравнению с моментом найма. И начинается долгий процесс. Если пустить его на самотёк, «эффективные менеджеры» составят чек-лист требований и будут оценивать разработчика по принципу «знает / не знает». Абсурд, когда человека увольняют по результатам такого performance review.
Крупные компании давно поняли, что лучше не ждать и поэтому делают процесс развития более прогнозируемым. Они вводят формальные ступени роста для разработчиков: условно раз в полгода сотрудника повышают на один грейд. За это полагается небольшой бонус — например, немного опционов или акций, единовременная премия, корпоративный мерч, незначительная прибавка к окладу. У каждой компании система грейдов своя. Как правило, эти ступени мало что меняют в реальной работе и дают совсем скромный прирост дохода, но всё же это лучше, чем ничего.
Но задачи, спущенные сверху без учёта личных целей разработчика и сведённые лишь к сухим метрикам, легко могут демотивировать разработчика. Эффективнее подход, при котором развитие определяется совместно: и бизнес, и сотрудник понимают, зачем нужны поставленные цели.
Мотивация тимлида и проактивный подход
Сам тимлид также прямо заинтересован в росте своей команды. Важно работать с профессионалами, расти вместе с ними и делать продукт, которым можно гордиться. Итоги проектов и сильная команда — то, что делает тебя тимлидом, за которым стоит результат. Поэтому в работе я стараюсь найти золотую середину между интересами команды и бизнеса, чтобы каждая сторона получила своё.
Бизнесу — качественный продукт, разработчикам — рост и комфортная атмосфера. Возможности для повышения и развития — должны соответствовать желаниям сотрудников. Но это возможно, только если команда приносит компании ощутимую отдачу — условно в 1,5 раза от её затрат, чтобы оставаться ценным активом.
Важно при этом быть проактивным. Не ждать, когда программист сам придёт с просьбой о развитии или повышении, а постоянно помогать ему расти — так компания будет заранее видеть отдачу от его роста. После существенного прогресса сотрудника (в рамках ИПР или в рабочих достижениях) я стараюсь сам просить о прибавке для него. Это лучше, чем ждать, когда руководство «предложит помощь для оптимизации процессов» в вашей команде.
TL;DR
Помогать развитию разработчиков — это задача тимлида
Регулярные 1:1, совместная постановка целей и гибкие ИПР — это инструменты роста
Развитие разработчиков должно нести пользу как разработчику так и бизнесу
Это должно быть частью рабочего времени и поддерживаться компанией (включая оплату).
Если цели сотрудника и задачи бизнеса расходятся — ищите точки пересечения. Если их нет, это тоже нормально.
Обмен опытом внутри команды, внутренние метапы, ревью и менторство помогают развиваться.
Тимлид, который умеет выстраивать сильную команду и достигать с ней результата, сам развивается.
