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