Как ответить
Сейчас, оглядываясь назад, я бы изменил подход к онбордингу и системе метрик. Основная проблема была в том, что разработчик, показавший себя отлично на собеседовании, столкнулся с иным уровнем требований к production-коду, чем он привык. Вместо того чтобы сразу давать ему сложные задачи, я бы внедрил более прозрачную систему отслеживания прогресса и обязательные ревью кода на первой неделе.
Конкретно, я бы сделал следующее:
- Убрал неопределённость в задачах. Поставил бы чёткие, маленькие задачи на первые 2 недели с дедлайнами и критериями готовности — например, «написать тесты для модуля X, покрытие 80%». Когда этого не было, разработчик тратил дни на исследование вместо поставки кода.
- Добавил код-ревью с конкретными чек-листами. Вместо общих пожеланий «улучшить качество» мы бы прописали требования: чистая архитектура, обработка ошибок, логирование. Я бы сам делал ревью первых 5 PR и требовал править до прохождения.
- Дал открытые метрики. Я бы показывал доску с трекингом: сколько задач закрыто за спринт, сколько багов найдено на код-ревью. Это смещает фокус с «я работал 8 часов» на «я сдал рабочий код вовремя».
- Провёл ретроспективу через 2 недели. Прямой разговор без оценок: «Я вижу, что сложности с деплоем — что конкретно мешает?».
Почему возникла ситуация? Я не уделил достаточно времени онбордингу в первые дни. У нас был быстрый найм, и я надеялся, что опытный разработчик «сам разберётся». А он ждал инструкций. К третьей неделе образовался долг по code review, и конфликт стал очевиден. Сейчас я знаю: для senior-разработчиков критично показать их влияние в первую неделю — если этого не происходит, человек начинает чувствовать себя ненужным и делает либо лишнюю работу, либо ничего.
Дополнительно, я бы провёл небольшой сессионный демо через день после завершения каждой задачи — не формальный звонок, а просто показать результат. Это сразу выявило бы расхождение в ожиданиях. Такой подход сократил бы время на выявление проблемы с трёх недель до трёх дней.