Недавно я сменил работу и, как все новички, столкнулся с трудностями адаптации на новом месте. Предыдущие 5 лет я работал в одной компании и выступал стороной, принимающей людей в команду. И вот мне довелось побывать на их месте.
В этой статье я хочу поделиться с вами чувствами, которые испытывает человек, пришедший на новое место, а также рассказать о нескольких приёмах, которые с большей эффективностью помогут интегрировать в команду (и чувствовать себя комфортнее) не только новоиспеченного стажёра, но и бывалого ветерана. В старой компании я прошёл путь от бекенд-джуна до техлида и приобрёл там большую часть своих практических навыков.
Не секрет, что чем дольше ты находишься на одном месте, тем лучше понимаешь процессы компании, накапливаешь знания о предметной области, наилучших способах взаимодействия между командами, хитростях работы с инфраструктурой и прочими сопутствующими особенностями работы в конкретном месте с конкретными людьми. И когда новый человек приходит в команду, ему лишь предстоит создать для себя такой же контекст, а задача команды — устранить на его пути все препятствия и как можно сильнее облегчить этот процесс.
Но как это сделать? Очевидный ответ: дать прочесть документацию. Вот так мы развёртываем новые сервисы, вот руководство по ежедневной разработке, вот описание всех тест-кейсов, а здесь расписаны архитектурные стандарты. Ни разу такого не встречал, хоть и работал в разных командах и с большим разнообразием проектов. Документация чаще всего отсутствует или устарела. Если вам повезло и есть readme по конкретному сервису, то информации на уровень выше того, как с этим приложением взаимодействуют остальные микросервисы, скорее всего нет.
Как часто вам приходилось слышать фразу «код — это лучшая документация»? Согласен на все 100 %, только код в master-ветке однозначно может сказать, как ведёт себя система. Но новичку от этого не легче. Пусть у меня есть код, а в какой момент он вступает во взаимодействие с соседним приложением? А почему тут сделано именно так? А как пройти клиентский путь в приложении, которое только готовится к релизу? Что таит в себе legacy-монолит на Perl? Всё это новому члену команды только предстоит узнать, и остаётся лишь пожелать ему сил и терпения, а параллельно молиться, чтобы они не закончились раньше, чем опустятся руки разработчика или бывший коллега напишет ему в Telegram: «Пс, а ты работу не ищешь?». Или мы можем с этим что-то сделать? В первую очередь, давайте честно признаемся себе, что описанная мной ситуация не является исключительной. Если вы вспомните проекты, над которыми работали, то поймёте, что это, скорее, норма. И нам как-то нужно научиться с этим жить.
Всё это не означает, что документацию можно не писать. Пишите, поддерживайте её актуальной, разубеждайте коллег, которые считают, что незачем писать комментарии к очевидным фичам. Ведь не стоит упускать из виду, что фича стала очевидной после того, как на её программирование потратили пару дней, а до этого PO пару недель думал над её идеей.
Итак, держим в голове, что документация не исчерпывающая. Но как же в таком случае новый член команды узнает обо всём, что нужно? Как в древности до изобретения письменности основным способом передачи информации была устная речь, так и разработчики передают огромное количество информации просто разговаривая друг с другом. Поэтому отличным способом погружения человека в команду является наличие приставленного к нему разработчика, который в первые 2-4 недели будет отвечать на огромное количество вопросов, рассказывать скрытые логические правила предметной области и посвящать в таинства пайплайнов. Другими словами, выберите из команды желающего и назначьте его наставником, который кроме общения в Slack будет проводить ежедневные созвоны минут на 10-15. Если у вас уже есть daily внутри команды, то этого достаточно. Главное, покажите, что на нём можно задать вопросы и получить ответы. Кстати, наставник — не обязательно самый опытный член команды; достаточно, чтобы он знал не сами ответы на вопросы, а где и как их заполучить.
Также безумно важно создать атмосферу доверия: новый человек должен понимать, что не знать, спрашивать и просить помощи не стыдно. Достаточно пару раз ехидно отреагировать на вопрос, безапелляционно отбросить предложенную идею или напасть из-за неверного суждения, чтобы получить замкнутого члена команды, который будет уверен, что его идеи здесь не нужны, и начнёт тратить дни на вопросы, которые можно решить за 15 минут, если просто спросить. Так что немного эмпатии всей команде и, в особенности, наставнику точно не повредит.
Подозреваю, что некоторые при прочтении последнего абзаца скажут: «Ну и не нужен нам такой неженка, зачем над ним трястись?». Но я всё-таки придерживаюсь мнения, что нетоксичная атмосфера в коллективе очень ценна и позволяет хорошо чувствовать себя абсолютно всем. Ведь гораздо продуктивнее пустить свои ментальные силы на решение очередного рабочего вопроса, а не на выстраивание щитов от подколок или придирок коллег. При этом нетоксичная ≠ нетребовательная.
Пока я редактировал текст, осознал, что и сам не всегда придерживаюсь этого правила. И я хорошо понимаю, почему так происходит: я воспринимаю работу как что-то личное. Поэтому некоторые вопросы очень чувствительны для меня. Как нибудь обязательно расскажу, как я над этим работаю.
Итак, наставник сильно облегчит жизнь новичку в первое время. Но испытательный срок всё равно остаётся огромным стрессом для сотрудника. Следующий приём мне кажется очень эффективным. Для его использования вам не придётся делать что-то новое, достаточно согласовывать планирование первых спринтов для новоиспеченного члена команды с тем, что я вам сейчас расскажу.
Что держит вас на вашей работе? Почему вы не ищите другое место? Почему я работал в одной и той же компании целых пять лет? Мне было интересно (и интерес не угас, я ушёл не по этой причине). На каждом этапе своей деятельности — от развёртывания первого микросервиса до техлидерства над командой, в ведении которой было под сотню микросервисов, — мне всегда было интересно. Я никогда не скучал целый спринт. Были рутинные задачи, иногда бывало однообразно, но каждый спринт я узнавал что-то новое. И именно это, по-моему, самое крутое в нашей работе: она доставляет удовольствие, позволяя решать интересные задачи. Также в поддержку этого суждения говорит не только мой опыт. Лучшие профессионалы, с которыми я работал, покидали свои позиции именно в тот момент, когда у них угасал интерес.
А интересно на протяжении долгого времени может быть только тогда, когда дело спорится. Вспомните, что вам нравилось в школе и в какие игры вы сейчас любите играть больше всего. Готов поспорить, что в большинстве случае это будут уроки и игры, в которых вы больше всего преуспели.
Небольшое отступление. Из дел по дому моё любимое — мыть посуду. Почему? В детстве мама научила меня этому простому делу и хвалила каждый раз, когда я хорошо с ним справлялся. Хитрый был ход с её стороны, не правда ли? Положительное подкрепление в виде похвалы позволило заниматься делом достаточно долго и старательно, чтобы овладеть им. А когда что-то получается, то и заниматься им одно удовольствие. И вот спустя десятки лет я по-прежнему люблю мыть посуду.
С разработчиком можно поступить схожим образом: создайте для него условия ограниченного, но понятного контекста, в котором он быстро сможет начать приносить пользу, за которую его оправданно можно будет хвалить. Другими словами, дайте ему преуспеть.
Я пробовал знакомить людей со всем по чуть-чуть сразу, это плохо работает и ведёт к разочарованию и усталости из-за излишней сложности. Небольшая область новых знаний, в которой человек отлично разбирается и использует её как плацдарм для дальнейшего знакомства с окружением, показывает себя гораздо лучше, чем знакомство со всем по чуть-чуть без достаточного погружения. Одна зона ответственности позволяет проще вникнуть в рабочие задачи и быстро почувствовать себя полезным, это сильно разогревает интерес к работе. А именно это нужно, если вы хотите комфортной среды для разработчика.
Предостережение: не стоит давать человеку в одиночку создавать новый кусочек вашей архитектуры. Да, этим вы добьётесь того, что человек будет себя отлично чувствовать в своей гавани, потому что он для себя её и создаст. Но в этом и заключается проблема. Разработчик ещё не знаком с принятыми в компании руководствами и подходами, не знает о готовых решениях, возможностях и потребностях смежных приложений. Поэтому сервис может получиться немного в отрыве от вашей специфики и вы будете вынуждены ещё потратить время на «допиливание» под реальные условия, которые формально нигде не зафиксированы, но считались само собой разумеющимися.
Конкретная рекомендация: по собственному опыту могу сказать, что лучше всего дать человеку что-то улучшать, оптимизировать, актуализировать. Например, у вас уже есть готовый сервис, до улучшения которого никак не доходили руки и по нему скопился пул хотелок. Это хороший кандидат на первые задачи для новичка. Но будьте внимательны! Это не должны быть задачи «в стол» или тормошение уже мертвого сервиса. Такое бьёт по мотивации и сильно отодвигает интеграцию нового человека в команду.
Несколько месяцев назад я думал, что количество необходимого внимания, которое стоит уделять новому члену команды, обратно пропорционально его опыту. Серьёзно, разве нужна вся эта чепуха с наставником и заботой о первых задачах матёрому сеньору? Кидай ему любую историю, прожуёт и не заметит, да ещё сверху вам улучшений в архитектуру насыпет. Однако после своего испытательного срока я понял, что это не так. После пяти лет работы в одной компании мне было очень сложно окунуться в новый проект. И самая большая сложность, которую устранить просто невозможно, — это непонимание предметной области. Я просто не знаю, что правильно, а что нет, как нужно делать, а как не стоит. Из-за этого я могу отлично закодить нелогичное поведение. Сюда же наслаивается очень серьёзный стресс не просто из-за незнания, а из-за утраты компетенций: на старом месте я не только досконально знал работу приложений и продуктов своей команды, я неплохо представлял глобальные процессы внутри компании и мог предложить пару альтернативных решений для любой встреченной проблемы. А что теперь?
Если вы думаете, что описанные мной приёмы могут пригодиться только тем, кто занимается адаптацией новых сотрудников, то это не так. Используйте их, если и сами сменили работу: берите инициативу в свои руки! Вам не назначили наставника? Активно общайтесь и задавайте вопросы более опытному коллеге. Принимать нового человека в команду тоже бывает волнительно, а такое общение, когда с вами делятся опытом, может успокоить и расположить к вам членов команды. Кажется, что вам пока дают лишь неважную мелочёвку для расширения кругозора? Замечайте места в проектах, где вам интересно было бы покопаться, и приносите пользу там. Разобравшись в очередном кусочке логики, документируйте его или делайте более очевидным. За это вся команда только скажет вам «спасибо», и процесс интеграции пройдёт гораздо приятнее.
Надеюсь, вам было интересно читать мои мысли. Понимаю, что приведённые советы ситуативны и воспользоваться ими можно не всегда, однако все они родились из практического применения адаптации новичков и собственного перехода на новое место. Больше всего мне хочется, чтобы вы запомнили, что смена работы — это большое испытание для человека с любым опытом, сталкиваться при этом с трудностями абсолютно нормально, а попытаться помочь своему новому коллеге — отличная идея.
Комментарии (15)
DmitryKoterov
09.09.2022 13:30+14Документация - это совсем не то, что люди обычно подразумевают. Не что-то такое, что новые люди приходят и начинают читать. Потому что а) не начинают (даже если что-то есть), и б) ее нет (потому и нет, что нет аудитории, невостребовано).
Здоровая документация (а не для галочки, и не для того, чтобы с умным видом задавать вопрос «а документация у вас есть? ах нет? ну тогда вы полное г-но, а я д’Артаньян») бывает только одного типа, и образуется она всегда одинаково. А именно:
Сначала ничего нет.
Потом приходит человек, который ХОЧЕТ что-то делать (желание тут - ключевое; симбурде не прокатит) и спрашивает. Вы отвечаете.
Он снова приходит. И спрашивает. И спрашивает. Вы снова отвечаете.
Потом приходят еще 3-4 человека и спрашивают ровно то же самое.
И вот в этот момент рождается ДОКУМЕНТАЦИЯ. Как ваша реакция на однотипные вопросы.
Теперь, когда приходит человек с тем же вопросом, вместо того чтобы ему новое сообщение строчить, вы даете ссылку на уже готовый ответ в документации.
Люди продолжают приходить и задавать новые вопросы, так что документация обрастает все новыми деталями и полируется, эволюционно.
То есть для рождения документации (а не «документации») должны встретится две необходимости: реальное желание внешних людей что-то делать и продвигаться вперед, и лень автора документации отвечать на одинаковые вопросы. Уберите хотя бы один компонент - и будет «документация», а не Документация.
netch80
11.09.2022 11:44Это если автор документа не способен посмотреть со стороны и оценить то, что он написал. Да, таких, может быть, 90%, но не все.
Можно также перечитывать раз в несколько месяцев написанное самим собой и оценивать, что уже стёрлось из памяти и что надо написать явно.
Но в целом я согласен с тем, что без реакции на обратную связь документация обычно крайне слаба.
Mike-M
09.09.2022 18:12Поставил плюсы не только за контент, но и за почти безупречную грамотность.
Отдельное спасибо за «daily» вместо «дэйли» ;-)
DX28
11.09.2022 07:57Как часто вам приходилось слышать фразу «код — это лучшая документация»
Как трудно переубедить в обратном коллег и руководство пока только начинаешь работать в компании. И только по прошествии полугода, при карьерном росте или заматерелости в проекте начинает удаваться что проталкивать. Ну хотя бы doc string в начале функции. А на уровне лида приходится доказывать необходимость документирования уже разговаривая с CTO.
dkuzminov
11.09.2022 10:43+1Поправка: хороший код -- это документация. Плохой код -- это расписка в профнепригодности, что тоже можно считать документом.
milkground
11.09.2022 13:14Поправка: хороший код -- это документация.
Хороший и простой код может сам себя объяснять. А бывает код хороший и в то же время сложный, когда возникают вопросы "Почему?" и "Зачем?". Если документации нет, спросить у кого-то невозможно, то придётся самому искать ответы. А это время.
dkuzminov
11.09.2022 10:40Лучшая документация -- это история коммитов. Вернее, так должно быть. По факту большинство игнорирует этот мощный инструмент передачи знаний. А зачастую убогая история изменений свидетельствует о том, что и передавать-то нечего...
netch80
11.09.2022 11:53> Лучшая документация — это история коммитов. Вернее, так должно быть.
Нет.
Потому что история коммитов — это диахроническое состояние, о том, как развивалось что-то в процессе. А документация конкретной версии — это синхроническое, о конкретном состоянии.
Разница хотя бы в том, что, например, 200 опций конфигурации и их особенности в текущий момент — документация описывает индексируемым списком, по иерархии и/или по алфавиту, а история коммитов не просто будет содержать их в произвольном порядке, но и с кучей ненужного сейчас типа «опция --moo-list была --moo до 2.2, потом до 2.5 содержала 2 параметра, а теперь один — имя ключа для выбора», и с тяжёлым поиском нужного, когда что-то меняется на 5-м уровне индиректности.
Всё-таки с синхронным профилем на порядки легче:)
garbagecollected
Я полюбил процесс мытья посуды, будучи еще студентом, когда купил посудомойку. Это, кстати, была вторая большая покупка на вырученные с курсовых проектов однокурсников средства, сразу после покупки ноутбука.
Mopckou
Я вот в детстве ненавидел мыть посуду, а сейчас это стал какой-то медитативный процесс - даже расслабляет..
Markscheider
У меня такая же фигня - с глажкой "плоского" белья (полотенца, простыни/пододеяльники и пр.). А если на фон еще регги включить... :)
tuxi
Такая же фихня.
Причем иногда ответы на нерешаемые вопросы сами приходят в голову в процессе наведения порядка в посуде и кастрюлях.
Шайтан терапия.
TyVik
Присоединюсь! Жена как-то раз дала попробовать поставить посуду, и я подсел.
Под мытьё посуды ещё хорошо заходят подкасты.
semmaxim
Ага. Аудиокнига и спящие жена и дети...
i_andreev
Я так диссертацию написал - пока мыл посуду, обдумывал текст, а потом шёл записывать)