Долгих дней и приятных ночей! Я Наталия Курченкова, IT Project Manager с 10+ лет опыта. Сегодня разберём поучительный кейс из моей практики — как «идеальный» senior-разработчик оказался на двух работах одновременно, и что мы изменили после этого случая.
Контекст проекта
Наша команда из 10 человек разрабатывала мобильное приложение для итальянских ученых с жестким графиком релизов (каждый месяц) и дорожной картой на 1,5 года вперед. В рамках расширения мы искали senior-разработчика под сложные задачи, включая интеграцию с собственным устройством, которое находилось в стадии исследований.
Идеальный кандидат... на бумаге
Новый сотрудник (назовем его Алекс) выглядел безупречно:
- Сильное резюме с опытом в известных компаниях
- Активный GitHub с релевантными проектами
- Отличное прохождение технического собеседования
На этапе найма он демонстрировал глубокие знания, работал из дома (на фоне была обычная кухня), оперативно отвечал на вопросы. Мы сделали оффер. Важное замечание - кандидат был из другой страны.
Первые тревожные звоночки
Уже на втором месяце онбординга стали заметны странности:
- Несоответствие слов и действий
На дейликах: «Сегодня точно залью PR», но код не появлялся днями с размытыми объяснениями
На пинги: «Решаю сложный баг» не давал конкретных деталей
На предложения созвониться отвечал «Через час» и часто пропадал на полдня - Странные условия работы
Все встречи 1:1, груминги, планирования проходили без видео (говорил что у него плохой интернет)
В редких включениях камеры — мы видели один и тот же фон с абстрактным узором
Постоянный шум на заднем плане (комментировал так: «я в коворкинге») - Необъяснимые пропажи
Исчезал на 3-4 часа в рабочее время
Не отвечал на срочные сообщения перед релизами
Момент истины
Когда задержки по простой задаче превысили неделю без четких объяснений, мы устроили серьезный разговор 1-1. Алекс объяснил, что он живет в пригороде без стабильного интернета и ежедневно ездит за 100 км в более крупный город («работаю в кафе или коворкинге»). А фича никак не доделывается из-за постоянных разнообразных сложностей (то доступ пропадет, то ноут вырубится без сохранения, то проект не билдится).
Но история не сходилась. Я стала подробно разбираться в ситуации:
- Анализ видеозаписей:
Я проанализировала видеозаписи (которые были сделаны с согласия кандидата по всем корпоративным правилам) и заметила интересный факт: до найма Алекс на всех звонках сидел на домашней кухне. Когда начались проблемы, везде уже на фоне был одинаковый фон с логотипом, как оказалось, зарубежного банка (гугл-картинки помогли) - HR-проверка:
Я посоветовалась с HR о проблеме, и они решили проверить резюме кандидата, и в нем действительно последним местом работы числился зарубежный банк. HR позвонили туда и, оказалось, что Алекс официально числился в том самом банке на полной ставке. Его «коворкинг» был офисом основного работодателя, а шум на фоне - разговоры коллег.
Выводы и системные изменения
Этот случай заставил нас пересмотреть процессы, чтобы минимизировать такие кейсы в будущем:
1. Необходимо вводить четкие критерии испытательного срока, понятные, достижимые и согласованные.
- Например, не «сделать 5 задач», а конкретные вехи:
Неделя 1: Разобраться в архитектуре, собрать проект локально
Неделя 2: Закрыть первый простой MR с ревью
Месяц 1: Реализовать небольшую фичу от начала до прода
2. Прописать конкретные правила в команде, с которыми знакомы все, например:
- Если задача «висит» больше 2 часов без прогресса — сразу просить помощь
- MR не должен ждать ревью дольше 1 рабочего дня
- Важное напоминание команде, что дейлики — не для отчетов, а для блокеров (если что-то не получается, говорим сразу). Да-да, до сих пор многие воспринимают дейлик как просто статусную встречу.
3. Наставник для senior-ов не должен расслабляться
- Нужно помнить, что даже если ваш "подопечный" - senior - это не значит что он и так уже все лучше знает. В любом случае нужен мониторинг и контроль, чтобы помочь влиться в проект или предотвратить проблемы. В нашем случае наставник был слишком уверен в кандидате.
- Наставник проводит 1:1 2-3 раза в неделю первый месяц (их всегда можно пропустить если нет вопросов). Это позволит держать руку на пульсе и вовремя отловить сложности и помочь. Либо увидеть красные флаги.
- Помнить про Code-review всех задач, даже «простых».
4. Проверка условий работы
- HR теперь уточняет: Есть ли стабильный интернет? Совмещает ли кандидат работу? Готов ли он к нашему графику встреч?
- Некоторые компании запрашивают фидбек с предыдущего места работы
- В моей практике был опыт, когда меня при приеме на работу просили прислать контакты людей, которые могли бы меня рекомендовать
Главный урок: Удаленка требует не только доверия, но и прозрачности. Чем четче правила, тем меньше недопонимания. Наш кандидат, кстати, в итоге, не прошел испытательный срок.
P.S. После этого случая наш HR перед наймом гуглил фоны на собеседованиях. На всякий случай
#УдаленнаяРабота #ITкоманды #УправлениеПроектами #УдаленныйКонтроль #ITменеджмент #ОшибкиНайма