Обучение и развитие ИТ-команды, ее развитие и управление

Создание ИТ-команды, ее развитие и управление – это одна из главных задач руководителя отдела frontend-разработки. Развитие и управление подразумевает не только улучшение навыков сотрудников, но и совершенствование операционных процессов. За многолетнюю практику в должности руководителя отдела я сформулировал для себя методы подбора и развития ИТ-команды, которые помогают ей не только успешно решать текущие задачи, но и максимизировать скорость, качество бизнес-процессов.

Cамые частые проблемы в управлении ИТ-командой в компаниях

Когда я вступил в должность руководителя frontend-отдела, я увидел, что разработчики в компании действуют изолированно, и это создает высокий bus-factor и технический долг. Не было никаких унифицированных стандартов разработки. Нельзя было спокойно поменять разработчика на проекте, и если кто-то уходил из компании, то создавался простой. Чтобы решить эту проблему, я внедрил единый технологический стек и стандарты разработки, включая архитектурные регламенты и стиль кода. Также был введен cross code-review для повышения взаимодействия внутри команды и поддержания стандартов.

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

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

Техники найма ИТ-команды

Для среднестатистического проекта (от 4000 часов) нужна команда, состоящая из:

1. Трех frontend-разработчиков (один лид и двое разработчиков)
   
2. Четырех backend-разработчиков (один лид и трое разработчиков)
   
3. Одного project maganer
   
4. Двоих человек из команды в отдел SEO
   
5. Двоих тестировщиков
   
6. Одного DevOps-инженера
   
7. Двух-трех UX/UI дизайнеров

Для найма разработчиков мы разработали конкретный порядок отбора кандидатов. Начинаем с анализа текущих потребностей:

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

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

Пример базовых требований к должности lead frontend:

1. Опыт разработки от 3 лет
   
2. Опыт управление командой от 1 года 3
3. Грейд не ниже middle+
   
4. Экспертные знания в собственном стеке
   
5. Развитые soft skills

Также лид Лид обязан проводить ежедневные встречи со своей командой для уточнения статуса, планов и блокеров. Лид делает декомпозицию проекта и планирует задачи, делает ревью и следит за сроками выполнения задач/проекта со стороны своего отдела; проводит синки с другими отделами.

Этапы найма:

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

1.1. Тестовое задание (опционально). Этот этап мы применяем для начинающих специалистов или тех, у кого мало опыта, чтобы более детально оценить их профессиональные навыки.

2. Собеседование на soft skills. На этот этап мы выделяем около одного часа, в течение которого обсуждаем с кандидатами их личные качества, поведение в спорных ситуациях, которые могут возникнуть на работе. Это помогает выявить лидерские качества (или их отсутствие), умение работать в команде.

Пример вопросов на собеседовании:

1. Сценарий конфликта: "Вы работаете над важным проектом с коллегой, но ваши мнения по поводу выполнения задания существенно расходятся. Что будете делать?"
   
2. Сценарий управления временем: "Ваш руководитель дает вам два важных проекта/задачи с одинаковыми сроками. Вам кажется невозможным выполнить оба проекта качественно и в срок. Как вы распределите свое время и ресурсы, чтобы максимально эффективно справиться с этой задачей?"
   
3. Сценарий управления временем №2: "Представьте ситуацию, где вы берете на себя задачу с четко установленными сроками. В процессе работы вы понимаете, что не сможете выполнить все задачи в срок из-за непредвиденных обстоятельств. Что будете делать?"

3. Собеседование на hard skills. Это полноценное техническое интервью на 1-1.5 часа, на котором мы тестируем профессиональные знания и умения кандидата. Это интервью проводят техлид и опытный разработчик. Они делят интервью на несколько секций: знакомство и small-talk, вопросы по знаниям технологий, небольшой live-кодинг простых практических задач.

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

Далее идет блок простых вопросов по требуемым технологиям. Если мы говорим про Javascript, то вопросы будут вроде таких:

• Расскажите все, что знаете про асинхронность: что это, для чего, как работает и как реализована?
  
• Какие хранилища есть в браузере, какая разница между ними и что для чего нужно использовать?
  
• Что такое фреймворк Vue, для чего мы его используем? Какие в нем есть особенности и/или недостатки по сравнению с другими фреймворками? Какие конкретные особенности Vue?

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

И последний блок этого этапа собеседования нужен для закрепления результата live-coding. Здесь мы даем простые практические задания, чтобы понять, как человек может разбивать задачу на маленькие подзадачи и решать действительно практические вещи.

Например:

• Необходимо представить, что у нас нет встроенных методов map, filter, reduce. Нам нужно реализовать полный аналог любыми другими доступными средствами. Главное, чтобы сохранилась вся логика и функционал исходных методов.
  
• Реализовать бесконечную ленту постов. У нас есть готовое апи и кандидату нужно сделать так, чтобы при загрузке страницы подгружалось 5 новостных блоков. И когда мы доходим до предпоследнего, подгружать еще 5 следующих блоков. И так до бесконечности. В момент загрузки предусмотреть лоадер.
  
• Реализовать собственные функции debounce b throttle
  
• Реализовать простой сервис для поиска с помощью апи и выдачу подсказок.

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

У меня есть несколько «красных флагов», при наличии которых рассматривать кандидата бессмысленно:

1. Безответственность и отсутствие пунктуальности.
   
2. Полное отсутствие развитых soft skills и лидерских качеств.
   
3. Не может справится с простыми техническими заданиями и не имеет навыков, о которых заявлял.
   
4. Отсутствие понимания и принятия корпоративной культуры.

Как организовать рабочие процессы для ИТ-команды

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

Командные встречи

1. Ежедневные стендапы (дейлики). Каждый день мы проводим короткие встречи, где команда обсуждает статус текущих задач, выявляет возможные блокеры и формулирует планы на день. Это позволяет нам быстро реагировать на изменения и поддерживать высокий уровень продуктивности.
   
2. Еженедельные собрания. Один раз в неделю мы подводим итоги прошедшей недели, анализируем ключевые метрики и планируем следующий спринт.

Индивидуальные встречи

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

Tech-review встречи

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

Развитие кадров и мотивация ИТ-команды – есть ли отличия от других сфер?

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

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

Образовательные программы. Предоставляем компенсацию за обучающие курсы, тренинги и семинары, включая курсы по изучению новых технологий или языков. Например, наш сотрудник на frontend захотел освоить backend, чтобы попробовать себя в качестве full-stack. Мы без проблем компенсируем часть или полную стоимость лучшего курса, который подойдет под его цели и задачи.

Система мотивации для ИТ-команды включает четко прописанные KPI и условия премирования.

KPI для разработчиков это:

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

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

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

Например, мы считаем эффективным 6-часовой рабочий день, поэтому всегда планируем задач на 126 часов. Оставшиеся 2 рабочих часа в день мы отдаем под любые другие процессы: звонки, чтение, обдумывание, или чтобы просто перевести дух и отдохнуть между задачами. Поэтому если сотрудник выполнит задачи на 150 часов за предусмотренные 126 часов, он получает премию за экономию времени и увеличение продуктивности.

Отдельные премии могут быть выданы за успешное завершение особо сложных или критически важных проектов. Например, за закрытие сложного проекта мы можем выдать ему премию в размере 50% от оклада (при среднем окладе 250.000 рублей премия составит 125.000 рублей).

Выбор лидера

Я внедрил в свою работу регламент определения лидера и сформулировал культуру лидерских принципов.

Семь основных лидерских принципов:

1. Лидер жаждет вызовов — он всегда готов столкнуться с трудностями.
   
2. Лидер берет инициативу — не ждет указаний сверху, сам предлагает решения.
   
3. Лидер играет в команде — умеет работать с другими, ценит вклад каждого.
   
4. Лидер довольствуется малым — может достигать целей с минимальными ресурсами.
   
5. Лидер ведет людей — вдохновляет и мотивирует команду на достижение общих результатов.
   
6. Лидер берет полную ответственность — готов отвечать за исход всего проекта.
   
7. Лидер постоянно учится — не останавливается на достигнутом, постоянно развивает свои навыки.

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

Параметры качества работы разработчиков

Результат работы разработчика надо проверять еженедельно и ежемесячно. Мы проводим недельные спринты с очень детальной декомпозицией задач с оценкой не более 6 часов. То есть в день мы закрываем минимум одну большую задачу. В реальности же прилетает много небольших задач по 2-4 часа, которые в сумме закрывают от 6 часов в день. Поэтому отследить прогресс и метрики достаточно легко уже через неделю.

Особое внимание надо уделять следующим параметрам:

1. Время решения инцидентов (Time to Resolution). Этот параметр отражает среднее время, необходимое для решения инцидента или проблемы. Улучшение этого показателя свидетельствует о повышении эффективности работы команды.
2. Качество кода и количество багов. Оценка качества кода может включать анализ количества багов, найденных после релиза, и серьезности этих багов. У нас есть внутренний style guide и общепринятые стандарты кода, поэтому следование общекорпоративным правилам мы также отслеживаем в результате code-review. Меньшее количество критических ошибок и быстрое их устранение указывают на высокое качество работы разработчиков.
3. Соблюдение сроков проекта и задач (On-time delivery).
4. Производительность команды (Team Productivity). Этот параметр можно измерять количеством выполненных задач, объемом проделанной работы или достигнутыми результатами в рамках каждого спринта или периода.
5. Использование ресурсов. Это оценка эффективности использования времени, бюджета и технических средств. Оптимизация ресурсов при сохранении или улучшении качества работы указывает на улучшение управленческих навыков и процессов.