Сыны IT-полка
IT / Статьи
кадры экспертная колонка
14.10.2022

Сыны 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 и др.) и пр.

ЗАКЛЮЧЕНИЕ

Резюмируя, хочется обратить внимание, что данная методика применима к командам с высоким инженерным уровнем и малоэффективна, когда все процессы пущены на самотек, так как базируется на описанных процессах. Но путь к внедрению данной методики также поможет систематизировать ваши процессы, что в целом позитивно скажется на компании и станет первым шагом в борьбе с хаосом. Рекомендации, описанные в методике, достаточно просты и понятны, но помогают построить эффективный процесс внедрения джуниор-разработчиков и закладывают в них серьезную базу для дальнейшего роста. А также помогают сократить этап по внедрению такого специалиста и разгрузить его ментора, систематизировав процесс самого менторинга.

Автор: Артем Коновалов

Изображение: RSpectr, Adobe Stock

Еще по теме

В России создается умная среда подготовки правовых документов

Как повысить эффективность отрасли углеводородов за счет digital-решений

Особенности экспорта российских IT-решений в 2022 году

Поможет ли маркировка дипфейков защите персональных данных россиян

Методы борьбы с уязвимостями в системах лояльности и в процессах покупки

Российские высокие технологии проникли во все сферы экономики, но нуждаются в данных для развития

О трендах и перспективах цифровизации территорий России

В России хотят создать Совет по программно-аппаратным комплексам

Как избежать провалов в бизнесе при внедрении IТ-решений

Поможет ли перевод сайтов СМИ в публичные облака их кибербезопасности

Как проходит импортозамещение на рынке автономного транспорта в России

IT-отрасль ждет решения о господдержке экспорта ПО

Чего ждет IT-отрасль от эксперимента по использованию открытого ПО

Топ-5 актуальных запросов от пользователей российских BI-систем

Как совместить Bug Bounty и критически важные государственные ресурсы