Срыв покровов: как организовать онбординг для QA

Представь: нового человека бросили в работу. Он не понимает, где что лежит, к кому идти с вопросом, что вообще от него хотят. Проходит месяц — и он уходит. Или остаётся, но выгорает.
А ментор? Ему некогда, он сам в дедлайне. Или его уже нет — уволился.
Получается замкнутый круг: бесконечный подбор → текучка → выгорание менторов → кадровый голод. Разорвать его можно только осознанным онбордингом.

Это не «познакомить с командой». Это сократить время, пока новый человек не приносит пользу.
Ввести в компанию. Показать продукт. Настроить доступы и инструменты. Познакомить с людьми. И — главное — вовлечь и удержать.
Причём это не задача одного ментора. Это работа компании (HR), проекта (команда) и практики (коллеги, лид, руководитель). Если что-то выпадает — страдает вся цепочка.

Ситуация первая: ты ментор. Или просто старший, к кому «подкинули» новичка.
Что чувствуешь? «Я не знаю, что с ним делать», «Нет времени», «А документации нет».
Это нормально. И вот что помогает:

• Спросить у руководителя, что вообще нужно
• Найти, кто может помочь из смежных практик
• Взять человека под «крыло»
• Оценить его уровень и понять, куда вести
• Записывать всё — чтобы не повторять дважды
• Давать право на ошибку

Ситуация вторая: у тебя несколько человек, ты несёшь за них ответственность, но индивидуального подхода нет. И интеграции с другими практиками — тоже.
Что делать:

• Остановиться и понять, что тебе надо
• Подключить других инженеров
• Собрать структуру онбординга — хотя бы простой чек-лист
• Собирать обратную связь
• Обновлять информацию «подаванами»

Не изобретай велосипед. Начни с простого и дорабатывай по ходу.

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

• Не ломать то, что есть — дорабатывать
• One-to-one — персонально
• Стандартизировать процесс
• Регулярно рассказывать, что происходит
• Показывать результат