Сыны IT-полка
Как эффективно внедрить в IT-проекты Junior-разработчиков
В настоящий момент существует дефицит разработчиков ПО с опытом от трех лет. Их поиск усложняется, а востребованность для решения ключевых задач – растет. При этом, как показывает опыт, есть большое количество джуниор— (младших) кандидатов с отсутствием или минимальным опытом. На российском рынке не так много компаний, которые готовы их нанимать с целью дальнейшего продвижения до middle— и senior—уровней. О том, как можно эффективно подключать к проектам junior-разработчиков и добиваться значительных результатов, читателям RSpectr рассказал эксперт в разработке программных продуктов Артем Коновалов.
ПОДБОР ПЕРСОНАЛЬНЫХ ЗАДАЧ
Нечасто можно встретить в команде по разработке ПО специалистов класса junior. Это происходит из-за того, что таких разработчиков внедрять достаточно долго и отсутствуют единые методологии их внедрения на рынке. Практика существует только в рамках крупных компаний, где процесс поставлен на поток. Для небольших компаний наиболее распространенная практика сводится к тому, что на местах senior и lead разработчикам дают под крыло начинающих специалистов. А таким менторам, кроме вынужденной опеки, еще и свои задачи нужно выполнять, которых обычно немало. Из-за этого на планирование и выстраивание процессов внедрения просто нет ни сил, ни желания, а менторство может быть пущено на самотек, когда просто скидываются на джуниоров рутинные и несложные задачи, которые не особо помогают последним развиваться.
В ходе моего опыта разработки в коммерческих проектах выработалась методика, которую внедряют и другие компании в свои процессы.
Из результатов могу отметить:
- Время на внедрение сокращается в среднем на 20-30% за счет выстраивания оптимальных процессов и понятного плана внедрения.
- Разгружаются senior-разработчики, за которыми закрепляют новичков, их время на менторство становится более систематизированным, не происходит расфокусировка.
- Разработчики, прошедшие период внедрения по данной методике, потом могут брать в среднем более сложные задачи в работу.
Значительная часть задач для джуниоров являются типовыми, их можно систематизировать и выделить из них основные типы, градировать их по уровню сложности и времени.
Перед наймом такого человека стоит понять, какого уровня задачи вы бы хотели доверять специалисту, и уже с упором на это выстраивать его план персональных задач.
Важно наличие понимания рабочих задач для внедряемого специалиста на ближайшие 6-9 недель
Пример типизации задач для front-end—разработки:
- Добавление/редактирование поля/нескольких полей в существующую форму – 2 ч.
- Добавление модального окна с формой – 8 ч.
- Реализация карточки сущности в режиме просмотра – 8-12 ч.
- Реализация карточки сущности в режиме редактирования – 16 ч.
- Добавление списка сущностей с фильтрами и поиском – 16 ч.
Как видим, расписано достаточно абстрактно, но этого достаточно. Можно также уйти от оценки в часах и перейти на условные обозначения сложности (или объема) задач: s, m, l, xl, xxl.
Нужно постараться, чтобы джуниор-разработчик получил опыт работы со всеми типами описанных задач, включая и нетиповые случаи, сложно поддающиеся типированию. Понятно, что ряд серьезных задач уровня сеньора, в ходе которых могут быть выполнены системные изменения приложения, сложные оптимизации его производительности, не имеет смысла доверять новичку – их стоит опустить на этом этапе. Но будет нелишним описать общие принципы и системный дизайн приложения.
При этом крайне желательно для джуниор-разработчика иметь уже готовый пример решения задач для всех типов. Как правило, в проекте уже есть удачно реализованные примеры всех основных типов задач. Например: добавление списка элементов с фильтром, страница просмотра сущности, модальное окно с формой, добавление новых полей в форму и другое.
Важно к каждому типу задачи приложить пример «коммитов» из GIT (наиболее распространенная система контроля версий) проекта, которые разработчик должен изучить перед тем, как приступать к работе. Если такого примера нет, то перед началом работы стоит обговорить, как разработчик видит реализацию задачи. Лучше, если он попробует схематично нарисовать структуру кода финальной версии (какие файлы, компоненты, функции).
Практику с проектированием задачи перед реализацией стоит оставить, даже если есть пример, но сотрудник реализует задачу подобного типа впервые. Ведь у джуниор-разработчика должна формироваться способность проектирования перед непосредственным началом реализации задачи.
Важно показывать решение в рамках системы, а не изолированно, это приучает изначально мыслить системно
Соответственно, для внедрения подобной методологии должна быть высокая инженерная культура разработки в команде. К примеру, в рамках одного «коммита» должна решаться конкретная задача, с понятным описанием «коммита» и номером задачи в трекере задач. Так можно по каждому «коммиту» исследовать реализованную в рамках него задачу, ее путь от сбора бизнес-требований до конечной постановки задач. При необходимости ознакомиться и со связанными с ней задачами, реализуемыми другими специалистами: дизайнерами, аналитиками, разработчиками другого типа.
Важным элементом при проектировании является оценка, что может быть переиспользовано в рамках текущего проекта, не должны изобретаться новые велосипеды, если в рамках системы уже есть набор функций, классов, библиотек.
Кроме того, требуется подготовить общую информацию о проекте, основных сущностях и бизнес-логике, так как зачастую процессы весьма специфичны и требуется разбираться в деталях.
ПРОЦЕСС РАБОТЫ С МЕНТОРОМ
Стоит понимать, что если ментор закреплен за джуниором, то это тоже отнимает у него достаточно значительное количество времени, и это нужно учитывать. Ведь это снимает определенный фокус с его собственных задач, которых немало. Поэтому важно брать во внимание моральное состояние ментора и беречь его от выгорания, которое может возникнуть оттого, что, кроме собственного восьмичасового рабочего дня, он еще постоянно отвлекается от собственных задач, теряет фокус и решает проблемы джуниора. Тем самым он может перерабатывать и не успевать полноценно выполнять собственные задачи.
Необходимо разграничить время, в ходе которого джуниор может беспокоить ментора, ведь он должен пытаться и самостоятельно найти решение, а также анализировать готовые решения из проекта.
К примеру, с утра на старте рабочего дня джуниор-разработчик описывает свои планы на день, как он видит реализацию задач, какие возможны трудности и вопросы, получая ответы и предложения от ментора. В дальнейшем в течение дня, при необходимости, можно выделить второй блок, когда ментор проверяет код выполненных задач (если таковые есть) и дает комментарии по нему. Если необходимо, то в формате звонка, лучше, если время будет определено заранее.
При этом код-ревью является общей практикой, а не только для кода, реализованного джуниором. Но на этапе внедрения этому периоду стоит уделить особое внимание и первое время возможно делать совместно, разбирая ошибки. При необходимости отправлять ссылки на устоявшиеся паттерны проектирования, статьи, видео или литературу, которые могли бы закрыть пробелы в знаниях.
Как правило, этого достаточно, исключением являются лишь первые пару недель, когда настраивается окружение, идет вникание в проект, в бизнес-логику и могут быть дополнительные звонки.
Если джуниор приходит за советом к ментору, ему нужно постараться предложить варианты путей решения проблемы, даже если он считает, что они не оптимальны. Требуется развивать собственное мышление и совместно разбирать предложенные варианты, учиться самостоятельно находить пути решения и дорабатывать их.
Минимум раз в две недели, а первое время и еженедельно, нужно разбирать результаты, вести оценку прогресса и подбадривать обучающегося специалиста, подмечать его прогресс и успехи.
ВЫДЕРЖИВАНИЕ ОБЩЕГО СТИЛЯ ПРОЕКТА
В коммерческих приложениях над проектом обычно работает команда инженеров и требуется соблюдать общий стиль приложения. Это упрощает поддержку текущей кодовой базы и делает интуитивно понятным любой раздел проекта без детального изучения.
Опытные разработчики могут и сами определить стиль кода и принципы построения приложений, но новички не всегда мыслят системно и часто недооценивают важность однообразности проекта, вставляя собственные «велосипеды» или именуя файлы/переменные/функции отлично от остального проекта.
Для этого требуется описать оговоренный стиль кода проекта, и обязательным условием передачи задачи начинающим разработчиком на код-ревью должна быть сверка, подходят его изменения под требования оформления или нет. Правила форматирования кода, последовательности импортов и другое. Можно настроить при помощи линтеров, но подход к разбивке функций/классов на более мелкие элементы и наименования типовых файлов должны быть определены заранее и также проверяться по чек-листу.
К примеру, при реализации на TypeScript выносить все типы компонента в отдельный файл types.ts или все запросы выносить в отдельный файл requests.ts.
Правила оформления «коммитов», веток в GIT, а также все процессы работы с версиями кода в этой системе контроля версий (или в другой, если в вашей команде другой вариант) должны быть описаны.
ТРЕНИНГ ПО РАБОТЕ СО СРЕДСТВАМИ РАЗРАБОТКИ И ОКРУЖЕНИЕМ
Многие недооценивают важность такого тренинга в проекте. Используемый софт и окружение везде разные, а многие думают, что все и так интуитивно понятно и в этом легко разобраться. Поскольку опытные специалисты выполняют все это на автомате после многих лет работы. А как показывает практика, джуниоры часто даже не знают о многих крайне полезных функциях в средствах разработки, баг-трекерах и другом. От поиска по проекту по регулярному выражению, использования локальной истории в IDE, удобной работы с контролем работы версий из IDE до сложного поиска задачи по баг-трекеру. Все эти вещи далеко не очевидны для начинающего в коммерческой разработке специалиста, у которого за плечами только домашние проекты. Понимание этих вещей значительно ускоряет ход обучения и саму работу такого специалиста.
Так как все используют разный софт, то рекомендую собрать список используемого у вас и составить рекомендации по эффективному применению именно вашего, оформив это в единый тренинг. Как это сделать:
- В ходе работы инженеры вашей компании могут выписывать основные функции, горячие клавиши и неочевидный на первый взгляд функционал. А также удобные, на их взгляд, конфигурации под проект.
- Эти заметки спустя две-три недели анализируются, и выделяются основные подходы к использованию софта, а также пути оптимизации рутинных процессов.
- Все это объединяется в документ, на основе которого можно записать видеокурс и предоставлять доступ к нему для сотрудников в процессе онбординга.
Крайне рекомендую сделать упор на использование IDE, так как это наиболее часто используемое ПО и от эффективности его применения зависит эффективность работы. Пример раскрываемых в тренинге моментов по работе с IDE:
- Весь процесс работы с GIT:
- Работа с ветками и тегами.
- Работа с GIT логом.
- Оформление «коммитов».
- Отслеживание незакоммиченных изменений, работа с ними.
- Основные часто используемые команды, такие как: pull, push, fetch, merge, rebase, cherry-pick и др.
- Работа с локальной историей.
- Методы поиска и замены текста по документу, разделу и проекту целиком.
- Конфигурации по форматированию кода и шаблоны.
Это также касается использования баг-трекера (Jira, clickup и др.), платформы для хранения документации по проекту (confluence, notion и др.) и пр.
ЗАКЛЮЧЕНИЕ
Резюмируя, хочется обратить внимание, что данная методика применима к командам с высоким инженерным уровнем и малоэффективна, когда все процессы пущены на самотек, так как базируется на описанных процессах. Но путь к внедрению данной методики также поможет систематизировать ваши процессы, что в целом позитивно скажется на компании и станет первым шагом в борьбе с хаосом. Рекомендации, описанные в методике, достаточно просты и понятны, но помогают построить эффективный процесс внедрения джуниор-разработчиков и закладывают в них серьезную базу для дальнейшего роста. А также помогают сократить этап по внедрению такого специалиста и разгрузить его ментора, систематизировав процесс самого менторинга.
Автор: Артем Коновалов
