Недавно я сменил работу и, как все новички, столкнулся с трудностями адаптации на новом месте. Предыдущие 5 лет я работал в одной компании и выступал стороной, принимающей людей в команду. И вот мне довелось побывать на их месте.

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

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

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

Как часто вам приходилось слышать фразу «код — это лучшая документация»? Согласен на все 100 %, только код в master-ветке однозначно может сказать, как ведёт себя система. Но новичку от этого не легче. Пусть у меня есть код, а в какой момент он вступает во взаимодействие с соседним приложением? А почему тут сделано именно так? А как пройти клиентский путь в приложении, которое только готовится к релизу? Что таит в себе legacy-монолит на Perl? Всё это новому члену команды только предстоит узнать, и остаётся лишь пожелать ему сил и терпения, а параллельно молиться, чтобы они не закончились раньше, чем опустятся руки разработчика или бывший коллега напишет ему в Telegram: «Пс, а ты работу не ищешь?». Или мы можем с этим что-то сделать? В первую очередь, давайте честно признаемся себе, что описанная мной ситуация не является исключительной. Если вы вспомните проекты, над которыми работали, то поймёте, что это, скорее, норма. И нам как-то нужно научиться с этим жить.

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

Итак, держим в голове, что документация не исчерпывающая. Но как же в таком случае новый член команды узнает обо всём, что нужно? Как в древности до изобретения письменности основным способом передачи информации была устная речь, так и разработчики передают огромное количество информации просто разговаривая друг с другом. Поэтому отличным способом погружения человека в команду является наличие приставленного к нему разработчика, который в первые 2-4 недели будет отвечать на огромное количество вопросов, рассказывать скрытые логические правила предметной области и посвящать в таинства пайплайнов. Другими словами, выберите из команды желающего и назначьте его наставником, который кроме общения в Slack будет проводить ежедневные созвоны минут на 10-15. Если у вас уже есть daily внутри команды, то этого достаточно. Главное, покажите, что на нём можно задать вопросы и получить ответы. Кстати, наставник — не обязательно самый опытный член команды; достаточно, чтобы он знал не сами ответы на вопросы, а где и как их заполучить.

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

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

Пока я редактировал текст, осознал, что и сам не всегда придерживаюсь этого правила. И я хорошо понимаю, почему так происходит: я воспринимаю работу как что-то личное. Поэтому некоторые вопросы очень чувствительны для меня. Как нибудь обязательно расскажу, как я над этим работаю.

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

Что держит вас на вашей работе? Почему вы не ищите другое место? Почему я работал в одной и той же компании целых пять лет? Мне было интересно (и интерес не угас, я ушёл не по этой причине). На каждом этапе своей деятельности — от развёртывания первого микросервиса до техлидерства над командой, в ведении которой было под сотню микросервисов, — мне всегда было интересно. Я никогда не скучал целый спринт. Были рутинные задачи, иногда бывало однообразно, но каждый спринт я узнавал что-то новое. И именно это, по-моему, самое крутое в нашей работе: она доставляет удовольствие, позволяя решать интересные задачи. Также в поддержку этого суждения говорит не только мой опыт. Лучшие профессионалы, с которыми я работал, покидали свои позиции именно в тот момент, когда у них угасал интерес.

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

Небольшое отступление. Из дел по дому моё любимое — мыть посуду. Почему? В детстве мама научила меня этому простому делу и хвалила каждый раз, когда я хорошо с ним справлялся. Хитрый был ход с её стороны, не правда ли? Положительное подкрепление в виде похвалы позволило заниматься делом достаточно долго и старательно, чтобы овладеть им. А когда что-то получается, то и заниматься им одно удовольствие. И вот спустя десятки лет я по-прежнему люблю мыть посуду.

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

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

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

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

Несколько месяцев назад я думал, что количество необходимого внимания, которое стоит уделять новому члену команды, обратно пропорционально его опыту. Серьёзно, разве нужна вся эта чепуха с наставником и заботой о первых задачах матёрому сеньору? Кидай ему любую историю, прожуёт и не заметит, да ещё сверху вам улучшений в архитектуру насыпет. Однако после своего испытательного срока я понял, что это не так. После пяти лет работы в одной компании мне было очень сложно окунуться в новый проект. И самая большая сложность, которую устранить просто невозможно, — это непонимание предметной области. Я просто не знаю, что правильно, а что нет, как нужно делать, а как не стоит. Из-за этого я могу отлично закодить нелогичное поведение. Сюда же наслаивается очень серьёзный стресс не просто из-за незнания, а из-за утраты компетенций: на старом месте я не только досконально знал работу приложений и продуктов своей команды, я неплохо представлял глобальные процессы внутри компании и мог предложить пару альтернативных решений для любой встреченной проблемы. А что теперь?

Если вы думаете, что описанные мной приёмы могут пригодиться только тем, кто занимается адаптацией новых сотрудников, то это не так. Используйте их, если и сами сменили работу: берите инициативу в свои руки! Вам не назначили наставника? Активно общайтесь и задавайте вопросы более опытному коллеге. Принимать нового человека в команду тоже бывает волнительно, а такое общение, когда с вами делятся опытом, может успокоить и расположить к вам членов команды. Кажется, что вам пока дают лишь неважную мелочёвку для расширения кругозора? Замечайте места в проектах, где вам интересно было бы покопаться, и приносите пользу там. Разобравшись в очередном кусочке логики, документируйте его или делайте более очевидным. За это вся команда только скажет вам «спасибо», и процесс интеграции пройдёт гораздо приятнее.

Надеюсь, вам было интересно читать мои мысли. Понимаю, что приведённые советы ситуативны и воспользоваться ими можно не всегда, однако все они родились из практического применения адаптации новичков и собственного перехода на новое место. Больше всего мне хочется, чтобы вы запомнили, что смена работы — это большое испытание для человека с любым опытом, сталкиваться при этом с трудностями абсолютно нормально, а попытаться помочь своему новому коллеге — отличная идея.