Что такое адаптация? Мерриам Вебстер определяет ее как «действие или процесс интеграции нового сотрудника в организацию».
Интеграция сотрудника - расплывчатое определение, но должно быть. Все места разные, как и процесс адаптации.
Итак, что такое онбординг?
Это просто целенаправленное наставничество? В рамках данной статьи давайте подумаем об этом как об этом. Кроме того, это можно рассматривать как систему друзей для новых сотрудников.
Когда к вашей команде присоединяется новый программист, происходит много типов адаптации. Иногда трудно вспомнить все изменения, которые приносит новая должность. В этой статье будет обсуждаться адаптация или наставничество новых программистов (программистов, разработчиков, инженеров) в их повседневной работе.
Следует отметить, что новые члены любой организации также столкнутся с другими проблемами адаптации, которые здесь не рассматриваются. Важно принять это к сведению и признать, что они могут создать дополнительные проблемы для выполнения вашего нового кодировщика в своей новой роли. Так как это не исчерпывающий список, не ограничивайте его дальнейшее исследование. Однако помните о времени и проблемах, связанных с человеческими ресурсами, культурой, технологиями и наборами инструментов, рабочими процессами в команде и языком (устным и письменным).
Теперь, когда мы знаем о возможностях адаптации, эта статья охватывает. Может быть полезно отметить когда обычно происходит адаптация, и это не всегда только новые сотрудники. Когда программист присоединяется к новой компании, необходимо его адаптировать. Легкость перехода будет определяться многими факторами. Учебная программа по адаптации - не единственное препятствие на пути к продуктивной работе нового сотрудника в его или ее новой команде. Командная культура станет важной частью этого процесса. Но также должны быть четкие ожидания для нового кодировщика. Сейчас не время для губительного сочувствия, точно сказать программисту, чего от него ждут в первые несколько недель, и прояснить, что научиться работать в своей новой команде - это такая же их работа, как и остальная часть команды. .
Кроме того, адаптация происходит не только тогда, когда новый сотрудник нанимается не из организации. Этот процесс будет полезен, когда программисты меняют команды, меняют проекты или меняют роли.
Не говоря уже о том, что и когда, давайте поговорим о как. Не существует единого решения, которое всегда работало бы. Если вы, читатель, программист, я понимаю, что вы, возможно, пришли сюда в поисках волшебного алгоритма успешной адаптации.
К сожалению, я не нашел ни одного.
В этой статье я расскажу о нескольких подходах к адаптации и наставничеству за последние 10 с лишним лет. Этот автор не претендует на звание эксперта по этому вопросу, и оставшаяся часть этой статьи будет основана на моем опыте работы в качестве нового сотрудника, а также на моих наблюдениях за помощью наставником и привлечением более дюжины новых программистов к довольно сложному набору программистов. программные продукты. Если вы ищете статью по общественным наукам, лучше всего поискать в другом месте на этом этапе. Я планирую описать некоторые особенности и процедуры, непосредственно применимые к новым программистам.
До конца текста не забывайте о следующей цели. Цель успешной адаптации - обеспечить беспрепятственный и продуктивный опыт как на борту, так и на борту.
Сфера
Новому члену команды есть чему поучиться в нашей области. Даже с многолетним опытом, который действительно помогает, мало шансов, что новый рок-звездный программист, который только что присоединился к команде, знает «все». Имея такое большое количество знаний, может быть полезно сузить круг вводных заданий, которые будут даны новому члену команды. У большинства программ много движущихся частей. Есть код для уровня сервера, уровня клиента, обычно какого-то уровня данных. Размещенное приложение может быть в облаке или на сайте. Инструменты, которые мы используем, разнообразны и разнообразны. Даже операционные системы разных компаний различаются.
Мое первое предложение - сузить область взаимодействия нового кодировщика. Во-первых, спросите их о том, что им нравится строить и чему они хотят научиться. Цель здесь - сузить рамки объяснения и понимания. Это полезно как для существующих, так и для новых членов команды. Суженный объем позволяет дать более короткие объяснения и позволяет новому программисту лучше понять, как работают более мелкие части приложения. Длинные объяснения иногда могут привести к разговору с нечеткими решениями и большим количеством потерянных деталей.
Тем не менее, не избегайте общих представлений о программном обеспечении. Иногда обсуждение большого объема может помочь сформулировать более мелкую задачу.
Документация
Одна из самых больших проблем для начинающего программиста - это настройка среды разработки. Контроль и точная настройка везде различаются, поэтому единственное, что я предлагаю, - это задокументировать это до процесса адаптации.
Документация о процессе (канбан, схватка и т. Д.), Настройке локального разработчика, передовых методах кодирования и контроле версий полезна как для наставников, так и для подопечных. Если у вас еще нет документов, начните прямо сейчас. Если это кажется сложным, начните с малого. И не пиши все в одиночку. Превратите это в командные усилия.
Я предлагаю хранить информацию там, где у команды будет постоянный принудительный доступ к ней. Местоположения, которые работали в прошлом, находятся в кодовой базе как README и на доске программного обеспечения для отслеживания работы группы (например, доска проектов Azure или Jira). Если информация находится вне поля зрения, она будет обновляться и к ней будут обращаться реже.
При настройке своей локальной среды. Направьте новым кодировщикам информацию и предложите им обновить ее на предмет ошибок и упущений, которые они случайно обнаружат. Это заставляет их делать что-то во время обучения, что, по-видимому, дает преимущества перед запоминанием. Это также способствует общению.
Наставник
Когда новый dev. присоединяется к команде. Если это имеет смысл с учетом размера вашей команды, представьте нового сотрудника старшему * члену команды. Иногда полезно также сузить рамки социального взаимодействия в течение первых нескольких недель. Поощрение человека, которому они задают вопросы, устраняет неуверенность в том, кто и как задает их вопросы. Кроме того, новый программист должен будет знать, кто лучше всех ответит на его вопросы. Но будьте осторожны, не заставляйте двух человек ладить, если они не ладят, и не заставляйте намеренно одного разработчика выполнять всю адаптацию.
Это действительно командные усилия, когда все члены команды должны помогать в процессе адаптации. Фактически, в зависимости от задач, поставленных перед новым кодировщиком, вы можете подумать о смене их наставника на постоянного программиста, обладающего наибольшими знаниями в этой области.
* Я использую здесь старшего как человека, хорошо знающего кодовую базу. Необязательно быть более опытным в этой области, но он должен уметь отвечать на вопросы о продуктах, за поддержку которых отвечает команда.
Стратегии
Вот несколько стратегий, которые мы использовали на протяжении многих лет, чтобы вовлечь новых программистов в повседневную работу по созданию программного обеспечения. Они не перечислены в каком-либо определенном порядке, и вам нужно будет выбрать, что лучше всего подходит для данной ситуации и отдельных лиц в команде.
Самостоятельное обучение может быть первым, что приходит на ум, когда вы думаете о начале новой работы. Это имеет место в процессе адаптации. На самом деле, на мой взгляд, его лучше всего использовать в качестве дополнения к другим методам, перечисленным в статье. Если часть технологического стека новичку не знакома, дайте ему прочитать конкретный пример обучающего видео или статьи. Ключевое слово здесь конкретное. Убедитесь, что это тот, который вы читали или смотрели, и тот, в котором вы цените содержание.
Преимущество самостоятельного обучения заключается в том, что оно дает наставникам в команде перерыв от наставничества для выполнения своих обычных задач. Кроме того, программисты стремятся узнать, как что-то работает, поэтому время, отведенное и потраченное на обучение, обычно воодушевляет новых сотрудников. Только будьте осторожны, это не ваша единственная стратегия адаптации, так как это может вызвать отчуждение вашего нового разработчика рок-звезды. Вы по-прежнему хотите, чтобы в команде происходило человеческое взаимодействие и общение.
Парное программирование (также известное как теневое программирование) отлично подходит для облегчения работы новых программистов в кодовой базе. Сидя рядом (физически или виртуально), наставник должен объяснить проблему и объем задачи, над которой он работает. Это важно для понимания новым кодировщиком того, как команда выполняет работу, и уровня знаний, ожидаемых от них в будущем. Сначала эта стратегия, скорее всего, начнется с того, что новый кодер будет наблюдать и задавать вопросы, но по мере того, как он или она станет более комфортно работать с кодовой базой, их следует поощрять брать на себя инициативу, в то время как другой будет их копировать.
Как наставник, ведущий сеанс парного программирования, ищите возможности получить мнение другого члена команды, чтобы поддерживать его интерес. Кроме того, старайтесь избегать чрезмерных объяснений новому разработчику. Вспомните, когда вы были новичком в команде. Есть много чего принять и запомнить. Повторение и действия помогут, но иногда слишком много информации может ошеломить.
Этот тип адаптации является более всеобъемлющим, чем самостоятельное обучение, поскольку он открывает для нового члена команды больше, чем просто аспект программирования в его работе. Вероятно, в ходе слежения за задачей кодировщик получит доступ к командному рабочему процессу и методам взаимодействия, системам контроля версий, форматированию базы кода и лучшим практикам, а также ожидаемым темпам работы. Настоящая проблема этой стратегии состоит в том, чтобы удержать разработчика, который не набирает текст, в происходящем.
После нескольких тезисов обеим сторонам всегда будет полезно ответить на следующие вопросы. Помогло ли вам понимание этого задания? Что я не так хорошо объяснил? Что для вас было нового? Эти вопросы часто помогают новым кодировщикам решать следующую задачу или дают хорошие идеи о том, какими темами следует заняться в следующем самостоятельном обучении. Для наставника любые отзывы об их объяснениях могут быть полезными для следующей встречи.
Управляемый псевдокод с частыми проверками - лучший способ описать следующую стратегию. Ищите меньшую задачу, над которой новый кодировщик может работать автономно без излишней срочности, но убедитесь, что она по-прежнему достаточно сложна, чтобы сохранять интерес. Ошибки или дефекты в продукте - отличное место для поиска. Начните с совместного открытия, убедившись, что проблема, которую нужно решить, ясна. Если это требует ввода от дизайнеров или членов команды взаимодействия с пользователем, вовлеките их в обсуждение открытия, при необходимости отслеживая любые детали.
Как только обнаружение будет ясным и определенным, напишите вместе псевдокод или список дел. Поощряйте нового кодировщика составить список, но помогайте с частями, которые, как вы знаете, потребуют дополнительных сведений. Псевдокод - не единственный способ подойти к этому этапу. Вы можете вместе составить список управляемых задач. Ключевым моментом здесь является то, что он записан в логическом порядке и подробно описывает части, которые могут быть выполнены небольшими шагами.
Теперь, когда вы знаете, что и как делать, позвольте подопечному автономно работать со списком. Я обычно рекомендую работать с правилом 20 минут. Если вы застряли более чем на 20 минут, задайте вопрос или попросите подсказку. Если понимание каждой отдельной задачи занимает больше 20 минут, подумайте о том, чтобы разбить список задач на более мелкие части. Идея состоит в том, чтобы дать возможность новому члену команды работать в своем собственном темпе, но при этом не допустить, чтобы он был разочарован или потерян. Небольшие дела помогают сосредоточиться на текущей задаче.
Псевдокод со стратегией руководства полезен для того, чтобы облегчить новому члену команды работу самостоятельно, но при этом дает ему запланированный выход для помощи. Легче попросить о помощи, когда это ожидается. Наставнику в этих отношениях важно подчеркнуть, что просьбы о помощи поощряются, а не надоедают. Кроме того, часто проверяйте, чтобы следить за прогрессом и препятствиями на пути.
Покажи и расскажи, на самом деле, не является стратегией само по себе. Однако это может быть полезно при использовании вместе с другими стратегиями. Когда подопечный не понимает концепции или с трудом справляется с задачей, укажите на пример (в кодовой базе, если возможно), объясните основы, а затем укажите им более подходящее объяснение. Часто руководство или документация по языку / фреймворку / и т. Д. более полезно, чем другое личное объяснение. Это не только решает текущее препятствие, но и помогает новому кодировщику искать помощи при работе в одиночку.
Аналогичная стратегия - спросить нового программиста, над чем он работает, и попросить его показать вам. Это хорошая обратная связь, чтобы увидеть, как они продвигаются в изучении кодовой базы, и поможет указать наши области, нуждающиеся в более целенаправленном обучении.
При всех этих стратегиях цикл обратной связи после каждых нескольких сессий полезен для обеих сторон. Так что держите общение открытым и честным.
Что делать, если не работает?
Если у вас возникают проблемы с тем, чтобы новый кодировщик выполнял задачи в одиночку, подумайте о том, чтобы сделать задачи более сложными. Если идеи и концепции не находят отклика, упростите и разбейте задачи.
Разные люди по-разному реагируют на приведенные выше стратегии. В том числе и наставник. Если одна стратегия не работает, попробуйте новый подход. У некоторых людей личностные конфликты, попробуйте сменить наставника. Думаю, вы можете увидеть здесь закономерность. Если что-то не работает, попробуйте изменить свой подход. Спросите и у нового программиста, что они думают. Акцент здесь делается на честном общении, четких ожиданиях и поиске того, что лучше всего работает для команды.
По прошествии определенного времени, если прогресс по-прежнему будет медленным и часто разочаровывающим для остальной команды, это может не быть стратегией. Некоторым вещам нельзя научить. Я обнаружил, что научить человека быть заинтересованным, проактивным и автономным не работает. Может быть, это приобретенный навык. Может, это черта личности. По профессии я кодировщик, а не врач, так что не верьте мне на слово. Воспринимайте это как мою наблюдательную теорию, основанную на последних 10 с лишним лет. Вот здесь-то и появляется честное общение. Если вам нужно, чтобы новый член команды проявлял большую активность при выполнении работы, скажите ему об этом. Если вы ожидаете, что они будут участвовать в обсуждениях и встречах. пусть они знают. Установите четкие ожидания.
Как определить успех?
Успех сложно определить с помощью стратегии адаптации. Вы обнаружите, что не все стратегии «подходят» всем людям. Лучшее, что у меня есть, - это делать что-то каждый день. Небольшая ежедневная победа, то есть исправление ошибки, изучение концепции или обучение кодовой базе, сохранит у всех положительный опыт. Ежедневные небольшие задачи в конечном итоге перерастут в более крупные и грандиозные достижения. Я считаю, что это успех, все в команде прилагают усилия для достижения общих целей.
Когда вы достигли этого момента, наставничество не должно заканчиваться. Я всегда надеюсь, что ученик станет мастером и передаст то, чему научился.
Надеюсь, описанные выше стратегии позволят вам успешно задействовать несколько новых замечательных талантов. Помните, что приведенная выше информация не является исчерпывающим списком. Комбинируйте и сочетайте то, что имеет наибольшее значение для вас, вашей команды и вашей организации. А теперь иди и получай удовольствие, создавая что-нибудь крутое.
