Когда вы опытный программист и вам вручили джуна на обучение (или даже может быть несколько джунов), первое, что вам придет в голову: я не хочу, у меня куча своей работы… И так далее и тому подобное. Я вас отлично в этом понимаю. Возиться с начинающими разработчиками работа тяжелая и, чаще всего, не благодарная. Но вы должны понимать, что работа с junior в первую очередь выгодно для вас.
Повышение ваших hard skills
Человек лучше всего запоминает информацию, когда он кому-то ее объясняет. Когда вы будете объяснять суть своей работы другому человеку, вы наращиваете свои hard skills. Трудно придумать, чем еще можно так эффективно повысить свой уровень.
И чем лучше вы можете объяснить, тем лучше вы сами все понимаете. Это как в поговорке: если ты что-то не можешь объяснить шестилетнему ребенку — ты сам этого не понимаешь. С обучением программистов аналогично. Для того чтобы объяснить что-то сложное простыми словами, нужно самому понимать это досконально. Только в этом случае вы можете выделить самое важное и сформулировать суть простыми словами.
Итого. Когда вы учите других программистов, вы сами растете как программист.
Повышение soft skills
Здесь все очевидно. Вы учитесь общаться с другим человеком, учитесь воспринимать информацию и получать фидбек. Вы учитесь доступно формулировать свои мысли. У вас может быть прекрасное понимание предметной области, но если вы ни разу все это не проговаривали, то обучение джуна будет отличным способом научиться доносить информацию. Вы научитесь легко и красиво рассказывать сложные темы и потом вам будет легко доносить свою мысль на митингах. Это же поможет, если дальше вы решите идти в сторону менеджмента.
Итого. Обучая джунов, вы прокачиваете свои навыки легко излагать информацию и доносить свою мысль.
Навыки работы с командой
Если вы еще не являетесь тим лидом, а джунов обычно поручают кому-то помладше, то обучение джуна как раз является первой ступенькой управления командой. Вы учитесь, как использовать сильные стороны вашей команды и как сделать так, чтобы слабые стороны не били по результату работы (а в данном случае ваша команда — джун на вашем попечении).
После опыта работы с джунами вы можете идти к руководителю и просить повысить вас до тим лида. Я вас уверяю, что человек, который хорошо себя зарекомендовал в качестве ментора будет одной из первых кандидатур на повышение до тим лида. Или до проджект менеджера, если вы решили расти в эту сторону.
Кроме того, таким образом вы заработаете авторитет у своих коллег. Не только у джунов, а тех, кто будет сидеть рядом и слышать, как вы рассказываете про разные нюансы.
Итого. Если вы хотите расти в сторону управления командой или проектами, то обучение джунов является отличной первой ступенью к вашей цели.
Как строится работа с джуном
В большинстве случаев джуны, которые к вам пришли, совсем не дураки. Они освоили базовые знания по вашей специальности, они прошли все этапы собеседования, а значит с ними можно работать. Вы можете положиться на них во многих отношениях. С другой стороны, полностью положиться вы на них не можете. Тут нужна ваша мудрость, которая вам подскажет, что можно поручить джуну, в чем он справится сам, где нужно подставить плечо, а что лучше сделать самостоятельно, просто показав, как это делается.
Еще один важный аспект при обучении джунов — это дидактика. Это выстраивание последовательности того, что вы должны объяснить человеку. Я советую строить объяснения следующим образом.
Этап 1.
Как только вам поручили джуна, проведите ему коротенькую (до часа) лекцию. Скажите ему название вашего проекта, расскажите о предметной области проекта, о чем он, какую роль в компании выполняет и для чего он нужен. Расскажите, с какими системами вы интегрируетесь. Ознакомьте с основными терминами и аббревиатурами, которые вы используете в вашей системе. Потому что если вы этого не сделаете, у человека будет полный хаос в голове. Вы будете говорить какие-то аббревиатуры или термины, которые человеку не понятны. Вы также должны четко дать понять новичку, где он находится, какая его роль в этом и какая цель проекта.
Этап 2.
После того как вы рассказали про проектную область, можете садиться за IDE и показать, из каких модулей состоит проект и все их особенности. Также рассказываете о принятой в команде инженерной практике. Здесь у нас Dev Server, здесь staging, тут Continuous Integration, коммитимся в такие то ветки, они создаются под то-то, и так далее. Все эти аспекты нужно проговорить.
Я бы советовал весь этот инструктаж поместить в один день. Да, этот день полностью выпадет из вашего рабочего графика. Или же можно разделить на два дня, параллельно давая джуну читать документацию по проекту. Когда вы будете докладывать на статус-митинге, так и скажите, что вы проводили первоначальный инструктаж с джуном. Закон Брукса никто не отменял.
* Закон Брукса: добавление человека в проект, который находится в критической стадии, не ускоряет работу над проектом, а замедляет.
Если руководство приняло решение о расширении штата, то оно должно понимать, что когда в команду добавляют нового человека, команда начинает работать медленнее. Потому что человека нужно ввести в курс, нужно обучить, нужно за ним следить, соответственно, не работать самому.
Если руководство скажет, мол зачем ты тратишь столько времени, зачем все эти вводные лекции, тогда просто откажитесь от джуна, пусть его учит кто-то другой, кто сможет это сделать без предоставления ему основных сведений о проекте. Вы не можете одновременно учить и делать свою работу.
Еще несколько соображений
Будьте человеком. Если человек хуже вас что-то знает, это не значит, что он хуже вас как человек. Если вы видите, что вы категорически не совместимы с новичком, он вам очень не нравится, поговорите об этом со своим тим лидом, попросите чтобы джуна поменторил кто-то другой. Желательно все это тоже сделать вежливо и по человечески. Это нормально, не все люди подходят друг другу. Переступать через себя и работать с человеком, который вам не нравится, не нужно.
Будьте ответственным. Если вы сказали, что у вас сегодня лекция в три, то значит в три вы берете свой ноут и идете в переговорку рассказывать то, что обещали. Многие опытные разработчики считают, что когда перед вами джун, можно сильно не заморачиваться, ну опоздали, пусть подождет. Так вот, важно быть ответственным со всеми коллегами, вне зависимости от их должности.
Вводите человека в работу постепенно. У новичка нет столько опыта, сколько у вас, плюс он не работал на вашем проекте. Естественно, что он очень многого не знает и не понимает. Пусть он сделает первое задание при вас, что бы если он застрял — вы подсказывали что делать. Но не нужно вырывать у него клавиатуру и делать все самостоятельно. Дайте понять своему джуну, что если он что-то не понимает, он может и должен задавать вопросы.
Помните, если человек что-то не понимает — это не его вина, а ваша. Значит вы плохо объясняете. Подумайте, как объяснить иначе. Подумайте, что вы могли упустить из объяснений, потому что вам показалось это естественным (а для человека это может быть не естественно).
Самый лучший способ поддерживать свой авторитет среди команды — не бояться признать свою ошибку. Если вы допустили ошибку и не можете ее признать, пытаетесь ее замести под ковер, оправдаться — ваш авторитет упадет на дно. А вот если вы открыто признали ошибку — это вызывает у людей уважение.
Всегда ваш Сергей Немчинский
А как строите работу с джунами вы? Поделитесь своими лайфхаками в комментариях.
Добавить комментарий