Руководитель отдела обучения Makers Кей рассказывает, как вы можете получить больше от своих младших разработчиков.
Чтобы добиться успеха, младшему разработчику необходимо:
- Высокие ожидания
- Полномочия и ответственность
- Отказоустойчивая среда
- Постоянный поток сложной работы
- Гора и карта
- Вы и ваша команда
Высокие ожидания
Причина номер один, по которой молодые разработчики останавливаются, заключается в том, что от них не ждут достаточно.
Вы можете почувствовать тенденцию снизить давление на них, чтобы уменьшить стресс, что понятно, но неуместно - люди обычно получают удовольствие от проблемы, если они не видят в последствиях неудачи катастрофические последствия.
Вместо этого вы можете передать словами и действиями следующее сообщение: «Эта работа сложная, но я верю, что вы справитесь с ней».
При разумной поддержке вы можете постепенно увеличивать объем и сложность задач, которые может выполнять ваш разработчик.
Если вы действительно чувствуете, что не можете доверять младшему разработчику более сложную работу, возможно, нужно решить более серьезную проблему. Если да, свяжитесь с нами, и мы вместе разберемся.
Что вы увидите, если что-то пойдет не так: застойный рост, постоянные вопросы о технических деталях, разочарование со стороны разработчика.
Полномочия и ответственность
Возможно, вы работали с неопытными разработчиками, которые жалуются на множество проблем в своем проекте, команде, среде или даже менеджере! Во многих случаях это разумно, но стоит обратить внимание на то, когда люди начнут использовать их, чтобы объяснить, почему им мешают выполнять хорошую работу.
Когда люди приписывают свои собственные неудачи вещам, которые они не могут контролировать, для них неразумно пытаться расти, поэтому их рост останавливается. Как менеджеру важно научить младшего разработчика брать на себя ответственность за собственный успех и дать им возможность преодолевать препятствия в своей среде.
Допустим, ваш разработчик работает над устаревшей кодовой базой без тестов. Они могут сказать: «Я застрял в этом билете на несколько дней, эта кодовая база ужасна, в ней нет тестов и мне не хватает поддержки». - подразумевается, что проблема заключается в кодовой базе и команде, а не в низкой квалификации разработчика в работе с унаследованным кодом.
Вы можете ответить таким сообщением:
«Да, это определенно сложная кодовая база, но я видел хорошую работу от вас, я считаю, что вы подходящий человек для этого билета, и что вы можете это сделать» [большие ожидания]
«Давайте поговорим о том, что вам сложно - я знаю, что вы хорошо пишете тесты, и это одна из причин, по которой вы здесь [ответственность], поэтому давайте найдем способ начать использовать тесты здесь, чтобы помочь с наследием. работа [полномочия]. Фактически, есть книга под названием Эффективная работа с устаревшим кодом, в которой основное внимание уделяется использованию тестов! "
«Я знаю, что может быть непросто обратиться за поддержкой ко мне и к команде, и мы не всегда можем вернуться немедленно, но мы действительно хотим, чтобы вы это сделали! [ответственность] В следующий раз, когда вы не знаете, как это получить, напишите мне, и мы разберемся. [расширение прав и возможностей] »
К концу этого сообщения становится ясно, что и их работа, и их сила - добиться успеха в решении этой задачи при вашей поддержке.
Что вы увидите, если что-то пойдет не так: жалобы, отсутствие прав собственности.
Отказоустойчивая среда
В тот или иной момент все мы совершаем ошибки. Когда это происходит, это может иметь для нас большие или маленькие последствия. Если это имеет небольшие последствия, мы незначительно меняем свое поведение. Если это будет иметь серьезные последствия, мы, вероятно, значительно сократим количество принимаемых нами рисков.
Для младшего разработчика практически любая задача - это риск. Если неудача имеет серьезные последствия, они неохотно берутся за работу, регулярно сверяются с пожилыми людьми и стараются не брать на себя ответственность. Поэтому важно, чтобы последствия сбоя были небольшими или что большие сбои маловероятны, учитывая текущие навыки разработчика.
Это представляет собой своего рода парадокс - как защитить разработчика от последствий неудач, не ставя под угрозу ваши высокие ожидания? Вы также не всегда можете возложить вину на окружающую среду, потому что это снизит чувство ответственности разработчика.
Решение состоит в том, чтобы заметить, что младшие разработчики больше всего беспокоятся об увольнении или потере уважения своей команды. Важно то, что они знают, что вы все еще верите в них, даже когда они терпят поражение.
Вы можете начать со слов и действий: «Все делают ошибки, тратят больше времени на оформление билетов, чем они надеялись, расстраиваются - важно извлечь из этого уроки».
Вы можете пойти еще дальше и явно вознаградить неудачу. Иногда я говорил, что если кто-то регулярно терпит неудачи, значит, он недостаточно сильно нагружает себя. Я часто, когда кто-то застревал на несколько дней из-за сложной проблемы, заметно волновался и объяснял, как хорошо, что у них есть возможность узнать, почему они застряли, и расти на этом опыте.
Так же, как важно не стыдить людей публично за неудачи, не менее важно не стесняться этого. Это говорит о том, что неудача вызывает смущение. Подумайте о том, чтобы открыто говорить о своих ошибках! Вероятно, это были одни из самых сильных моментов роста в вашей карьере.
Что вы увидите, если что-то пойдет не так: разработчики молча терпят неудачу в течение нескольких дней, никому не сообщая об этом, нежелание браться за сложные задачи.
Постоянный поток сложной работы
Вы можете почувствовать облегчение, когда ваш младший разработчик наберет обороты и с легкостью сможет взять на себя определенную категорию задач - тяжелая работа окончена, и вы можете уйти. Боюсь, твоя работа только начинается!
Вызов необходим для роста. В то же время, поскольку некоторые задачи будут слишком сложными для вашего разработчика, и многие задачи будут слишком простыми.
В этом нет ничего удивительного, но для вас возникает сложная задача - попытаться управлять своей командой, чтобы выполнять работу. Также необходимо выполнять простые задачи, а более сложные задачи требуют поддержки, которой у вас может не хватить ресурсов.
В случае с простыми задачами у вас есть отличная возможность, если вы пытаетесь увеличить свою команду. Если сейчас достаточно легкой работы, чтобы поддержать нового сотрудника младшего звена, подумайте о том, чтобы сделать это. Ваш нынешний юниор может принять нового юниора. Если ваша команда полностью укомплектована, подумайте, что потребуется для автоматизации или, по крайней мере, ускорения простых задач - такая работа может создать дополнительную проблему и повысить скорость вашей команды.
В случае предоставления поддержки, когда младший берет на себя более сложные задачи, вы должны взвесить, сколько вы инвестируете в эту поддержку, и отдачу, которую вы получите обратно в виде того, что ваш разработчик теперь может выполнять более сложные задачи. В некоторых случаях вы не сможете сэкономить это старшее время, но в большинстве случаев это хорошее вложение.
Если вы действительно чувствуете, что не можете доверять младшему разработчику более сложную работу, возможно, нужно решить более серьезную проблему. Если да, свяжитесь с нами, и мы вместе разберемся.
Что вы увидите, если что-то пойдет не так: начинающие разработчики скучают, занимают ниши или выполняют сложную, но малоцельную работу, разработчики уходят в течение года или двух.
Гора и карта
То есть: привлекательное место назначения и понимание того, как туда добраться.
Многие работодатели попадают в ловушку, полагая, что разработчиков волнуют в основном технические вопросы, а не стратегия их компании. По моему опыту, это верно только тогда, когда компания не может сообщить о своем видении внутри компании - разработчики возвращаются к заботе только о своих собственных навыках. Поэтому неудивительно, когда им удобно уезжать.
Разработчики, как и все мы, хотят работать каждый день и верят, что то, что они делают, способствует достижению какой-то более широкой цели. Даже если целью является просто зарабатывание денег, вы услышите, как разработчики жалуются на работу, которая, по их мнению, не поможет.
Итак, это гора - неотразимая цель.
Карта - это более чем обычная потребность разработчика понять, как бизнес намеревается достичь своих целей. Им это нужно, потому что разработчики всегда выносят суждения на основе предположений о будущем - нужно ли что-то менять или нет, и кому это нужно будет менять. Если в ближайшие 5 лет бизнес, вероятно, вырастет в Бразилию, будет иметь значение, по сравнению, скажем, с Новой Зеландией (потребуется ли гибкость валюты? Как будет осуществляться перевод? Возможно ли сотрудничество в разных часовых поясах?)
Кого-то, на кого они могут положиться, чтобы рассказать о стратегии разработки программного обеспечения в организации, обо всех системах и о том, как их соединить, а также об их более крупной цели для клиентов, которая поможет им принимать более правильные решения.
Это также помогает им связать разочаровывающие мелочи разработки программного обеспечения с более крупной «горной» целью. Разработчики, которые понимают, почему их работа важна, пишут лучшее программное обеспечение. Иногда можно срезать углы в интересах ускорения вывода на рынок, иногда надежность имеет первостепенное значение - разработчики, которые понимают стратегию, принимают эти микростратегические решения эффективно.
Все это особенно важно для юниоров, потому что их работа непропорционально сложнее, чем для других людей. Им нужно чувствовать мотивацию, потому что им труднее!
Что вы увидите, если что-то пойдет не так: технические решения, которые кажутся оторванными от реальности, зависимость от контекста старших или менеджеров, а также контркультура некачественной работы, оправданная тем, что на самом деле большая разница в любом случае.
Ты и твоя команда
Все вышеперечисленное требует времени и усилий для поддержания. Это начинается с вас.
Хорошо сформированные команды хорошо справляются с этой задачей, но кто-то все равно должен быть рядом, чтобы рассказать им о завышенных ожиданиях, помочь им понять, как они могут нести ответственность за качество своей работы, успокоить их, когда они совершают ошибки, и отстаивать их интересы. за то, что они сталкиваются с трудностями в своей работе.
В Makers мы тратим относительно мало времени на прямую работу с разработчиками - и предоставление слишком большой поддержки со стороны старшего может сформировать зависимость, - но определенное количество времени с опытными разработчиками может изменить ситуацию.
Наличие у ваших опытных разработчиков «дежурства» в любое время имеет очевидные недостатки и может быть не лучшим вариантом для юниоров. Это ставит их в относительно беспомощное положение, когда они просят о помощи, когда считают, что не могут добиться прогресса. Вместо этого подумайте:
- Если вы еще не пользуетесь парой регулярно, выделите один-два дня в неделю для юниоров, чтобы они могли объединиться с более опытными разработчиками. Это позволяет вашим старшим разработчикам планировать подходящую работу и следить за тем, чтобы их не сорвали в другое время.
- «Как бы я это сделал». Назначьте время для группы младших разработчиков, чтобы они встретились с одним или двумя опытными разработчиками, и попросите одного из младших разработчиков принести билет, над которым они недавно работали. Учитывая это, старший может непредвзято продемонстрировать, как они бы подошли к решению проблемы. Это помогает младшим разработчикам осваивать новые методы работы и тренирует их рассудительность.
- Запросы на вытягивание как вопросы. Предложите, чтобы, когда ваши младшие разработчики застряли, вместо того, чтобы переходить, они сделали запрос на вытягивание своей работы, насколько это возможно, и четкое разъяснение своей проблемы. Это может относительно хорошо вписаться в существующий процесс проверки кода и особенно хорошо для распределенных команд. Они могут даже решить свою проблему в процессе объяснения своего вопроса!
Когда младшие разработчики все же застревают, стоит убедиться, что ваша команда не просто решит проблему, но и выяснит, почему они не могут продолжить, и поможет им решить эту проблему. В результате систематического выполнения этого обсуждения будут проводиться более продуктивные обсуждения, а младшие разработчики станут более независимыми.
Что вы увидите, если что-то пойдет не так: разочарование младших разработчиков, неуверенность в том, куда обращаться и как получить поддержку, а также множество прерываний из-за извинений.
