Новый сотрудник — dead or alive

    Всем привет! Продолжаю рассказывать об опыте управления в IT. Сегодня поговорим о вводе нового сотрудника в команду. Вы взяли инженера в штат. Когда он станет полноценной боевой единицей? Что делать, чтобы ускорить его адаптацию? Как оптимизировать этот процесс? В конце концов, стоит ли вообще уделять этому внимание и тратить время?

    image

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

    Я считаю, что ввод нового сотрудника в команду крайне важный процесс, и чем он более отлажен, тем быстрее новичок становится полноценным сотрудником и тем меньше времени вы на это тратите.

    Превращение из новичка в коллегу


    image

    Когда я работал в сервисе-агрегаторе б/у запчастей, ввод новых людей в команду занимал 3 дня. После этого они с остальными на равных решали текущие задачи, участвовали в обсуждениях и шутили с коллегами у кофейного аппарата. Но я к этому пришёл, конечно, не сразу, сначала пришлось набить шишки и получить опыт. Только потом я сформировал для себя основные принципы и выстроил процесс.

    Вот главные нюансы, которые я вынес для себя из практики управления командами.

    1. Ввод человека в команду стоит начинать со знакомства с проектом. И это я делал уже на собеседовании. У меня всегда был наготове 10-минутный рассказ о компании в целом, на чём она зарабатывает, как устроен сервис, структуре отделов и прочем.
    2. Подготовка рабочего места и создание комфортных условий для работы. Человек должен в первый день сесть за свой стол с удобным стулом или креслом и включить уже настроенный компьютер. Не успели подготовить всё это? Ваш косяк, этому действительно надо уделять внимание.
    3. Индивидуальный подход. Например, для создания комфорта (а он необходим, особенно в условиях стресса при переходе на новое место работы). Неплохо поинтересоваться о предпочтениях в плане операционной системы и клавиатуры/мыши. Может вы будете первым работодателем, который такое предложит. А это поднимет вашу компанию в глазах сотрудника.
    4. Правильное знакомство с командой. Недостаточно просто представить по именам всех сотрудников и разойтись по рабочим местам. Можно сделать так: это Миша, он отвечает за бэкенд, это Петя, он DevOps, а Вася и Коля отвечают за клиентскую часть, им можно задавать вопросы по таким-то аспектам. И это всё должно быть отражено в служебной документации для сотрудников, но об этом ниже.
    5. Знакомство с компанией. Я считаю, что лучше всего провести его по отделам и рассказать, как устроена компания внутри, каким образом налажено взаимодействие между сотрудниками. В будущем это пригодится.
    6. Быт. Новый инженер должен обязательно знать такие банальные вещи, где находится уборная, как пользоваться кофемашиной и где можно разогреть еду. Отличный шаг в сторону сближения с коллегами — пригласить его на обед вместе с командой.
    7. Принципы работы команды. Везде свои правила и условия. Например, у нас в команде было принято работать по гибкому графику, любой мог приходить в удобные для него часы или отпроситься на день по делам или поработать из дома. Но в случае релиза или нештатных ситуаций мы задерживались и вместе решали проблему. Также в команде сложилась дружественная атмосфера, мы относились друг к другу с уважением, и ждали этого от новичков.

    В общем-то, никаких тайн я не открыл, но эти аспекты действительно имеют большое значение. Первое впечатление очень важно, именно с него у человека будет формироваться мнение о компании и о его месте в ней.

    Ещё один крайне важный фактор — снижение уровня стресса. Он неизбежен, так как переход на новую работу — это выход из зоны комфорта, все люди разные, не все умеют хорошо справляться с этим. Ваша задача — максимально сгладить процесс вхождения человека в команду. И тут важно внимание к мелочам. Например, человек может постесняться попросить заменить неудобную клавиатуру. Или если видите, что он интроверт, будьте деликатнее и не выводите его под софиты в центр арены опенспейса при знакомстве с командой.

    Как быстро погрузить новичка в проект и не убить его


    image

    Человек пришёл к вам работать, вы его познакомили с коллегами и компанией в целом, создали комфортные условия. Пора приниматься за работу. Ведь ваша задача в том, чтобы он включился в процесс разработки и как можно быстрее начал приносить пользу компании. И в этой ситуации главное не перебрать со скоростью. Погружайте новоиспечённого коллегу в работу плавно.

    Итак, ниже основные шаги, которые позволяют мне максимально быстро и безболезненно превратить новичка в полноценного члена команды.

    1. Рассказ о проекте. Я считаю, что сначала надо рассказывать о проекте с точки зрения клиентов. Для чего он нужен, как работает, какие проблемы решает. И только потом можно переходить к тому, что «под капотом», и показывать, как он устроен внутри. Для экономии времени можно один раз записать видео. Только необходимо следить за его актуальностью. Если не можете сами это сделать, дайте задание коллегам.
    2. Структура проекта. Важно показать, из чего состоит ваш сервис, какие модули включает, как они взаимодействуют между собой.
    3. База знаний. Обязательно пишите техническую документацию. Она будет лучом света и путеводителем по дебрям вашего проекта для новичка. Там должно быть всё: от принципов именования веток и правил создания pull request в Git до описания серверной инфраструктуры и набора технических инструментов.
    4. Поднятие проекта. Помогите новичку развернуть проект, не бросайте его на этом этапе. Даже опытный программист может спасовать перед такой задачей, когда там всё запутано. Чтобы ускорить этот процесс, напишите инструкцию. Но ещё больше сэкономить времени можно, если заняться этим заранее и настроить сам процесс сборки проекта.
    5. От простого к сложному. За два дня рассказать обо всём, а потом бросить новичка на амбразуру и заставить пилить новые сложные фичи? Отличный план для провала. Ресурсы человеческого мозга небезграничны, вводите его в курс дела постепенно. Потратьте совсем немного времени и подберите ему задачи с нарастающей сложностью, постепенно выводите его на нужный уровень сложности.

    Я опять не рассказал ничего нового, но почему-то в очень многих компаниях продолжают совершать такие ошибки. А потом удивляются, что человек с большим опытом делает досадные ляпы. Тут логично провести мою любимую аналогию со спортом: профессиональный игрок отлично умеет бить по мячу и ловко давать пас, но без знания тактики и стратегии команды от него не будет толка и результатов. Именно поэтому и нужен тренер, который поможет игроку стать частью команды. Если вы руководитель команды, то ввод новых людей команду должен лежать на вас. Нехватка времени и прочие причины, это всего лишь отговорки. Это действительно важный процесс, который за вас никто не наладит.

    Истории из жизни


    Ниже я поделюсь поучительными случаями из собственной практики. У меня тоже не сразу получилось отладить процесс, я к этому шёл через ошибки.

    О поднятии проекта


    Когда моя команда была совсем маленькой, новым сотрудникам мы поднимали все сервисы с нуля на каждой машине. Конечно, я тратил на это кучу времени или отнимал его у коллег, когда просил их помочь. С ростом компании и IT-отдела это стало головной болью.

    Признаюсь, я упустил этот момент. Кроме того, это вызывало проблемы не только с новичками. Когда кому-то из сотрудников надо было поднять сервис, который писала другая команда, они были готовы застрелиться. А если разом надо было поднять десяток? Я решил ситуацию кардинально: перевёл всю инфраструктуру на Docker. Да, было непросто, потратили немало времени и сил, но очень много этим сэкономили в будущем. Мы подобрали оптимальные конфигурации проектов и каждую снабдили подробными инструкциями о том, как разворачивать и поднимать.

    В итоге все наши 15 внутренних сервисов разворачивались за 20–30 минут. То есть новички безболезненно перескакивали один из этапов адаптации на новом месте. Многие даже удивлялись, вспоминая свой прошлый опыт. Для меня это было лучшей похвалой. К слову, я знаю много компаний, в которых новичков бросали наедине с проектом, и им приходилось тратить целую неделю на поднятие!

    О документации


    Наверное, как и у всех, в начале проекта у нас совсем не было документации. И пока команда была небольшая, а сервис скромным по функционалу, в этом не было никаких проблем. Но через два года при переключении на другие части проекта разработчики уже сами не понимали, как работают те куски сервиса, которые они давно не трогали. Рассказывать новым сотрудникам о проекте было ещё сложнее. Тем более, когда он состоит из 15 сервисов, которые работают по-разному и на разных технологиях.

    На первом этапе решения проблемы записали обучающие видео для всех сотрудников всех отделов. Программистам давали смотреть все, чтобы они понимали, как устроена работа сервисов с точки зрения пользователя. Это сильно экономило время, не надо было долго рассказывать, хватало 10 минут, чтобы ответить на вопросы после просмотра.

    Затем мы подготовили документацию в двух версиях: для новичков и расширенную для всех остальных. Первая по сути была простой шпаргалкой для начального этапа ввода человека в команду, там новички могли находить всё самое важное. А второй, расширенной версией, уже пользовались все. Там было описано всё: от архитектуры и инструкций по разворачиванию проектов до тонких технических нюансов использования тех или иных технологий. Позже создали ещё один большой документ, который описывал взаимодействие всех компонентов нашей общей системы.

    Можно сказать, поиска по большой доке сначала не было, пользоваться было крайне неудобно, поэтому всё перевели на Wiki-движок. При правильной организации, а это удалось тоже не с первой попытки, всё оказалось очень удобно и доступно. Позже мы ещё добавили дополнительные документы для разных отделов. И тогда наша документация стала полноценной базой знаний. Например, понадобилось настроить репликацию на каком-то из сервисов, находишь нужную статью с инструкциями и примерами.

    Каждый сотрудник мог дописывать и редактировать документы, были ответственные, которые следили за актуальностью сведений, но в процесс так или иначе были вовлечены почти все. Здесь важно отметить ключевой момент — знания не должны замыкаться на одном человеке, это путь в никуда. Он может заболеть или уволиться, тогда в случае его отсутствия может случиться информационный коллапс.

    Я уже давно ушёл из той компании, но база жива, ей постоянно пользуются сотрудники.

    О комфорте


    Когда-то я сам приходил на новую работу рядовым программистом, мне было приятно, когда старались создать комфортные условия и всё объясняли. Но было, когда просто сажали на рабочее место и оставляли один на один с проектом. Это жутко бесило. Но руководство не видело в этом проблемы.

    Помня о своём опыте, я всегда стараюсь прислушиваться к людям и создавать комфортные условия. Например, было такое, что человеку не хватало хороших наушников с шумоподавлением или стула с поддержкой спины. В моей практике даже была история, когда программист пришёл на PHP, но в душе хотел заниматься JS. Я как раз переформировывал отдел, а у человека была отличная мотивация и горящие глаза. В итоге я перевёл его на другую позицию, все остались довольны.

    Ребята, которые пришли в мой отдел, очень ценили такое отношение. Говорили, что у нас всё очень сложно устроено, но благодаря такому плавному вводу в курс дела и помощи других сотрудников они быстро осваивались в команде.

    Я считаю, что во многом помогает хорошо отлаженная коммуникация и дружественная атмосфера в команде. Team Leader должен жить с командой, CTO с TL и процессами, наверное, только тогда будет идиллия.

    Тест-драйв проекта


    image

    Бывают такие досадные случаи, когда нового человека берут в компанию, но уже в процессе работы выясняется, что либо он не подходит для проекта, либо проект по каким-то причинам не подходит ему. Конечно, ситуация не рядовая, но иногда случается.

    Чтобы минимизировать риски для обеих сторон, я ввёл такую практику, как тестовый день. Мы использовали такой подход, когда были сомнения. То есть специалист мог поработать день, чтобы попробовать на зуб новый для него проект, посмотреть, как всё устроено. Мы в свою очередь даже за такое короткое время могли комплексно оценить его.

    У инженера может быть много причин, по которым проект ему не нравится. Например, он может не захотеть работать с легаси, ему могут не понравиться подходы в разработке, наконец, ему может не подойти атмосфера в команде. И бывает, что человеку недостаточно этих причин, чтобы уйти после испытательного срока. Он остаётся, но испытывает дискомфорт или недовольство.

    Чтобы исключить подобные ситуации, мы и проводили тестовые дни. Люди просто брали отгул и приходили к нам попробовать поработать. В этом случае времени для знакомства с проектом было ещё меньше, поэтому мы вводили их в курс дела по ускоренной программе. Это приносило свои плоды: в случае сомнений после собеседования мы вместе с кандидатом принимали правильное решение. Таким образом, он не рисковал потерять существующую работу и попасть в проект, который ему не нравится, а мы экономили много ресурсов в случае, если человек в итоге не становился членом команды. Кстати, подобный подход используют и некоторые другие компании.

    Выводы


    В разных компаниях рабочие процессы сильно отличаются, также везде своя специфика и архитектура. Поэтому даже крутым специалистам требуется время на адаптацию. Ваша задача — сделать её наиболее эффективной и максимально сократить по времени. Поэтому стоит уделить время отладке такого процесса, как ввод нового сотрудника в команду. Если вы ещё не делали шагов в этом направлении, то старайтесь заняться этим как можно скорее. Это в будущем поможет вам сэкономить много времени. И неважно, сколько человек работает в компании, 10 или 1000. Ещё важно понимать, что если этим некому заниматься, то ответственность всё равно лежит на руководителе команды.

    В моей команде удалось добиться сокращения времени ввода до трёх дней! Уже после такого короткого срока человек вливался в команду и брался за текущие задачи. Универсального рецепта нет, в каждой ситуации будет работать свой план. Но на мой взгляд, ключевые аспекты — это тщательная подготовка к набору новых сотрудников (документация, настройка окружения, аппаратное обеспечение), создание комфортных условий, грамотное знакомство с проектом и поддержка со стороны коллег и, конечно, руководителя команды.

    P.S. А вдруг у вас есть интересные, забавные или поучительные истории о том, как вас вводили в команду? Жгите в комментах! :)

    Мои другие статьи о менеджменте в IT:

    → Что такое быть Team Leader
    → Dream team из ничего: найм специалистов в IT
    → Как создавать успешные команды и управлять ими

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    В конце хотелось бы собрать мнения о том, как вас вводили в новый проект или команду

    Поделиться публикацией

    Комментарии 16

      –4
      было, когда просто сажали на рабочее место и оставляли один на один с проектом. Это жутко бесило. Но руководство не видело в этом проблемы.

      Эрнест Резерфорд пользовался следующим критерием при выборе своих сотрудников. Когда к нему приходили в первый раз, Резерфорд давал задание. Если после этого новый сотрудник спрашивал, что делать дальше, его увольняли.
        +1
        Можете пояснить методологию и смысл данного тестового испытания?
          –1
          У Резерфорда это был критерий отбора талантливых и компетентных специалистов.
          Да и я сам сторонник идеи, что новый сотрудник первую неделю должен бездельничать, так он продемонстрирует свои качества лучше, чем если его сразу в работу погружать. И как ни странно, этот метод имеет шансы на эффективность, кто-то в первую же неделю ищет себе задание, другой не вылазит с развлекательных сайтов, третий идет со всеми знакомиться, четвертый садится что-то изучать и т.д.
            0
            А почему сотрудника увольняли если он спрашивал «что делать дальше» после выполнения задания?
              –2
              Считалось, что новичок и в дальнейшем будет не сам работать, а ждать пока не прилетит задание с последующими отмазками и «футболом».
                +4
                Т.е. если новичок выполнил задание и просит новое — это плохо.
                А если он выполнил задание и залип на Хабре или пошел кофе пить — это норм?
                  0

                  Считалось ровно наоборот: после первого задания сотрудник будет брать задачи сам. В наших реалиях, наверное, ближе всего: после первой назначенное таски в треккере будет брать их сам из бэклога или типа того.

                    0

                    В науке, видимо, ещё и придумывать задачи самому надо было.

                    0

                    Рискну предположить, что дело в том, что у товарища всё же был сугубо исследовательский проект. Стоит ли его опыт тащить в другие отрасли?

                    0
                    Или же формулировка кривая и выкидывали сотрудника, если он спрашивал, как именно делать задачу.
                    Такой вариант, кмк, и с исследовательским профилем задач Резерфорда лучше увязывается. Тебе сказали, что сделать, а как — уже исследуй сам.
                      0
                      Был у меня в студенчестве такой опыт. Дали задачу — я сделал
                      На следующий день два этажа в крупном банке часов 5 не работали и не понимали почему (~100 человек). Зато похвалили что нашел уязвимость в их системе )).
                      У всех таких заявлений и подходов одна общая проблема, люди излишне пытаются упростить сложную проблему.
                    0
                    «Да и я сам сторонник идеи, что новый сотрудник первую неделю должен бездельничать, так он продемонстрирует свои качества лучше, чем если его сразу в работу погружать» — Это не бездельничание, а самое сложное — освоение на новом месте работы. И главное в нём — понять какие сотрудники. Если сотрудники готовы подсказывать и помогать, то можно рассчитывать на длительное сотрудничество. А если они видят в тебе конкурента и рады твоим проблемам и тому что тебе трудно их решить — попутно с продолжением работы, начинай подыскивать новую. Атмосфера в коллективе очень важна.
                      0
                      Когда идет речь о разработке продукта, эффективном использовании человеческих ресурсов в условиях рыночных отношений и конкуренции. То стратегия Резерфорда выглядит даже не бесполезной, а вредной. Он был ученым, а в научных областях задачи в расширении границ знаний. С этой точки зрения, человек который способен самостоятельно искать проблемы и добиваться их решения полезен. Даже если он придет к выводам, который кто-то сделал ранее, то команда ученых получит еще одного сотрудника который прошел путь от причины к следствию. Если мы будем говорить о рынке, конкуренции, стоимости рабочего времени ITшника, то пускать такой золотой во всех смыслах ресурс на самотек не лучшая идея. Так себе пример…
                    0
                    Какая-то хрень, честно говоря
                      0

                      Хрень вообще думать заранее о том как быстрее ввести нового сотрудника в полноценный режим или предложенные способы?

                    0

                    Не совсем в тему, но при выдаче реальных задач новому сотруднику неплохо было бы предупреждать, делаются ли ему скидки на новичковость, а может наоборот ему даются задачи из очереди "вот наймём эксперта по этим вопросам", но она не вечна. Иначе можно попасть в такие ситуации:


                    • сотруднику скучно от "детских" задач и он начинает искать новую работу или просто демотивируется и переходит в режим "деньги платят за часы немного выше рынка и ладно, от добра добра не ищут"
                    • сотрудник наоборот считает, что если тут "детские" задачи такие, то надо уходить до того, как его ушли
                    • сотрудник считает, что все задачи настолько же интересны и демотивируется, не понимая что происходит, когда после потока явно настоящих и интересных ему задач, начинают идти "детские".

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое