Всем привет! Продолжаю рассказывать об опыте управления в IT. Сегодня поговорим о вводе нового сотрудника в команду. Вы взяли инженера в штат. Когда он станет полноценной боевой единицей? Что делать, чтобы ускорить его адаптацию? Как оптимизировать этот процесс? В конце концов, стоит ли вообще уделять этому внимание и тратить время?
Начну с ответа на последний вопрос: однозначно да. Каким бы опытным ни был специалист, ему требуется время, чтобы вникнуть в технические тонкости конкретного проекта, ознакомиться с процессом разработки, наконец, познакомиться с новыми коллегами. Это действительно важно для компании: чем быстрее он начнёт в полной мере решать задачи, тем быстрее он начнёт приносить пользу компании.
Я считаю, что ввод нового сотрудника в команду крайне важный процесс, и чем он более отлажен, тем быстрее новичок становится полноценным сотрудником и тем меньше времени вы на это тратите.
Когда я работал в сервисе-агрегаторе б/у запчастей, ввод новых людей в команду занимал 3 дня. После этого они с остальными на равных решали текущие задачи, участвовали в обсуждениях и шутили с коллегами у кофейного аппарата. Но я к этому пришёл, конечно, не сразу, сначала пришлось набить шишки и получить опыт. Только потом я сформировал для себя основные принципы и выстроил процесс.
Вот главные нюансы, которые я вынес для себя из практики управления командами.
В общем-то, никаких тайн я не открыл, но эти аспекты действительно имеют большое значение. Первое впечатление очень важно, именно с него у человека будет формироваться мнение о компании и о его месте в ней.
Ещё один крайне важный фактор — снижение уровня стресса. Он неизбежен, так как переход на новую работу — это выход из зоны комфорта, все люди разные, не все умеют хорошо справляться с этим. Ваша задача — максимально сгладить процесс вхождения человека в команду. И тут важно внимание к мелочам. Например, человек может постесняться попросить заменить неудобную клавиатуру. Или если видите, что он интроверт, будьте деликатнее и не выводите его под софиты в центр арены опенспейса при знакомстве с командой.
Человек пришёл к вам работать, вы его познакомили с коллегами и компанией в целом, создали комфортные условия. Пора приниматься за работу. Ведь ваша задача в том, чтобы он включился в процесс разработки и как можно быстрее начал приносить пользу компании. И в этой ситуации главное не перебрать со скоростью. Погружайте новоиспечённого коллегу в работу плавно.
Итак, ниже основные шаги, которые позволяют мне максимально быстро и безболезненно превратить новичка в полноценного члена команды.
Я опять не рассказал ничего нового, но почему-то в очень многих компаниях продолжают совершать такие ошибки. А потом удивляются, что человек с большим опытом делает досадные ляпы. Тут логично провести мою любимую аналогию со спортом: профессиональный игрок отлично умеет бить по мячу и ловко давать пас, но без знания тактики и стратегии команды от него не будет толка и результатов. Именно поэтому и нужен тренер, который поможет игроку стать частью команды. Если вы руководитель команды, то ввод новых людей команду должен лежать на вас. Нехватка времени и прочие причины, это всего лишь отговорки. Это действительно важный процесс, который за вас никто не наладит.
Ниже я поделюсь поучительными случаями из собственной практики. У меня тоже не сразу получилось отладить процесс, я к этому шёл через ошибки.
Когда моя команда была совсем маленькой, новым сотрудникам мы поднимали все сервисы с нуля на каждой машине. Конечно, я тратил на это кучу времени или отнимал его у коллег, когда просил их помочь. С ростом компании и IT-отдела это стало головной болью.
Признаюсь, я упустил этот момент. Кроме того, это вызывало проблемы не только с новичками. Когда кому-то из сотрудников надо было поднять сервис, который писала другая команда, они были готовы застрелиться. А если разом надо было поднять десяток? Я решил ситуацию кардинально: перевёл всю инфраструктуру на Docker. Да, было непросто, потратили немало времени и сил, но очень много этим сэкономили в будущем. Мы подобрали оптимальные конфигурации проектов и каждую снабдили подробными инструкциями о том, как разворачивать и поднимать.
В итоге все наши 15 внутренних сервисов разворачивались за 20–30 минут. То есть новички безболезненно перескакивали один из этапов адаптации на новом месте. Многие даже удивлялись, вспоминая свой прошлый опыт. Для меня это было лучшей похвалой. К слову, я знаю много компаний, в которых новичков бросали наедине с проектом, и им приходилось тратить целую неделю на поднятие!
Наверное, как и у всех, в начале проекта у нас совсем не было документации. И пока команда была небольшая, а сервис скромным по функционалу, в этом не было никаких проблем. Но через два года при переключении на другие части проекта разработчики уже сами не понимали, как работают те куски сервиса, которые они давно не трогали. Рассказывать новым сотрудникам о проекте было ещё сложнее. Тем более, когда он состоит из 15 сервисов, которые работают по-разному и на разных технологиях.
На первом этапе решения проблемы записали обучающие видео для всех сотрудников всех отделов. Программистам давали смотреть все, чтобы они понимали, как устроена работа сервисов с точки зрения пользователя. Это сильно экономило время, не надо было долго рассказывать, хватало 10 минут, чтобы ответить на вопросы после просмотра.
Затем мы подготовили документацию в двух версиях: для новичков и расширенную для всех остальных. Первая по сути была простой шпаргалкой для начального этапа ввода человека в команду, там новички могли находить всё самое важное. А второй, расширенной версией, уже пользовались все. Там было описано всё: от архитектуры и инструкций по разворачиванию проектов до тонких технических нюансов использования тех или иных технологий. Позже создали ещё один большой документ, который описывал взаимодействие всех компонентов нашей общей системы.
Можно сказать, поиска по большой доке сначала не было, пользоваться было крайне неудобно, поэтому всё перевели на Wiki-движок. При правильной организации, а это удалось тоже не с первой попытки, всё оказалось очень удобно и доступно. Позже мы ещё добавили дополнительные документы для разных отделов. И тогда наша документация стала полноценной базой знаний. Например, понадобилось настроить репликацию на каком-то из сервисов, находишь нужную статью с инструкциями и примерами.
Каждый сотрудник мог дописывать и редактировать документы, были ответственные, которые следили за актуальностью сведений, но в процесс так или иначе были вовлечены почти все. Здесь важно отметить ключевой момент — знания не должны замыкаться на одном человеке, это путь в никуда. Он может заболеть или уволиться, тогда в случае его отсутствия может случиться информационный коллапс.
Я уже давно ушёл из той компании, но база жива, ей постоянно пользуются сотрудники.
Когда-то я сам приходил на новую работу рядовым программистом, мне было приятно, когда старались создать комфортные условия и всё объясняли. Но было, когда просто сажали на рабочее место и оставляли один на один с проектом. Это жутко бесило. Но руководство не видело в этом проблемы.
Помня о своём опыте, я всегда стараюсь прислушиваться к людям и создавать комфортные условия. Например, было такое, что человеку не хватало хороших наушников с шумоподавлением или стула с поддержкой спины. В моей практике даже была история, когда программист пришёл на PHP, но в душе хотел заниматься JS. Я как раз переформировывал отдел, а у человека была отличная мотивация и горящие глаза. В итоге я перевёл его на другую позицию, все остались довольны.
Ребята, которые пришли в мой отдел, очень ценили такое отношение. Говорили, что у нас всё очень сложно устроено, но благодаря такому плавному вводу в курс дела и помощи других сотрудников они быстро осваивались в команде.
Я считаю, что во многом помогает хорошо отлаженная коммуникация и дружественная атмосфера в команде. Team Leader должен жить с командой, CTO с TL и процессами, наверное, только тогда будет идиллия.
Бывают такие досадные случаи, когда нового человека берут в компанию, но уже в процессе работы выясняется, что либо он не подходит для проекта, либо проект по каким-то причинам не подходит ему. Конечно, ситуация не рядовая, но иногда случается.
Чтобы минимизировать риски для обеих сторон, я ввёл такую практику, как тестовый день. Мы использовали такой подход, когда были сомнения. То есть специалист мог поработать день, чтобы попробовать на зуб новый для него проект, посмотреть, как всё устроено. Мы в свою очередь даже за такое короткое время могли комплексно оценить его.
У инженера может быть много причин, по которым проект ему не нравится. Например, он может не захотеть работать с легаси, ему могут не понравиться подходы в разработке, наконец, ему может не подойти атмосфера в команде. И бывает, что человеку недостаточно этих причин, чтобы уйти после испытательного срока. Он остаётся, но испытывает дискомфорт или недовольство.
Чтобы исключить подобные ситуации, мы и проводили тестовые дни. Люди просто брали отгул и приходили к нам попробовать поработать. В этом случае времени для знакомства с проектом было ещё меньше, поэтому мы вводили их в курс дела по ускоренной программе. Это приносило свои плоды: в случае сомнений после собеседования мы вместе с кандидатом принимали правильное решение. Таким образом, он не рисковал потерять существующую работу и попасть в проект, который ему не нравится, а мы экономили много ресурсов в случае, если человек в итоге не становился членом команды. Кстати, подобный подход используют и некоторые другие компании.
В разных компаниях рабочие процессы сильно отличаются, также везде своя специфика и архитектура. Поэтому даже крутым специалистам требуется время на адаптацию. Ваша задача — сделать её наиболее эффективной и максимально сократить по времени. Поэтому стоит уделить время отладке такого процесса, как ввод нового сотрудника в команду. Если вы ещё не делали шагов в этом направлении, то старайтесь заняться этим как можно скорее. Это в будущем поможет вам сэкономить много времени. И неважно, сколько человек работает в компании, 10 или 1000. Ещё важно понимать, что если этим некому заниматься, то ответственность всё равно лежит на руководителе команды.
В моей команде удалось добиться сокращения времени ввода до трёх дней! Уже после такого короткого срока человек вливался в команду и брался за текущие задачи. Универсального рецепта нет, в каждой ситуации будет работать свой план. Но на мой взгляд, ключевые аспекты — это тщательная подготовка к набору новых сотрудников (документация, настройка окружения, аппаратное обеспечение), создание комфортных условий, грамотное знакомство с проектом и поддержка со стороны коллег и, конечно, руководителя команды.
P.S. А вдруг у вас есть интересные, забавные или поучительные истории о том, как вас вводили в команду? Жгите в комментах! :)
Мои другие статьи о менеджменте в IT:
Что такое быть Team Leader
Dream team из ничего: найм специалистов в IT
Как создавать успешные команды и управлять ими
Расти, Team Leader, большой и маленький
Начну с ответа на последний вопрос: однозначно да. Каким бы опытным ни был специалист, ему требуется время, чтобы вникнуть в технические тонкости конкретного проекта, ознакомиться с процессом разработки, наконец, познакомиться с новыми коллегами. Это действительно важно для компании: чем быстрее он начнёт в полной мере решать задачи, тем быстрее он начнёт приносить пользу компании.
Я считаю, что ввод нового сотрудника в команду крайне важный процесс, и чем он более отлажен, тем быстрее новичок становится полноценным сотрудником и тем меньше времени вы на это тратите.
Превращение из новичка в коллегу
Когда я работал в сервисе-агрегаторе б/у запчастей, ввод новых людей в команду занимал 3 дня. После этого они с остальными на равных решали текущие задачи, участвовали в обсуждениях и шутили с коллегами у кофейного аппарата. Но я к этому пришёл, конечно, не сразу, сначала пришлось набить шишки и получить опыт. Только потом я сформировал для себя основные принципы и выстроил процесс.
Вот главные нюансы, которые я вынес для себя из практики управления командами.
- Ввод человека в команду стоит начинать со знакомства с проектом. И это я делал уже на собеседовании. У меня всегда был наготове 10-минутный рассказ о компании в целом, на чём она зарабатывает, как устроен сервис, структуре отделов и прочем.
- Подготовка рабочего места и создание комфортных условий для работы. Человек должен в первый день сесть за свой стол с удобным стулом или креслом и включить уже настроенный компьютер. Не успели подготовить всё это? Ваш косяк, этому действительно надо уделять внимание.
- Индивидуальный подход. Например, для создания комфорта (а он необходим, особенно в условиях стресса при переходе на новое место работы). Неплохо поинтересоваться о предпочтениях в плане операционной системы и клавиатуры/мыши. Может вы будете первым работодателем, который такое предложит. А это поднимет вашу компанию в глазах сотрудника.
- Правильное знакомство с командой. Недостаточно просто представить по именам всех сотрудников и разойтись по рабочим местам. Можно сделать так: это Миша, он отвечает за бэкенд, это Петя, он DevOps, а Вася и Коля отвечают за клиентскую часть, им можно задавать вопросы по таким-то аспектам. И это всё должно быть отражено в служебной документации для сотрудников, но об этом ниже.
- Знакомство с компанией. Я считаю, что лучше всего провести его по отделам и рассказать, как устроена компания внутри, каким образом налажено взаимодействие между сотрудниками. В будущем это пригодится.
- Быт. Новый инженер должен обязательно знать такие банальные вещи, где находится уборная, как пользоваться кофемашиной и где можно разогреть еду. Отличный шаг в сторону сближения с коллегами — пригласить его на обед вместе с командой.
- Принципы работы команды. Везде свои правила и условия. Например, у нас в команде было принято работать по гибкому графику, любой мог приходить в удобные для него часы или отпроситься на день по делам или поработать из дома. Но в случае релиза или нештатных ситуаций мы задерживались и вместе решали проблему. Также в команде сложилась дружественная атмосфера, мы относились друг к другу с уважением, и ждали этого от новичков.
В общем-то, никаких тайн я не открыл, но эти аспекты действительно имеют большое значение. Первое впечатление очень важно, именно с него у человека будет формироваться мнение о компании и о его месте в ней.
Ещё один крайне важный фактор — снижение уровня стресса. Он неизбежен, так как переход на новую работу — это выход из зоны комфорта, все люди разные, не все умеют хорошо справляться с этим. Ваша задача — максимально сгладить процесс вхождения человека в команду. И тут важно внимание к мелочам. Например, человек может постесняться попросить заменить неудобную клавиатуру. Или если видите, что он интроверт, будьте деликатнее и не выводите его под софиты в центр арены опенспейса при знакомстве с командой.
Как быстро погрузить новичка в проект и не убить его
Человек пришёл к вам работать, вы его познакомили с коллегами и компанией в целом, создали комфортные условия. Пора приниматься за работу. Ведь ваша задача в том, чтобы он включился в процесс разработки и как можно быстрее начал приносить пользу компании. И в этой ситуации главное не перебрать со скоростью. Погружайте новоиспечённого коллегу в работу плавно.
Итак, ниже основные шаги, которые позволяют мне максимально быстро и безболезненно превратить новичка в полноценного члена команды.
- Рассказ о проекте. Я считаю, что сначала надо рассказывать о проекте с точки зрения клиентов. Для чего он нужен, как работает, какие проблемы решает. И только потом можно переходить к тому, что «под капотом», и показывать, как он устроен внутри. Для экономии времени можно один раз записать видео. Только необходимо следить за его актуальностью. Если не можете сами это сделать, дайте задание коллегам.
- Структура проекта. Важно показать, из чего состоит ваш сервис, какие модули включает, как они взаимодействуют между собой.
- База знаний. Обязательно пишите техническую документацию. Она будет лучом света и путеводителем по дебрям вашего проекта для новичка. Там должно быть всё: от принципов именования веток и правил создания pull request в Git до описания серверной инфраструктуры и набора технических инструментов.
- Поднятие проекта. Помогите новичку развернуть проект, не бросайте его на этом этапе. Даже опытный программист может спасовать перед такой задачей, когда там всё запутано. Чтобы ускорить этот процесс, напишите инструкцию. Но ещё больше сэкономить времени можно, если заняться этим заранее и настроить сам процесс сборки проекта.
- От простого к сложному. За два дня рассказать обо всём, а потом бросить новичка на амбразуру и заставить пилить новые сложные фичи? Отличный план для провала. Ресурсы человеческого мозга небезграничны, вводите его в курс дела постепенно. Потратьте совсем немного времени и подберите ему задачи с нарастающей сложностью, постепенно выводите его на нужный уровень сложности.
Я опять не рассказал ничего нового, но почему-то в очень многих компаниях продолжают совершать такие ошибки. А потом удивляются, что человек с большим опытом делает досадные ляпы. Тут логично провести мою любимую аналогию со спортом: профессиональный игрок отлично умеет бить по мячу и ловко давать пас, но без знания тактики и стратегии команды от него не будет толка и результатов. Именно поэтому и нужен тренер, который поможет игроку стать частью команды. Если вы руководитель команды, то ввод новых людей команду должен лежать на вас. Нехватка времени и прочие причины, это всего лишь отговорки. Это действительно важный процесс, который за вас никто не наладит.
Истории из жизни
Ниже я поделюсь поучительными случаями из собственной практики. У меня тоже не сразу получилось отладить процесс, я к этому шёл через ошибки.
О поднятии проекта
Когда моя команда была совсем маленькой, новым сотрудникам мы поднимали все сервисы с нуля на каждой машине. Конечно, я тратил на это кучу времени или отнимал его у коллег, когда просил их помочь. С ростом компании и IT-отдела это стало головной болью.
Признаюсь, я упустил этот момент. Кроме того, это вызывало проблемы не только с новичками. Когда кому-то из сотрудников надо было поднять сервис, который писала другая команда, они были готовы застрелиться. А если разом надо было поднять десяток? Я решил ситуацию кардинально: перевёл всю инфраструктуру на Docker. Да, было непросто, потратили немало времени и сил, но очень много этим сэкономили в будущем. Мы подобрали оптимальные конфигурации проектов и каждую снабдили подробными инструкциями о том, как разворачивать и поднимать.
В итоге все наши 15 внутренних сервисов разворачивались за 20–30 минут. То есть новички безболезненно перескакивали один из этапов адаптации на новом месте. Многие даже удивлялись, вспоминая свой прошлый опыт. Для меня это было лучшей похвалой. К слову, я знаю много компаний, в которых новичков бросали наедине с проектом, и им приходилось тратить целую неделю на поднятие!
О документации
Наверное, как и у всех, в начале проекта у нас совсем не было документации. И пока команда была небольшая, а сервис скромным по функционалу, в этом не было никаких проблем. Но через два года при переключении на другие части проекта разработчики уже сами не понимали, как работают те куски сервиса, которые они давно не трогали. Рассказывать новым сотрудникам о проекте было ещё сложнее. Тем более, когда он состоит из 15 сервисов, которые работают по-разному и на разных технологиях.
На первом этапе решения проблемы записали обучающие видео для всех сотрудников всех отделов. Программистам давали смотреть все, чтобы они понимали, как устроена работа сервисов с точки зрения пользователя. Это сильно экономило время, не надо было долго рассказывать, хватало 10 минут, чтобы ответить на вопросы после просмотра.
Затем мы подготовили документацию в двух версиях: для новичков и расширенную для всех остальных. Первая по сути была простой шпаргалкой для начального этапа ввода человека в команду, там новички могли находить всё самое важное. А второй, расширенной версией, уже пользовались все. Там было описано всё: от архитектуры и инструкций по разворачиванию проектов до тонких технических нюансов использования тех или иных технологий. Позже создали ещё один большой документ, который описывал взаимодействие всех компонентов нашей общей системы.
Можно сказать, поиска по большой доке сначала не было, пользоваться было крайне неудобно, поэтому всё перевели на Wiki-движок. При правильной организации, а это удалось тоже не с первой попытки, всё оказалось очень удобно и доступно. Позже мы ещё добавили дополнительные документы для разных отделов. И тогда наша документация стала полноценной базой знаний. Например, понадобилось настроить репликацию на каком-то из сервисов, находишь нужную статью с инструкциями и примерами.
Каждый сотрудник мог дописывать и редактировать документы, были ответственные, которые следили за актуальностью сведений, но в процесс так или иначе были вовлечены почти все. Здесь важно отметить ключевой момент — знания не должны замыкаться на одном человеке, это путь в никуда. Он может заболеть или уволиться, тогда в случае его отсутствия может случиться информационный коллапс.
Я уже давно ушёл из той компании, но база жива, ей постоянно пользуются сотрудники.
О комфорте
Когда-то я сам приходил на новую работу рядовым программистом, мне было приятно, когда старались создать комфортные условия и всё объясняли. Но было, когда просто сажали на рабочее место и оставляли один на один с проектом. Это жутко бесило. Но руководство не видело в этом проблемы.
Помня о своём опыте, я всегда стараюсь прислушиваться к людям и создавать комфортные условия. Например, было такое, что человеку не хватало хороших наушников с шумоподавлением или стула с поддержкой спины. В моей практике даже была история, когда программист пришёл на PHP, но в душе хотел заниматься JS. Я как раз переформировывал отдел, а у человека была отличная мотивация и горящие глаза. В итоге я перевёл его на другую позицию, все остались довольны.
Ребята, которые пришли в мой отдел, очень ценили такое отношение. Говорили, что у нас всё очень сложно устроено, но благодаря такому плавному вводу в курс дела и помощи других сотрудников они быстро осваивались в команде.
Я считаю, что во многом помогает хорошо отлаженная коммуникация и дружественная атмосфера в команде. Team Leader должен жить с командой, CTO с TL и процессами, наверное, только тогда будет идиллия.
Тест-драйв проекта
Бывают такие досадные случаи, когда нового человека берут в компанию, но уже в процессе работы выясняется, что либо он не подходит для проекта, либо проект по каким-то причинам не подходит ему. Конечно, ситуация не рядовая, но иногда случается.
Чтобы минимизировать риски для обеих сторон, я ввёл такую практику, как тестовый день. Мы использовали такой подход, когда были сомнения. То есть специалист мог поработать день, чтобы попробовать на зуб новый для него проект, посмотреть, как всё устроено. Мы в свою очередь даже за такое короткое время могли комплексно оценить его.
У инженера может быть много причин, по которым проект ему не нравится. Например, он может не захотеть работать с легаси, ему могут не понравиться подходы в разработке, наконец, ему может не подойти атмосфера в команде. И бывает, что человеку недостаточно этих причин, чтобы уйти после испытательного срока. Он остаётся, но испытывает дискомфорт или недовольство.
Чтобы исключить подобные ситуации, мы и проводили тестовые дни. Люди просто брали отгул и приходили к нам попробовать поработать. В этом случае времени для знакомства с проектом было ещё меньше, поэтому мы вводили их в курс дела по ускоренной программе. Это приносило свои плоды: в случае сомнений после собеседования мы вместе с кандидатом принимали правильное решение. Таким образом, он не рисковал потерять существующую работу и попасть в проект, который ему не нравится, а мы экономили много ресурсов в случае, если человек в итоге не становился членом команды. Кстати, подобный подход используют и некоторые другие компании.
Выводы
В разных компаниях рабочие процессы сильно отличаются, также везде своя специфика и архитектура. Поэтому даже крутым специалистам требуется время на адаптацию. Ваша задача — сделать её наиболее эффективной и максимально сократить по времени. Поэтому стоит уделить время отладке такого процесса, как ввод нового сотрудника в команду. Если вы ещё не делали шагов в этом направлении, то старайтесь заняться этим как можно скорее. Это в будущем поможет вам сэкономить много времени. И неважно, сколько человек работает в компании, 10 или 1000. Ещё важно понимать, что если этим некому заниматься, то ответственность всё равно лежит на руководителе команды.
В моей команде удалось добиться сокращения времени ввода до трёх дней! Уже после такого короткого срока человек вливался в команду и брался за текущие задачи. Универсального рецепта нет, в каждой ситуации будет работать свой план. Но на мой взгляд, ключевые аспекты — это тщательная подготовка к набору новых сотрудников (документация, настройка окружения, аппаратное обеспечение), создание комфортных условий, грамотное знакомство с проектом и поддержка со стороны коллег и, конечно, руководителя команды.
P.S. А вдруг у вас есть интересные, забавные или поучительные истории о том, как вас вводили в команду? Жгите в комментах! :)
Мои другие статьи о менеджменте в IT:
Что такое быть Team Leader
Dream team из ничего: найм специалистов в IT
Как создавать успешные команды и управлять ими
Расти, Team Leader, большой и маленький
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
В конце хотелось бы собрать мнения о том, как вас вводили в новый проект или команду
4.88% Идеально: всё показали и рассказали4
20.73% Познакомили с проектом и рассказали об основных аспектах, но когда начал копать глубже, пришлось разбираться самому17
45.12% Пробежались по верхам, дальше изучал самостоятельно37
29.27% Посадили на рабочее место и ушли24
Проголосовали 82 пользователя. Воздержались 20 пользователей.
