Привет! Я Евгений Антонов, ведущий технический менеджер проектов в Yandex Infrastructure. В ИТ‑индустрии за 17 лет успел поадминистрировать, поразрабатывать и поруководить. Работал на многих позициях в разных компаниях — аутсорсных и продуктовых.
Я был тем, кого онбордят, кто онбордит, кто придумывает, как онбордить, и несёт ответственность за производительность команд и онбординга в том числе.
Я пообщался по этой теме с десятками людей из десятков разных компаний, изучил их опыт и смог увидеть похожие боли. В этой статье я хочу поделиться основными трудностями онбординга, которые заметил, и предложить своё решение.
![](https://habrastorage.org/getpro/habr/upload_files/9d4/7b4/072/9d47b407212be23a70a5d53beb42c24e.png)
Компании разные, проблемы одинаковые
Вообще, в онбординге часто распространены одни и те же проблемы. Многие коллеги по индустрии сталкивались с ситуацией, когда онбординга в компании совсем нет или он минимальный: руководитель просто отдаёт ноутбук с преднастроенным ПО, а дальше делай что хочешь.
Я знаю типичные истории из крупных и скрипучих энтерпрайзов: человек устроился на работу и несколько недель просто ждёт, когда ему наконец дадут доступы. Такое ожидание может длиться 1–2 месяца. Программист спит, а оклад идёт.
Или встречал совсем гротескный пример: руководитель забыл, что к нему выходит новый сотрудник. Никого не предупредил, место не подготовил, рабочий компьютер не запросил, пропуск не сделал и уехал в отпуск. Человек пришёл, а его охранник не пускает в офис.
В итоге человек сидел в коридоре перед дверьми офиса на диване и два дня работал с личного ноутбука. Хорошо, что не с телефона.
Почему я сразу начал с таких примеров? Прежде чем рассказывать, как делать хороший онбординг, было бы неплохо подсветить последствия проблем с плохим.
Первая проблема — репутационные риски. Думаю, многие читали статьи на Хабре или VC, где разгневанные, униженные, оскорблённые разработчики, менеджеры или другие сотрудники изливают свой гнев и рассказывают, как ими не занимались, как им ничего не объяснили, не показали, не дали. В нашем маленьком, уютном мире IT такие неприятные слухи быстро расходятся из уст в уста, и в дальнейшем будет сложно «отмываться» и нанимать новых людей в команду, так как испортится HR‑бренд.
Вторая проблема — дезорганизация и неэффективность. Менеджеры и тимлиды тратят на онбординг много времени. При этом новые сотрудники очень долго выходят на нужную производительность.
В результате мы имеем ценных специалистов, которые могли приносить профит по другим задачам, занятых плохим и долгим онбордингом новых людей, которые начнут приносить пользу неизвестно когда. В этой тягучей схеме оказываются малопродуктивны все участники.Третья проблема — морально‑мотивационная. Люди в растерянности — поменяли работу, пришли на новое место, хотят понять, что и как делать, с кем общаться, как сделать так, чтобы ими были довольны, чтобы они успешно прошли испытательный срок. К сожалению, они не всегда получают это понимание и понятные ответы от руководства.
Так что ответ на вопрос «Кому выгоден хороший онбординг?», на мой взгляд, очевиден — он выгоден всем. В первую очередь — работодателю. Чем лучше будет онбординг, тем быстрее люди начнут приносить пользу, меньше будет бестолковых трат времени и денег, а шанс построить долгосрочные трудовые отношения с человеком вырастет.
К сожалению, работодатели не всегда это хорошо понимают. Поэтому надеюсь, что кто‑то из людей, принимающих решения, прочитает это и подумает ещё раз, насколько ему важно вкладываться в онбординг.
Общий и локальный онбординг
Я считаю, что онбординг можно разделить на две логические категории: общий онбординг на уровне компании и локальный онбординг на уровне команды.
Причём сам формат онбординга может быть разный: где‑то это набор документов, которые нужно прочитать онлайн, где‑то офлайн‑занятия, когда сотрудник в аудитории сидит, а лектор рассказывает про компанию и работу в целом. Или это могут быть подготовленные заранее курсы, где в конце нужно проходить какие‑нибудь квизы. Бывает и так, что нового сотрудника по компании за руку водит тимлид и в живом режиме один на один рассказывает.
Но суть предлагаемого мной процесса от этого никак не меняется.
![В эту сторону тоже важно не переборщить. Но всегда лучше, когда ответ на вопрос есть. В эту сторону тоже важно не переборщить. Но всегда лучше, когда ответ на вопрос есть.](https://habrastorage.org/getpro/habr/upload_files/c0a/f76/8a0/c0af768a06025327e1c469bc2a6c0411.png)
Общий онбординг — вовлечение в дела компании. Обычно за это отвечает HR‑отдел, а если компания небольшая, то специалисты по кадровому документообороту, делопроизводители или другие люди, которые ориентируются во внутренних документах и готовы рассказать новичку, когда и как выдают зарплату, как оформить ДМС, как написать заявление на командировку, как использовать корпоративное такси, оформить отгул и т. д.
В этой же части онбординга должна быть описана организационная структура компании: кто в каком отделе работает, какой отдел за что отвечает. Там, где процессы проще и держатся на конкретных людях, а не подразделениях, бывает что‑то типа карты коммуникаций, где расписано: командировки — это вот этот человек, доступы — это вот этот человек, вот этот отдел и т. д.
В каких‑то компаниях есть целые корпоративные порталы с подобной информацией, а где‑то всё оформлено в вики‑подобные странички или хотя бы в одну большую объясняющую портянку текста.
Чтобы новичок попал во все эти нужные документы, существует самый простой вариант такого общего онбординга — обычное приветственное welcome‑письмо.
Наверное, многие с этим сталкивались — при трудоустройстве в компанию вам приходит письмо, в котором написано: «Здравствуй, дорогой Вася / Петя / Маша! Ты у нас работаешь, мы все тебе рады. Хочешь узнать про отпуск — сходи по этой ссылке, вот документация; хочешь узнать про ДМС — сходи по этой ссылке, вот документация».
Я такие письма получал и очень им радовался. Они действительно помогали, и я надолго погружался в эту документацию. У меня всегда очень много вопросов, как мне в дальнейшем жить и работать в компании, мне всегда это было интересно. И я искренне благодарен тем людям, которые такие письма составляют.
Вы справедливо можете спросить: а что, если таких документов нет? Тут две новости — плохая и хорошая. Плохая новость в том, что у вас проблема на уровне компании. Если даже такой общей документации нет, значит, вы передаёте её из уст в уста. При этом где‑то что‑то забываете, где‑то что‑то теряете и где‑то, наверное, что‑то не очень актуальное сообщаете. А ещё тратите на это время и создаёте о себе впечатление не очень организованных товарищей.
Хорошая новость — это можно исправить и написать эту документацию. В самом небольшом и простом формате подготовить её — не такая уж большая проблема. Я это точно знаю на своём опыте: пару раз помогал такое делать в небольших компаниях размером до 50 человек.
В общем, если у вас этой документации нет, не поленитесь и напишите. Тогда и онбординг настроите, и доброе дело всей компании сделаете, потому что без этого никак.
Локальный онбординг. Можно сказать, что это дело тимлида конкретной команды. Не обязательно, что онбордить будет лично он, но именно он должен построить эту систему, придумать, как именно онбордить.
К сожалению, я видел случаи, когда в разных командах и разных компаниях это пытались переложить на HR-отдел. В итоге бедные HR страдали: они же не знают специфики работы именно в этой команде. Как они могут заонбордить в команду? И команда тоже страдала, потому что при плохом онбординге трудно влиться в коллектив и рабочие процессы. Поэтому призываю понять и принять, что здесь нужен тимлид, это его задача.
Локальный онбординг тоже хочу разделить на две части. Первая — официальная часть, где вы погружаете человека в процессы, которые у вас есть в команде: все Scrum-Agile, митапы и ретро-груминги, как у вас делается код-ревью и делается ли вообще, какие у вас код-стайлы и средства для коммуникации, какие доступы, проекты и архитектура в проектах, какие бизнес-процессы в этих проектах заложены, кто с кем как общается из смежников. Это всё, что нужно знать для выполнения работы.
Но работа — это одна часть, а погрузить человека в команду, в социум — это вторая часть, тоже очень важная. Здесь имеются в виду неформальные вещи. Например, если вы работаете в офисе, то все куда-то и когда-то ходите на обед. У вас есть список любимых мест для обеда? Вот, пожалуйста, покажите. Или есть какой-нибудь чатик, куда вы скидываете смешные мемы, — поделитесь, чтобы человек вливался. Может быть, есть какие-нибудь любопытные традиции в команде? Было бы неплохо нового человека туда погружать. Считаю, это помогает лучше социально адаптироваться.
Инструкции в онбординге: пишите сами, просите новичков
![Начать можно с самых простых чек-листов. Начать можно с самых простых чек-листов.](https://habrastorage.org/getpro/habr/upload_files/39d/68b/04a/39d68b04af48b13bf74c73b75f16ce91.png)
Как фиксировать инструкции. Роковая ошибка многих заключается в том, что они предпочитают не заморачиваться. Тимлиду говорят: «К тебе завтра / послезавтра / через неделю придёт новый сотрудник. Готовься». А он думает: «Зачем готовиться? Я и так всё знаю. Там приключение на 20 минут, зашли и вышли. Ничего не надо».
Но по факту всегда оказывается, что это не так. Всегда что‑то идёт не по плану, вы что‑то забудете, что‑то не готово или в середине процесса вас отвлекут, а вы потом не вспомните, что вы начинали человеку рассказывать. Или что‑то уже изменилось, а в ваших чертогах разума содержится старая и неактуальная информация. Призываю не надеяться на авось. Это не работает.
Как человек организованный, я считаю: самое простое, что тут можно сделать, — написать инструкцию о том, что человеку нужно сделать, чтобы войти в проект, в работу, в команду.
Первоначальное написание такой инструкции — это задача тимлидов. Но если мы годами в проекте — мы всё знаем, нам всё и так понятно, то мы думаем: «Зачем какие‑то мелочи описывать? И так всё ясно, две строчки только накидаем». Глаз тимлида замылен его опытом. У новичка нет такого контекста, он многое тут видит впервые.
Я рекомендую произвести мысленное упражнение:
Попробуйте напрячь фантазию и представить себя на месте человека, который пришёл в команду. Вот вы новичок: у вас нет никакого софта, вы не знаете, кто за что отвечает, какие ведутся проекты, как в команде общаются, у кого спросить доступы и что это за доступы, куда они нужны, какие сервисы делает команда, про какие смежные сервисы тоже нужно знать.
Представили? А теперь по горячим следам попробуйте написать какой‑то регламент, инструкцию: что нужно сделать этому новому человеку. Может быть, какой‑то софт поставить, где‑то зарегистрироваться, какие‑нибудь календарики завести, встречи в расписание добавить, заявки на доступы отправить, какую‑то доку по проекту прочитать.
Возможно, часть инструкции коснётся и вас как тимлида. Например, вы запрашиваете у кого‑то доступы, что‑то должны подготовить или пишете заявки, чтобы человеку выдали компьютер, создали электронный ящик и так далее. Всё это имеет смысл структурировать и более‑менее алгоритмизировать.
Я сам очень ценю, когда к моменту выхода нового человека у меня есть инструкция не только для него, но и для меня, как ответственного за онбординг. Не надо ничего вспоминать, а можно просто пройтись по чек‑листу и всё.
У такого подхода с инструкциями есть пара плюсов. Первый плюс — для очень эффективных или очень ленивых тимлидов: когда у вас есть инструкции и алгоритм, онбординг можно делегировать. Вы можете научить кого‑то из своей команды, и этот человек сам сможет онбордить новичков. А вы освободитесь для каких‑то других своих дел. В паре‑тройке команд я такое внедрял, чтобы разгрузить тимлидов и подрастить саму команду. Очень хорошо этим способом получалось научить людей онбордить новых коллег.
Второй плюс инструкции в том, что её всегда можно перечитать. Для меня это очень важное качество: когда мне что‑то важное долго рассказывают, то уже к концу рассказа я где‑то половину забываю, если не записывал. А если я хочу постфактум что‑то записать спустя определённое время, то от этой половины ещё половину забываю.
В итоге при устном рассказе можно записать только четверть, а заводить всю эту шарманку заново немного неудобно. А вот была бы у меня инструкция, я бы её перечитал. Сегодня, завтра, через неделю перечитал и всегда всё помнил и знал.
Как поддерживать актуальность. Вы справедливо можете заметить, что инструкция всегда устаревает. Это так, любая документация устаревает и может приходить в какое‑то неактуальное состояние. Как это можно решить?
Собирайте обратную связь при онбординге новичка по вашей инструкции. Пусть он скажет, где было непонятно, что неактуально, чего не хватило или неправильно написали. Ведь новичок — это представитель целевой группы. Он единственный, кто может понять, хорошо эта инструкция написана или нет. Она создана для него и таких, как он. Поэтому обязательно запросите обратную связь.
Попросите того, кто онбордился, самостоятельно актуализировать и дописать эту инструкцию. Потому что он напишет её понятными словами, которые нужны для него и других таких же новичков.
Пусть инструкция, которую написал тимлид изначально, окажется в чём‑то устаревшей, неактуальной. Но с каждым заонбордившимся сотрудником она будет актуализироваться. Больших усилий для этого не потребуется, достаточно научить новых людей вовремя идти и актуализировать эту инструкцию, а если потребуется — пинговать вас.
Ожидания и дорожные карты
![](https://habrastorage.org/getpro/habr/upload_files/755/3a6/616/7553a661645acdc9dd48b7c4622da88b.png)
Отдельная боль и отдельная тема, на которой хотел бы остановиться, — это ожидания от работника. К сожалению, некоторые работодатели сами не очень понимают, чего хотят получить от человека. «В компании медленно релизится продукт — давайте наймём трёх разработчиков, закинем их в команду». А почему 3? А почему не 1 или не 5? А что они будут делать вместе? Что будет делать каждый из них? Как потом разбираться, прошёл ли каждый из нанятых испытательный срок? Непонятно.
Работодателю нужно понять, чего он хочет от работника, которого наняли: что конкретно он должен делать, чтобы было хорошо и ему, и компании. И важно сразу проговорить с человеком эти ожидания. Потому что иногда нового сотрудника словно бы выбрасывают в озеро из лодки: куда хочешь, туда плыви. И вот человек плывёт и не знает, доплыл ли он, и вообще, в ту ли сторону плыл?
Ещё пример. Один мой товарищ как‑то устроился в компанию, ему сообщили, чего от него ждут. При этом что‑то не подрасчитали, ожидания оказались огромными, и в первый месяц он выдал аж 250 рабочих часов. К концу этого месяца он не то что в этой компании работать не хотел, он уже в целом работать не хотел. Хотел в отпуск, говорил: «Всё, хватит, мне надоело».
Когда месяц прошёл, начали ревьюить то, что он сделал за эти 250 часов, и говорят: всё классно, задача замечательно сделана, но мы ещё в середине месяца передумали. Поэтому это всё не нужно, всё удаляй, и сейчас мы тебе новую задачу нарежем. Представляете, какое было разочарование у человека, который старался по ночам, по выходным, не спал, делал, а в итоге, оказывается, и не надо было? И люди про это знали раньше, но ему просто не сказали.
Поэтому когда вы будете проговаривать ожидания от работника, сразу сообщите ему, что мы не высекаем это в камне, это не какая‑то недвижимая вещь. Всякое бывает, и как только мы узнаем, что изменилось что‑то, — дадим знать. И ты, если понимаешь, что переоценил свои силы или мы что‑то недооценили, не успеваешь, не получается, — скажи! Мы это выслушаем, мы открыты к диалогу, к разговору.
И не забывайте, пожалуйста, про промежуточный контроль. Хоть иногда приходите, заглядывайте, спрашивайте, как дела, какие сложности, чем помочь, где непонятно, что объяснить. Это не занимает много времени и сил. Просто спросить, посмотреть, а действительно ли в нужном направлении человек идёт. Нередко новички (даже опытные сениорные ребята) стесняются лишний раз спросить и попросить помощи. Поэтому могут зависнуть где‑то на дни, в то время как с вашей помощью справились бы за считанные часы или минуты.
Офбординг
Существует такое понятие, как «офбординг». Кто‑то использует его как синоним для слова «увольнение», но я же хочу его употребить в контексте того, как можно построить последние недели работы с уходящим сотрудником.
В одной из компаний, где я работал, была моя коллега, которой пора было уходить в декретный отпуск. Она обладала специфичным знанием и занималась определёнными задачами одна в команде. Мы попросили её в последние недели перед уходом не делать рядовые задачи и не тратить драгоценное время, а написать инструкцию вроде той, о которой я рассказал чуть раньше. Она описала свои проекты и задачи, как и с кем взаимодействовать, что делать, если что‑то пойдёт не так. Оставила эту инструкцию и ушла спокойно в отпуск.
Мы наняли ей замену уже после того, как она ушла. Человек, пришедший на место, быстро и хорошо заонбордился. Примерно 80% своих задач и вопросов он закрыл этой инструкцией.
В остальных 20% ему помогли мы. Научили, вместе разобрались и попросили: «Теперь ты всё знаешь. Пожалуйста, дополни инструкцию, актуализируй её. Разберись и хорошими, понятными словами напиши». Он это сделал. Спустя 2–3 месяца мы наняли ещё одну сотрудницу, и она тоже хорошо заонбордилась по этой обновлённой инструкции. Её мы также проинструктировали, что если что‑то меняется, всё можно актуализировать.
А спустя год вернулась коллега, которая изначально уходила в декрет. Она прошлась по этой дважды актуализированной инструкции и заонбордилась заново. Пока её не было, появились новые проекты, новые заказчики, новые механики работы, но у неё не возникло никаких вопросов. Она буквально за два‑три дня ворвалась в работу.
Ещё немного советов
Если у вашей команды есть время, и вы готовы уделить его онбордингу, покажите свою свеженаписанную инструкцию кому‑то из коллег. Вы пишете первую итерацию с замыленным глазом. Да, у вашего коллеги глаз тоже замылен, но если у вас замылен правый глаз сверху, а у коллеги — левый глаз снизу. Он точно заметит какие‑то неточности, недоработки вашей инструкции и поможет вам сделать её лучше.
Ещё один важный момент: нужно подобрать подходящие вводные задачи новому сотруднику. С этим часто бывают проблемы.
Бывает, что человек приходит, и все: «О, новый человек пришёл! Сейчас посадим его багфиксить эту штуку, которая постоянно залипает». И в итоге человек багфиксит три месяца, а проект так и не понял, не разобрался, не изучил. Даёшь ему другую задачу про какой‑нибудь модуль, который рядом, а он не знает, что это такое. Умеет только вот эту небольшую гайку точить.
А бывает наоборот. Например, никому не хочется делать сложный рефакторинг ядра, потому что с ним проблем не оберёшься. Пришёл новый человек, и все такие: «Сениор, значит, сейчас мы ему задачищу дадим». И он сидит месяц, два. И вряд ли из его посиделок выйдет что‑то хорошее, потому что на ядре многое завязано. Он половину модулей сломал, не знает, как тестить, не знает бизнес‑логику, все кейсы. И проверять за ним потом плохо. И в итоге человек месяц‑два сидит с одной задачей, никак не может разобраться. И думает о себе, что его уволят, если он одну задачку сделать не может. В уныние впадает.
Поэтому важно думать над подходящими вводными задачами, чтобы человек начинал проект с разных мест понимать, входить в него и быстрее вовлекаться в продуктивную работу. Тогда его можно будет на какие‑то внезапно загоревшиеся задачи или в соседнюю команду пересадить. Да и сам новичок будет понимать, как проект устроен в комплексе.
И заключительный совет: как отслеживать прогресс онбординга.
Видел, как один человек из тимлидского комьюнити под каждого сотрудника формирует доску в Trello и на ней следит за прогрессом нового сотрудника.
Я делаю по‑рабоче‑крестьянски — тикетом с пошаговым чек‑листом, что где посмотреть, в какую доку сходить, что поставить, как настроить и т. д.
Один тикет — одна точка входа, куда и человек ходит за полезной информацией, и я смотрю, что уже сделано для погружения, а где есть проблемы.
Компании разные, онбординг одинаковый
Я пробовал применять этот простой подход к онбордингу в разных компаниях и командах.
Делал это в организациях на несколько десятков человек, на тысячу человек, на десятки тысяч человек. В командах, которые занимались продуктом, инфраструктурой для внутренних потребителей и аутсорсом для внешних.
Везде это всё работало одинаково неплохо. Неоднократно я получал хорошие отзывы и от самих проходящих онбординг, и от тех, кто онбордит.
Так что, попробовав разные вариации, я продолжаю быть уверенным, что эта схема — рабочая, и я её могу вам рекомендовать.
Итоги и TL;DR
Вот вы сейчас скажете: а тема‑то статьи «Система онбординга комфорт‑класса». В чём тут комфорт?
На мой взгляд, комфорт в том, чтобы простыми, понятными действиями сделать такую систему онбординга, где старшие специалисты тратят меньше времени на всё это дело, новые специалисты быстрее и эффективнее входят в рабочий процесс и не делают лишней работы, которая никому не нужна. Вследствие этого бизнес тратит меньше денег, и все довольны.
20% усилий, 80% результата. На мой взгляд, такой размен для большинства компаний вполне себе подходящий.
Итак, каким я вижу комфортный и эффективный онбординг:
Не забудьте про стандартное welcome‑письмо со ссылкой на документы‑регламенты — это общий онбординг.
Примите, что за локальный онбординг отвечает тимлид. То есть тимлид его готовит, а дальше решает: либо сам онбордит, либо делегирует и учит своих коллег.
Обязательно готовьте инструкции и для проходящего онбординг новичка, и для ответственного за онбординг: кому, что и как нужно делать.
Просите новичков, чтобы они эту инструкцию актуализировали. Если там что‑то неактуально или непонятно, то пусть пишут своими понятными словами.
Готовьте вводные задачи, чтобы человек эффективно входил в рабочий процесс.
Обозначьте ожидания, чтобы никто не выгорал, не делал бесцельную работу и не страдал потом от этого.
Контролируйте процесс и прогресс онбординга. Не бросайте человека одного.
По моему мнению, с таким подходом онбординг точно станет комфортнее.
P. S. Если вам было интересно или полезно прочесть эту статью, то подписывайтесь на телеграм‑канал «Тимлид Очевидность», где пишу похожее про менеджмент, тимлидство и рабочие процессы.
А если вы любите подкасты (как люблю я), то есть ещё 2 подкаста, где я являюсь соавтором и соведущим.
«Кода кода» — и про технологии, и про менеджмент, и про вещи, которые в бытовой жизни интересны и применимы.
«Три тимлида заходят в бар» — строго про менеджмент и реальные истории из жизни руководителей разных уровней.
Комментарии (12)
Elpi
16.08.2024 08:10+2На мой взгляд, вы неточно выстраиваете логику процесса. Она у вас нормативная с некоторым уклоном в академичность. Вроде как вы некий курс излагаете.
Оно бы ладно, но приоритеты неверные. Вы встаньте на точку зрения новичка, влезте в его шкуру.
Для чего меня взяли? чтобы я давал реальный вклад, отдачу, денег работодателю зарабатывал. Поскольку мотивация у меня максимальная (первые дни на новом месте), то все, что мне нужно: а) понять требования на новом месте; б) получить доступ к требуемым для решения первых задач инструментам и данным (включая уже наработанный объем, причем уже в традиции этой конторы).
Важнейший момент - это предъявить требования. Не ожидания, не пожелания - а требования. Если этот момент упустить, то чел быстро адаптируется и начинает воспринимать текущий бардак исторически сложившимся. А предъявы начальника как самодурство и каприз недалекого человека.
Он реально недалекий, потому что нужно было четко и в меру жестко очертить, сформулировать требования к работе (не внутреннему распорядку, не куда к кому обращаться). Что новый сотрудник должен делать и как.
Ведь суть в том, что перво-наперво он хочет зарекомендовать себя и начать генерить прибыль. Если это происходит, то наступает черед общих деталей и подробностей. Квазифилософские фирменные доки типа видения своей миссии, штатного расписания.
На первом этапе они не нужны вовсе. Создайте условия (оборудование, доступы, стайл-гайды, где и что лежит) чтобы работник начал приносить пользу. Это важно для него, для его самощущения.
Как вы правильно сказали, общую информацию можно и нужно предоставлять в виде комплекта доков. В частности, полезно штатное расписание. Только в одной компании я видел на страницах сотрудников в локальной сети сведения о том, руководитель над ним и кто под ним. Но, повторюсь, это мелочи.
Теперь о двух психологических моментах.
Английский ученый Резерфорд считал, что если аспирант второй раз подходит к нему с вопросом "что делать дальше?" - это это негодный аспирант. Затем опытный работник понимает, что он должен пользу приносить, а не отвлекать занятого начальника дурацкими вопросами. Каждый такой "подход" - это "минус" к карме. И шанс не закончить испытательный срок. А вы пишите, что он должен спрашивать...
Второй момент - это отношение аборигенов к новичку. Очень любят везде бросить его в воду и с неприязненным интересом наблюдать, утонет, обделается ли? При этом умом-то все понимают, что и в их интересах помочь ему быстро включиться в эффективную работу. Но одно дело ум - а другое "чуйства". В итоге, из моего опыта, начальница упомянула о том, где что лежит из уже наработанного в форме критики, мол "не знаешь ничего". Вместо того, чтобы сразу об этом рассказать.
*
Резюмирую. Исходно, обязательно необходимоо а) предъявить разумные и внятно изложенные требования и добиваться из соблюдения; б) создать "пятачок возможностей" для начала продуктивной деятельности. Не нудно излагать все обо всем - а дать возможность новичку зацепиться, начать приносить пользу. А уже на основе зарождающегося удовлетворения от продуктивной деятельности на новом месте расширять "включенность" работника в различные "подсистемы" фирмы. Ну и о роли личности в
исторонбординге желательно помнить.e-antonov Автор
16.08.2024 08:10+3Спасибо за развернутый отзыв, замечания и предложения!
Немного прокомментирую некоторые вещи.
Я и согласен, и не согласен в том, что пришедший сотрудник заботится о том, чтобы начать генерить прибыль и показать, что он окупается. Согласен в плане того, что по сути-то от сотрудника бизнес такого и ждет. А не согласен в плане того, что это не так часто встречающий паттерн мышления. Часто встречается более простой вариант: «Мне надо делать задачи на испытательном сроке хорошо, чтобы мной были довольны и оставили дальше работать». Поэтому я как раз и предлагаю сразу оговаривать и стартовые задачи, и сроки, и не просто высекать в камне со словами «мы тут тебе придумали и оценили, игра началась», а допускать возможность аргументированного уточнения.
В абзаце про психологические моменты приведены примеры, которые заставляют меня недоумевать. Я бы точно в таких условиях работать не хотел и с руководителем, который так действует. Ну и самому быть таким не хочется. Тут я не понял, что именно вы предлагаете. То ли явно знать о такой проблеме и приложить усилия, чтобы их избежать, то ли что-то другое.
В блоке резюме: а) я оговорил, вы не согласились с формулировкой, но в целом мы про одно и то же; б) «пятачок возможностей» — в моём варианте это базовая инструкция, как настроиться, где что лежит, как что работает + хорошие стартовые задачи разумной сложности и полезности, чтобы человек и погружался плавно, и видел пользу от своей работы.
Мне кажется, мы с вами довольно похоже мыслим. Возможно, вам показалось, что присутствует некая академичность или изложение курса потому, что статья скрафчена из сорокаминутного доклада, который должен быть в целом структурно раскрыть проблематику и предлагаемое решение онбординга.
dyadyaSerezha
16.08.2024 08:10Все автор верно изложил, и про всякие туманные миссии ни разу не упомянул. А таких "чувствительных" работников, особенно начальников, надо гнать в шею.
voldemar_d
16.08.2024 08:10+1Английский ученый Резерфорд считал, что если аспирант второй раз подходит к нему с вопросом "что делать дальше?" - это это негодный аспирант. Затем опытный работник понимает, что он должен пользу приносить, а не отвлекать занятого начальника дурацкими вопросами. Каждый такой "подход" - это "минус" к карме. И шанс не закончить испытательный срок. А вы пишите, что он должен спрашивать...
Английские (и прочие британские) учёные - вовсе не факт, что хорошие IT-руководители. И вообще в бизнесе.
Имхо, если за "дурацкие" вопросы по работе "минусят карму" вместо того, чтобы ответами на вопросы повышать эффективность работника - бежать надо из такой конторы.
Elpi
16.08.2024 08:10В первом абзаце я говорю о трудовой этике. На своем примере. Я довольно много ездил как visiting scientist. Это всего 3 месяца в чужой лабе. Нет времени на раскачку, а деньги идут. И ты либо даешь результат, либо больше не пригласят. Нмв, это ессно. но за других не скажу. Ваш вариант выглядит инфантильным каким-то.
*
Про пятачок вы снова в преподавательской манере излагаете: шаг 1, шаг 2 и пр. И только потом допустить до реальной (хотя вы говорите об учебной облегченной спецом подобранной) задачи. А я сижу и думаю, что мне делают большой аванс, хотя я еще ничего не делал. И инфа эта мне пока не нужна. Помните как в "Операции Ы" Пуговкин трындел о том, как космические корабли бороздят просторы космоса"? вот я про это.
Я же о приоритетах в процессе адаптации нового коллеги! Ему надо дать возможность начать продуктивно работать по основной специальности. Прежде всего, чтобы снять вопросы психологии. Он ощущает свою востребованность, снимает сомнения в своих возможностях, начинает обретать уважение новых коллег и пр.
*
Можно еще уточнить, что общую часть делает кадровик. А вводит в тему и в работу обычно РП. Которые обычно сами имеют опыт такой работы и все знают. Вот они и должны давать "вводную" с целью запустить эффективный процесс.
*
Про психологию плохих руководителей я ничего не предлагаю. Бежать надо как можно быстрее. Хотя меня и удивляет ваше недоумение. Я не придумываю, наоборот у меня никогда не было. Был один пофигист - и он оказался лучшим руководителем. Мозги не пачкал, доводил абсолютно необходимый ему минимум, причем с толковыми пояснениями.
Короче, ваши слова сильно расходятся с моим жизненным опытом. Причем доверяю я опыту.
*
По форме я уже подчеркнул - начинать надо с главного. Брать быка за рога. А уже потом рюшечки и цветочки... Именно в этом суть упрека в академичности.
Когда я учился на командира взвода гаубиц, нам поясняли простую вещь. По правилам надо проводить полную подготовку к открытию огня. Получить данные с метеозонда там, с артиллерийского радара и пр. красоты. Но когда на марше на тебя из-за поворота лесной дороги выезжает взвод вражеских танков - то уже как-то резко не до этого.
*
И мне крайне не понравилось и не нравится слово "онбординг". Не по-русски. Поэтому я хочу напомнить вам старый советский анекдот.
Приходить бригадир Вася на ферму к доярке Дуне. Дунька! к нам корреспондент из области едет. Какой то онбординг делать будет (в оригинале "брать интервью"). Ой, Васька, а чой-то?? Да я ХЗ, Дунь. Но ты подмойся на всякий случай.
dyadyaSerezha
16.08.2024 08:10+1Какой процент из читаюих эту статью - visiting scientists? Думаю, меньше 1%. Ну, в общем, это всё.
voldemar_d
16.08.2024 08:10Научная среда и IT - это всё-таки совсем не одно и то же.
Онбординг, soft skills и много чего ещё - устоявшиеся термины.
dyadyaSerezha
16.08.2024 08:10+1человек устроился на работу и несколько недель просто ждёт, когда ему наконец дадут доступы. Такое ожидание может длиться 1–2 месяца. Программист спит, а оклад идёт.
Это прекрасный пример очень комфортного онбординга. Побольше бы таких.
voldemar_d
16.08.2024 08:10Читал про другой случай - когда на новом месте работы оказалось, что всю работу за день удаётся сделать за 2 часа. А когда новый работник подошёл к старому, чтобы спросить, что ему делать дальше, он ему сказал: тебе что, больше всех надо? Растягивай эту работу на весь день, куда тебе торопиться?
montenegro333
Шикарная статья