Привет, Хабр! Меня зовут Павел Иванов, я работаю в AWS и последнее время выступаю ментором для наших стажёров и новичков.

– «А что пушить?» – «Всё по задаче». – «И тесты тоже?»

Этот короткий диалог когда-то ввёл меня в ступор на несколько секунд. После него я стал замечать: чем опытнее становишься, тем сложнее вспомнить, каково это – не знать тех вещей, которые со временем стали чем-то привычным и естественным. Для ментора это базовые рабочие рефлексы, а для стажёра – тайные знания, которыми никто не поделился. В итоге оба попадают в ловушку взаимного непонимания: один считает своё объяснение исчерпывающим, упуская десяток «очевидных» для него деталей и нюансов, а другой молча закапывается в проблему и, начав двигаться в неверном направлении, теряет ценное время.

В этой статье я собрал свой список таких навыков, и поделил их на две группы: неочевидные пробелы – слепые зоны для нас, менторов; и очевидные пробелы – то, чему можно и нужно научить новичка прямо сейчас, не дожидаясь, пока «само придёт с опытом».

Итак, поехали.

Неочевидные пробелы: что менторы упускают из виду

В этом блоке собраны моменты, которые поначалу по-настоящему удивляют. Это те самые слепые зоны, где ловишь себя на мысли: «Как этого можно не знать?». Для опытного инженера они естественны, как дыхание – он выполняет действия на автомате и может искренне удивиться, что новичок думает и делает совершенно иначе.

«И тесты тоже?»

Диалог про тесты выше – как раз пример такой слепой зоны. Дело не в том, что стажёр не знал, как пользоваться Git. Его вопрос показал, насколько у нас различаются картины мира.

Для него «продукт» – то, что работает, и «вспомогательные материалы» – вроде как черновики. Для инженера с опытом понятие «исходный код проекта» гораздо шире. Тесты, файлы конфигурации CI/CD, скрипты сборки, документация – всё это его неотъемлемая часть. Это не «вспомогательные» файлы, а часть фундамента проекта, гарантия его здоровья и поддерживаемости.

Тут важно не просто дать инструкцию, а объяснить концепцию. Показать, как тесты автоматически запускаются в пайплайне после каждого пуша, как они реально спасают от выкатки багов. Когда новичок видит, что эти «вспомогательные» части приносят ощутимую пользу всей команде, вопрос «а что пушить?» отпадает сам собой.

Настоящий смысл ownership

Пожалуй, самое опасное заблуждение, с которым я сталкивался в менторстве, связано с овнершипом. В крупных компаниях, особенно в Amazon с его Leadership Principles, культуре ownership уделяется значительное внимание. Но вот в чём парадокс:

• Что думает ментор: «Ты овнер задачи, значит, несёшь ответственность за её успешное завершение. Используй все доступные ресурсы».

• Что слышит стажёр: «Ты овнер задачи, значит, должен сделать всё сам. А просить помощи – значит расписаться в своей некомпетентности».

В итоге стажёр молча перерабатывает и боится эскалировать проблемы. Почему так происходит? Я для себя объясняю это аналогией с вождением машины. Дать стажёру ownership – это как посадить его за руль, но остаться сидеть рядом, готовым нажать на тормоз. Если же он понимает это как «тебя высадили на трассе и сказали «добирайся сам»» – катастрофы не миновать.

Я стараюсь внести ясность как можно раньше: ownership – это не про то, чтобы делать всё в одиночку, а про то, чтобы довести дело до результата. Умение вовремя привлечь помощь, поднять тревогу, когда что-то идет не так – это и есть признак сильного овнера.

Понимание ценности тестирования

Зачем нужны тесты? Уверен, большинство инженеров скажут, что это инструмент проектирования, сеть безопасности и экономия времени в будущем. А теперь задайте тот же вопрос стажёру. Для него тесты – зачастую досадная формальность, которую требует злой CI, чтобы поставить зелёную галочку. Он не видит в ней ценности, потому что ещё не платил за её отсутствие своим временем и нервами в 3 часа ночи.

Задача ментора – донести простую мысль: тесты – это самый эгоистичный инструмент разработчика. Это машина времени, которая позволяет тебе из будущего проверить, не сломал ли ты что-то важное сегодня. Они заставляют продумать крайние случаи и дают уверенность при рефакторинге. Когда стажёр осознаёт, что тесты – его личный инструмент, который экономит его же время, отношение меняется.

Критерии готовности (Definition of Done)

Что значит «задача готова»? Скорее всего, в голове сразу всплывает чек-лист: код написан, тесты зелёные, документация обновлена, код прошёл ревью, смёржен, задеплоен…

Для стажёра же «готово» – это часто просто «у меня на машине работает». Но есть и обратная сторона, этакий «синдром отличника», когда он может до бесконечности «полировать» фичу, добавляя улучшения, о которых его не просили, когда всё уже давно соответствует критериям готовности.

Чтобы избежать крайностей, в самом начале работы над задачей необходимо составить конкретный чек-лист: «Эта задача считается выполненной, когда…». Такой список даёт стажёру чёткую цель и редко отнимает больше десяти минут.

Опыт эксплуатации: мир после git push

Код смёржен, фича выкачена. Конец истории? Для стажёра – да, он мысленно ставит галочку и переходит к следующей задаче. Для команды – только начало. Начинается жизнь кода в продакшене.

Мир метрик, алертов, логов и дежурств для новичка часто остаётся за кадром. Важно погружать стажёров в него как можно раньше. При постановке задачи полезно задавать вопросы:

• «Как мы будем измерять успешность этой фичи? Какие метрики нам нужны?» 

• «Какие алерты стоит настроить, чтобы узнать о проблеме раньше пользователей?» 

• «Что должно быть в runbook (инструкции для дежурного) на случай инцидента?»

Поначалу эти вопросы ставят в тупик, но они формируют мышление, ориентированное на надёжность. Код – это не артефакт, который нужно сдать, а сервис, который должен стабильно работать.

Краткая проектная документация (RFC/one-pager)

«Зачем писать этот документ, я же могу просто пойти и сделать?» – классическое заблуждение новичка. Для него RFC или one-pager – ненужная бюрократия. На самом деле one-pager – это не отчёт, а чертёж будущего здания. Прежде чем заливать фундамент, этот чертёж нужно показать опытным архитекторам (команде). Они посмотрят на него свежим взглядом и скажут: «Смотри, вот тут стена несущая слабая, а здесь без окна будет темно».

Найти изъян в плане на бумаге – это огромный успех, а не провал, ведь это экономит недели работы. Ментор может не догадаться, что стажёр уже начал «строить», ни с кем не согласовав проект. Поэтому даже для небольших проектов стоит просить набросать план на одну страницу: проблема, предлагаемое решение, альтернативы, их плюсы-минусы.

Ориентирование в инструментах

Помню, как мой стажёр потратил полтора дня на изобретение собственного велосипеда с блекджеком и регексами для работы с именами компонентов в разных регионах. Когда он показал мне результат, я был в недоумении: «Погоди, а почему ты не взял нашу библиотеку X? Она делает ровно то же самое одной строчкой». Ответ был обезоруживающе прост: «А я не знал, что она есть».

И тут я понял: я ему о ней не рассказал. Эта библиотека была для меня настолько базовой и очевидной частью нашего стека, что я просто забыл, что о её существовании можно не знать. Этот случай показывает, что наш привычный набор инструментов – это тёмный лес для новичка. Поэтому в начале онбординга обязательный пункт – провести краткую экскурсию по нашей «велостоянке»: «Смотри, для логов мы используем вот это, для метрик – вот то, а для задач типа Y – вот эту волшебную библиотеку X».

Очевидные пробелы: чему можно и нужно научить явно

Здесь всё проще — мы знаем, что у новичков нет этих навыков, но часто надеемся, что они появятся сами. Появятся, но не сразу. Зато их можно довольно быстро сформировать, если дать конкретные инструменты.

Умение вовремя попросить помощь (и таймбоксинг)

Самый частый страх стажёра – показаться глупым. Из-за этого он может часами биться над проблемой, которую можно решить за 15 минут разговора. Чтобы сломать этот барьер, отлично подходит таймбоксинг.

Мы договариваемся: «На самостоятельное исследование этой проблемы у тебя есть, скажем, 4 часа. Пробуй всё, что считаешь нужным. Но если через 4 часа ты всё ещё в тупике, ты не просто можешь, а должен прийти ко мне. Сформулируй, что ты пробовал и где застрял, и мы разберемся вместе». Это простое правило снимает с новичка груз ответственности за «неудачу» и превращает просьбу о помощи из признания слабости в плановый этап работы.

Планирование и оценка задач

Никто не ждет от стажёра точной оценки сроков, но научить его декомпозиции – прямая обязанность ментора. Большая и страшная задача «Сделать фичу Y» вгоняет новичка в ступор? Нужно показать, как «есть слона по частям»! Вместе разбить задачу на маленькие, понятные шаги: «1. Изучить API. 2. Написать прототип клиента. 3. Реализовать основной сценарий. 4. Написать тесты. 5. Поправить UI». Такой план делает прогресс видимым, снижает тревожность, а радость от вычеркивания очередного пункта служит отличной мотивацией.

Проверка идей на практике

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

Стажёра стоит научить мыслить как учёный-экспериментатор: прежде чем строить мост, нужно перекинуть через пропасть верёвочку и проверить, что на другом берегу есть за что цепляться. Proof of Concept (PoC) – быстрый, черновой прототип, который проверяет самую рискованную часть гипотезы. Потратить день на PoC, чтобы понять, что идея нежизнеспособна – это огромный выигрыш, а не потеря времени.

Проактивная коммуникация и проверка предположений

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

Стажёр (в личку коллеге из другой команды): Привет! Можешь посмотреть мой PR?  Коллега: Привет! Да, видел, посмотрим. 

One week later…

Стажёр (в отчаянии): Ну что там с моим PR? У меня всё горит! 
Коллега: Ой, прости, замотались. А там всё надо переделывать…

Что здесь произошло? Стажёр действовал на основе целого букета неверных предположений:

• Он предположил, что его подход к решению верный (не проверил). 

• Он предположил, что коллега знает о важности и срочности его PR (не предупредил). 

• Он предположил, что PR проверят сегодня-завтра (не договорился о сроках).

Здесь работает простой принцип: любое предположение нужно проверять. Любая зависимость от другого человека – это риск, которым нужно управлять. Правильный диалог выглядел бы так: «Привет, команда X! Мне для моей задачи нужно ваше ревью. Это блокер, и было бы здорово получить фидбек до пятницы. Скажите, это реально?». Такой подход превращает пассивное ожидание в активное управление ожиданиями.

Польза отчётов и видимость рисков

Как увидеть проблему, которую не видит сам стажёр? Здесь помогает такой инструмент, как короткий письменный апдейт для команды в конце недели. Периодичность, структура, степень детализации и горизонт планирования могут быть разными, но важно договориться: у любого следующего шага должна быть дата. Не «займусь тестированием», а «закончу тестирование к среде, 3 сентября». Отсутствие даты – само по себе сигнал, что план не продуман, для самого стажёра в том числе.

В первую очередь, апдейт полезен самому стажёру: он заставляет структурировать мысли и зафиксировать план, а не держать в голове все риски и шаги. Но его главная ценность – дать опытному коллеге возможность увидеть проблему, которую новичок ещё не осознаёт. Например, стажёр пишет в плане: «Вторник – разворачиваю сервис на тестовом стенде». Он не видит в этом подвоха. А коллега или сам ментор знает, что для доступа к этому стенду нужна заявка, которая одобряется два-три дня, часто не с первого раза. Увидев это в пятницу, он говорит: «Подай заявку на доступ прямо сейчас». Простое действие, которое спасает стажёра от простоя и вероятного срыва сроков.

Культура Code Review

Для стажёра первое код-ревью – это почти всегда стресс, ведь легко принять замечания на свой счёт. Задача ментора – с самого начала показать, что ревью – это не экзамен и не критика автора, а совместная работа над улучшением кода.

Стоит объяснить две вещи. Во-первых, как готовить хороший PR: разбивать изменения на маленькие коммиты, писать понятное описание. Это проявление уважения ко времени коллег. Во-вторых, как принимать фидбэк: не спорить, а пытаться понять точку зрения ревьюера. Задавать вопросы: «Почему так будет лучше?». Важно донести, что правки получают все, от джуна до принципала. Это нормальная, здоровая часть процесса.

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

В заключение

Менторство – это про терпение и эмпатию. Про умение вспомнить себя на старте и сделать путь для новичка проще. Наша роль – не просто давать задачи, а подсвечивать слепые зоны и делиться подходом к работе, которого не найдёшь в учебниках.

Главное, что должен почувствовать стажёр: команда его не оценивает, а хочет научить. Тогда он не побоится задать «глупый» вопрос или показать недоделанный результат. Вы, как ментор, получите отдачу: через несколько месяцев перед вами будет уже самостоятельный разработчик, внесший свой вклад и благодарный за полученные знания – а команда получит мотивированного и сильного специалиста. Такой результат окупает все усилия.

А с какими неочевидными пробелами у стажёров сталкивались вы? Делитесь своим опытом в комментариях, обсудим.