У вас возникал синдром «сожалений специалиста по найму»? Это когда вы жалеете о том, что наняли кого-то сразу после того, как он начал работать. Может быть, вам не нравится внешность новичка, а может вы просто желаете погрузить мир в хаос. Или, хуже того, он как-то упомянул, что любит джаз. Какой бы ни была причина, этот пост поможет вам заставить его уволиться самостоятельно, выбрав для него худший первый проект.
Не ждите, пока он обустроится
Ему всё ещё не выдали монитор? Менеджер проекта так и не добрался до него, чтобы познакомить с продуктом, над которым работает команда? Его бейдж не работает и ему приходится просить коллег провести его в туалет? Это самое подходящее время встретиться с ним и объяснить все подробности нового проекта. Есть какой-то компонент, который он пока не освоил? Сэкономьте своё время и пока не объясняйте его — пусть разберётся самостоятельно после завершения проекта.
Выберите что-нибудь большое
Это необходимый шаг. Подберите проект, в котором задействовано как можно больше компонентов. В идеале нужно, чтобы для выполнения этого проекта требовалось два-три месяца работы самого опытного сотрудника. Выбор крупного проекта гарантирует, что у новичка не будет маленьких побед и он не сможет тешить свою самооценку. Если ему удастся разбить проект на более мелкие части, вам следует донести до него, что вам важна только конечная цель, и что вас беспокоит, что он «тратит время на менеджмент проекта», вместо того, чтобы работать!
Если кто-то возражает против выбранного вами проекта, то просто скажите, что новичок должен «почувствовать ответственность».
Пусть он отвечает за то, за что отвечал человек, которого он заменил
Это увеличивает шансы на то, что проект будет неинтересным и что никто в команде не будет по-настоящему знать, что в нём творится.
Выберите что-то спорное
Если это возможно, выберите проект, против которого возражают другие. Например, кто-то недоволен направлением его технического развития; возможно, менеджер проекта и дизайнер не могут договориться насчёт UX; может быть, кто-то думает, что проект возненавидят пользователи.
Если вам удастся найти подобный спорный проект — не говорите об этом новичку! Но сделайте так, чтобы ему пришлось взаимодействовать с тем, кто против этого проекта. Бонусные очки: если противник проекта — член команды, то назначьте его ментором новичка.
Пусть он соберёт требования
Обязательно выберите неоднозначный проект, не имеющий чёткого набора требований. Опишите проект как можно менее подробно и отправьте новичка разбираться в остальном самому.
Добавьте взаимодействия между командами
Выберите проект, требующий участия максимального количества других команд. Вот список возможных способов взаимодействия между командами:
- Проект может зависеть от API, созданного другой командой, которая сейчас слишком занята (бонусные очки: позвольте новичку встретиться с другой командой одному, чтобы он рассказал о требованиях его команды). Пусть он постоянно находится в стрессе и ощущает, что никто его не страхует; он должен уяснить, что если опоздает, то разочарует кучу людей.
- Другой команде срочно может понадобиться проект вашей команды. Сообщите новичку, что другая команда разочарована тем, что задачу поручили ему. Здесь вашими друзьями будут чувство вины и низкая самооценка!
Пусть он обучает команду новой технологии
Так мы добьёмся идеального баланса: новичок и не понимает готовых инструментов, которыми все члены команды пользуются каждый день, и является единственным членом команды, знакомым с новой технологией.
Требуйте множества действий, не связанных с кодингом
Не позволяйте ему расставлять приоритеты! Сделайте так, чтобы ему приходилось делать что угодно и всё сразу:
- Пусть он организует все связанные с проектом совещания (сделайте так, чтобы ему пришлось вести записи на этих совещаниях: тогда ему не будет хватать времени слушать и понимать)
- Заставьте его проверять оптимизацию проекта: пусть занимается бенчмарками и анализирует результаты
- Пусть он разбирается во всём жизненном цикле проекта: получит одобрение юридического отдела, проверит его на безопасность и конфиденциальность и, разумеется, подготовит график запуска.
Сделайте так, чтобы проект препятствовал работе других людей
Проект не просто должен быть сложным сам по себе. Мы хотим, чтобы против новичка работали и его негативные чувства. Это можно сделать, добавив стресса и низкой самооценки. Скажите ему, что от него зависят другие люди. Бонусные очки: выражайте согласие придерживаться строгого графика от его лица, когда он находится в том же кабинете. В большинстве случаев новички цепенеют и соглашаются со всем, что вы скажете. Когда он начнёт жаловаться на слишком жёсткие сроки дедлайнов, просто напомните ему, что он мог сказать об этом вовремя!
Выберите ему в качестве ментора самого занятого члена команды
Убедитесь, что у помогающего ему много другой работы. У него должно быть множество совещаний и, возможно, скачущий график. Например, он работает удалённо или приезжает на работу в пять утра, чтобы избежать пробок. Бонусные очки: выберите того, кто скоро собирается в отпуск или командировку.
Откладывайте любые просьбы о помощи не менее чем на два рабочих дня
Большинство новичков очень долго пытается разобраться самостоятельно, прежде чем попросить о помощи. Это значит, что если вы оставите их без внимания, когда они уже просят помощи, то в процессе ожидания они гарантированно не смогут делать ничего. Это откладывает завершение проекта, вызывая стресс. К тому же, это культивирует общее чувство беспомощности и низкое самоуважение. Помните: что посеешь, то и пожнёшь, так что посейте немного несчастья!
Джун: «Можете мне помочь с этим?»
Сениор: «Прежде чем просить о помощи, попробуй разобраться сам»
*День спустя*
Сениор: «Ты потратил на это столько времени? В следующий раз, если запутаешься, проси о помощи»
Запланируйте частые синхронизационные совещания с участием высшего руководства
При правильном использовании синхронизационные совещания могут быть отличным способом развития проекта, поэтому не используйте их правильно! Начинайте ставить их в график ещё с ранних этапов проекта и включайте в них максимально возможное количество людей. Пусть высшее руководство ожидает быстрого прогресса; сообщите ему, кто за него ответственен. Нужно организовать всё так, чтобы после каждого синхронизационного совещания новичок ощущал себя неудачником и разочарованием. Донесите до него, что он должен презентовать что-то на совещании — благодаря этому он будет тратить время на подготовку к совещанию, а не на развитие проекта.
Как выбрать проект для новичка, чтобы он остался в компании
Ох, какая досада. Вам показалось, что новичок ужасно любит джаз, но позже он объяснил, что считает джаз ужасным. А его лицо уже не кажется таким отвратительным. Хм, возможно, стоит выбрать для него лучший проект?
Задачи для новичка, а не проект для новичка
Люди недооценивают сложность внесения даже малейших изменений в их кодовую базу. Вы представляете строки кода, но на самом деле всё гораздо масштабнее. Как ваша команда называет действие по внесению изменения в вашу кодовую базу? «Отправка диффа», «пуш коммита», «отправка мердж-реквеста»? Каждая команда делает это по-своему, и мы даже не используем одинаковые названия. У каждой команды своя система контроля версий, система отслеживания ошибок, система работы с тикетами, инструменты командной строки и так далее. Возможно, вы ко всему этому привыкли, но цель задач для новичка — упростить знакомство со всем этим. Для него это не должно быть игрой на выживание.
Начинайте с тривиально мелких задач. Нет, даже ещё меньше. И ещё меньше. Ещё немного меньше… отлично! Пусть исправит опечатку. Пусть изменит код для соответствия стандарту в том модуле, до которого у вас давно не доходили руки. Пусть добавит своё имя в файл CONTRIBUTORS проекта. Это должно быть что-то, совершенно не представляющее трудностей. Процесс понимания потока разработки труден сам по себе.
Затем начинайте двигаться вперёд небольшими шагами. Пусть он устранит небольшой баг. Вы должны знать, как выглядит решение, ещё до того, как дадите новичку эту задачу. Задачи новичков не должны делать ничего нового для вас. Пусть он добавит тест для одного конкретного бага. Пусть разберётся, как выполнять тесты, как проверить, что внесённые им изменения отразились в процессе непрерывной интеграции. Пусть он отследит их до продакшена. Не нужно торопиться.
Мелкие задачи — источник множества лёгких побед, и в то же время они позволяют познакомиться с вашей кодовой базой. Новичок прикоснётся ко всему. Начнёт узнавать имена компонентов, ассоциировать конкретную технологию и «стиль» с каждым из них, разберётся, где хранится его код в вашей системе контроля версий. Он получит представление о том, что и как вы делаете.
Пусть он работает над базовыми бизнес-задачами, основной целью вашей команды
У каждой команды есть задачи, на выполнение которых она наиболее оптимизирована. Команда, работающая над платформой обработки платежей, может считать одной из своих основных задач добавление нового поставщика сервиса платежей. Команда, сосредоточенная на разработке приложения для организации списка дел, может быть оптимизирована на добавление новых свойств задач и возможностей фильтров. Для команды разработчиков такого приложения не является основной задачей реализация платежей, а для разработчиков системы платежей основной задачей не является добавление возможности выбора пользователями крутых аватарок.
Пусть новичок занимается тем, что ваша команда делает часто и с чем справляется лучше всего. Благодаря этому всё, что он делает, будет значимо для проекта, а полученные навыки можно будет применять в будущих проектах. А ещё это значит, что все члены команды будут ему помогать, поэтому ему не придётся ждать, пока у конкретного человека появится свободное время.
Задачи должны быть максимально автономными
В идеальной ситуации для выполнения вводных задач новичку нужно общаться только с людьми из основной команды. Разумеется, если задача маленькая и чётко очерченная, вполне допустимо, что перед тем, как пушить её, она проверяется менеджером проекта. Но если новички ощутят чуть больше уверенности, прежде чем столкнуться с другими функциями, то эти взаимодействия окажутся для них гораздо более положительными.
Автономность также подразумевает отсутствие сложных перекрёстных зависимостей между задачами. Они не должны зависеть от чьего-то диффа, который будет готов «через два-три, или, может, через пятнадцать дней», как и никто не должен зависеть от изменений, вносимых новичком. Нет никакого смысла добавлять лишний стресс. Когда вы приходите на новую работу, стресса и так достаточно (и он обязательно добавится в дальнейшем).
Учитесь на ошибках прошлого
Спрашивайте членов команды об их опыте онбординга. Просите помощи у человека, пришедшего в команду последним, а не у самого опытного. Самый новый член команды, вероятно, лучше всего помнит свой опыт. Вероятно, он лучше знает, в каком поддерживаемом командой компоненте сложнее всего разобраться (и работы с которым поначалу стоит избегать), и о каких инструментах обязательно нужно рассказать в процессе онбординга.
Выберите ментора, но сделайте так, чтобы можно было обратиться к любому члену команды
Лучший разработчик команды — не всегда лучший кандидат на менторство новичка. Выберите того, кто любит обучать и к кому новичок сможет обращаться. Если обычно он участвует во множестве совещаний, возможно, ему следует освободить свой график на первые несколько дней после прихода новичка.
Однако одного человека недостаточно. Он может быть занят, заболеть или уйти в отпуск. Ментор и новичок просто могут не найти общий язык, и им некомфортно будет общаться. Сделайте так, чтобы новичок смог обратиться к любому члену команды, и чтобы ему было комфортно просить помощи. Это можно облегчить следующим образом:
- Пусть каждую мелкую задачу для новичка объясняет и проверяет другой член команды
- Пусть люди из команды рассказывают о вашем продукте и соответствующей ему кодовой базе
- Запланируйте на момент прихода новичка какое-то интересное мероприятие, чтобы он смог освоиться в общении со всеми
Проактивно предлагайте помощь
Как говорилось ранее, большинство новичков обычно тратит слишком много времени, прежде чем самим попросить о помощи. Опередите их, предлагая помощь проактивно. Однако это нужно делать аккуратно, потому что это тоже может вызывать стресс. Предложение помощи может подразумевать, будто вы думаете, что новичок запаздывает и что к этому моменту вы ожидали какого-то прогресса. Донесите до него, что если ему понадобится, вы всегда поможете, но не давите.
Когда вы помогаете новичку (проактивно или нет), не перенапрягайте его. Многие (обычно опытные) инженеры склонны отвечать на вопросы потоками подробной информации и длинными театральными монологами о том, как вы пришли к текущей ситуации («Это давняя история, начавшаяся ещё в те времена, когда контроль версий был причудой для богатых...»). Говорите новичку то, что он должен знать и спрашивайте, хочет ли он узнать подробности. Или позвольте ему сначала завершить мелкую задачу, потом сообщите чуть больше контекста, когда у него уже будет понимание того, что же делает компонент.
Автор:
PatientZero
