Методика STAR и система «бадди»: три небанальных совета по управлению IT-командой

Начнем с самого важного — диагностики.

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

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

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

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

Метод помогает выявить, как человек действовал в прошлом. Например, можно спросить: «Расскажите о ситуации, когда в команде возник конфликт. Как вы его решили?». Если кандидат четко описывает ситуацию, задачу, свои действия и результат, это хороший знак.

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

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

Если в первые месяцы рядом с новичком работает наставник,  более опытный коллега, который поможет разобраться в работе и поделится лайфхаками — адаптация проходит быстрее. У нас система «бадди» входит в онбординг. Опытный сотрудник помогает новичку узнать, как устроены процессы, какие приняты форматы взаимодействия, как решать бытовые и рабочие вопросы. Иногда роль бадди может пересекаться с ролью руководителя.

Внутри команды можно организовать регулярные воркшопы, где сотрудники делятся опытом. Например, наши разработчики могут провести сессии разбора кода (от англ. code review), а аналитики — обсудить лучшие практики обработки данных. Сотрудники также учатся друг у друга в процессе обычной работы. Кроме того, в нашей компании есть архитектурный комитет — еженедельные встречи тимлидов, где они обсуждают новые технологии, варианты решений и способы их применения в текущих и будущих проектах.

В нашей внутренней академии сотрудники выступают спикерами и делятся своими знаниями. Кто-то делится опытом с конференции, кто-то показывает практики моделирования, например, как красиво и понятно рисовать BPMN (англ. business process model and notation — нотация моделирования бизнес-процессов. Это стандартный графический язык, который использует набор символов и правил для визуализации, документирования и анализа бизнес-процессов от начала до конца. — Прим. ред.), а кто-то  обучает смежные команды. Так, технический директор может рассказать HR-отделу о базовых принципах разработки или провести внутренний ликбез по архитектуре.

Это инструмент, который помогает точечно прокачивать навыки сотрудников. Пример: через 6−8 месяцев работы у нового разработчика появляются первые успехи и зоны роста. Вместе с руководителем они составляют план: какие технологии изучить, какие навыки подтянуть. Если сотрудник хочет вырасти до тимлида, в его ИПР организовываются курсы по управлению командой (плюс менторство со стороны опытного руководителя). Но это всегда инициатива двух сторон: если развитие навязывается только сверху, у сотрудника может не быть интереса. Поэтому мы строим процесс по принципу win-win (в переводе с английского языка — выигрыш-выигрыш) — сотрудник получает возможность расти, а компания  развивает нужные компетенции.

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

Например, если основная разработка ведется на PHP (англ. hypertext preprocessor — препроцессор гипертекста — скриптовый язык программирования для бэкенд-разработки) и Vue (от англ. user interface — пользовательский интерфейс. Фреймворк для создания пользовательских интерфейсов — фронтенд-разработка. — Прим. ред.), а к нам приходит проект, где все реализовано на Java (это другой язык, требующий совершенно иного подхода), внешний специалист может проконсультировать по архитектуре, подобрать подходящих разработчиков, помочь сформировать команду.

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

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

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