Слышу это регулярно и каждый раз 🤦‍♀️🤦‍♀️🤦‍♀️. Да вы в лучшем случае успели выдать ноутбук и доступы, и то не всегда даже это успели. А до состояния “человек самостоятельно берёт задачу и не блокирует команду” — там совсем другие цифры.

Бенчмарки APQC по всем профессиям: медиана выхода на базовую продуктивность — 35 дней. У худших компаний — 50+. И это про базовую, а не про полную.

Для разработчиков сроки длиннее. Так GitLab в открытом гайде по онбордингу даёт три фазы: обучение и адаптация — 3-6 месяцев, создание ценности — 6-12 месяцев, полная экспертиза в роли — до 18 месяцев. И это нормальная картина для крупных engineering-команд.

У Lally с коллегами *(European Journal of Social Psychology, 2010)* есть классическое исследование привычек. Медиана достижения автоматизма любого нового действия — 66 дней. Разброс от 18 до 254 дней в зависимости от человека и сложности действия. И это не лень или отсутствие мотивации, а устройство нашего мозга.

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

— почему вот это решение принято именно так — кто из коллег за что отвечает по-настоящему, а не по должности — какие задачи можно брать, а какие — пока нет

И вот этот настоящий онбординг идёт месяцами. У меня в практике senior’ы выходили на полную мощность к четвёртому-пятому месяцу, потому что в систему нужно врасти.

Что с этим делать. Не сокращать срок — это не получится, нужно честно его признать. В планировании ресурсов — заложить, что новый человек первые два месяца это полу-юнит. В ожиданиях команды — что новичок будет задавать вопросы и это нормально. В метриках тимлида — что найм одного человека не равно “+1 к мощности команды прямо сейчас”.

Признать долгий онбординг — это уважение к реальности.

—

Это первый пост в серии *“Мои любимые мифы про разработку”*. Дальше разберу ещё четыре:

— Документация необязательна, нормальная команда и так разберётся. — Больше людей в проекте — быстрее результат. — Senior-разработчик готов стать team lead. — Code review — это про качество кода.

Каждый из этих мифов дорого обходится команде.

Сколько по факту занимает онбординг до состояния “самостоятельно тянет задачу средней сложности” в ваших командах? Совпадает с цифрами из исследований или нет?

#лебедева_ит #лебедева_команды #лебедева_найм