Онбординг как дедовщина: а вы называете это Agile
Если ваш онбординг похож на ритуал посвящения в тайное общество, возможно, вы путаете Agile с дедовщиной.
Знакомая картина: вы приходите в новую команду, а вас встречают стеной Jira-тикетов, документацией из 2016 года и коллегой, который бормочет что-то про «спринты». Звучит как очередной день в Agile-царстве? Автор статьи на dhung.dev считает, что такой онбординг — не что иное, как хейзинг, только в корпоративной обертке.
Почему это больно?
Разработчики — народ терпеливый, но даже у нас есть пределы. Когда вместо внятного введения в проект тебя кидают в пул реквестов без контекста, это напоминает игру в сапера с завязанными глазами. А если при этом еще и требуют «быстро влиться в процесс» — поздравляю, вы участник ритуала посвящения, где вместо костра — daily stand-up.
Чем это отличается от нормального Agile?
Agile подразумевает итеративность и адаптацию. Но когда онбординг — это разовая пытка длиной в неделю, это уже не Agile, а legacy-код процесса. Хороший онбординг должен быть как CI/CD: автоматизированным, прозрачным и с возможностью отката. А не как релиз в пятницу вечером — страшно и непредсказуемо.
Что делать?
- Документируйте процесс. Не заставляйте новичка собирать пазл из разрозненных заметок.
- Назначайте ментора. Не просто «посмотри вон туда», а человека, который ответит на вопросы даже в 2 часа ночи (шутка, но почти).
- Устраивайте ретроспективу онбординга. Спросите новичка через месяц: «Что было больно?» — и исправьте.
Комментарий студии METABYTE: Мы тоже проходили через онбординг-квесты, поэтому в своих проектах закладываем понятную документацию и плавный вход. Без ритуалов с бубном, но с чувством юмора.