Привет! Меня зовут Андрей, я бэкенд-тимлид в KTS. 

Когда у вас в компании появляются стажёры или джуны, на первых порах они погружаются в процессы, подтягивают хард-скилы и знакомятся с командой. Стажёр постепенно становится джуном. Чтобы продолжить рост и стать мидлом, ему необходимы начальные навыки проектирования. Проблема в том, что часто взять эти навыки просто негде.

В статье расскажу про методику обучения проектированию в нашей компании.

Содержание:

• Задачи джунов и стажёров после появления в компании

• Что должен уметь джун, чтобы стать мидлом

• Проблема нехватки навыков проектирования

• Варианты решения

• Наша методика:

  • Постановка и описание задачи

  • Подготовка решения

  • Сдача готового решения

• В чём ещё польза таких тренировок

• Советы при внедрении методики

• Отзывы джунов, выполнявших задания

• Заключение: пайплайн обучения

Задачи джунов и стажёров после появления в компании

На первых порах новичок занимается погружением: знакомится с инфраструктурой, CI/CD и экосистемными приложениями, потихоньку начинает вливаться в коллектив и получает понятные задачи. Вместе с наставником он принимает участие в дейли-встречах, получает задачи и подробно разбирает их, тоже с наставником: мы проговариваем весь цикл, как сделать и как протестировать.

На этом уровне об опыте именно в проектировании речь не идёт. Стажёр просто реализовывает полностью оговоренное решение.

В какой-то момент стажёр становится уверенным джуном, который хочет расти в сторону мидла. И тут мы сталкиваемся с проблемой.

Что должен уметь джун, чтобы стать мидлом

Скоп проблем мидл-разработчика шире, чем у джуна. Джун выполняет понятные задачи с небольшой долей неопределённости. Мидл уже немного умеет проектировать.

Вот характеристики грейда «Мидл 1» из нашей матрицы грейдов:

• Участвует в обсуждении реализации блоков функционала

• Зона влияния: часть проекта / небольшой проект

• Задачи по разработке: может решить практически любую продуктовую задачу (фича / фикс багов), может быть наставником

• Навык проектирования: проектирует простые задачи самостоятельно. Участвует в проектировании сложных задач.

Проблема нехватки навыка проектирования

На этом месте у джуна может появиться ступор. Раньше ему нужно было решать только понятные задачи. А чтобы стать мидлом, джун уже должен уметь что-то проектировать. Получается, что нужно сделать прыжок от юнлинга до джедая: в траектории развития есть точки: «Джун» → «Мидл», но между ними не хватает промежуточного этапа «Джун, который учится проектировать».

При этом конкретно в нашей компании есть дополнительное требование. У нас работают разные команды с разной спецификой. Например, может быть один большой длительный проект, как «Личный кабинет сотрудника Пятёрочки», а может быть много небольших — как в отделе рекламных спецпроектов. В каждом направлении есть какие-то скилы, которым уделяется больше внимания.

Вывод: нужен этап, когда человек может получить опыт проектирования.

К этому процессу есть дополнительные требования:

• джун не должен набить серьёзных шишек, чтобы не растерять мотивацию

• джун не должен подорвать эффективность рабочих проектов, пока набирается опыта

• желательно, чтобы при обучении джун закрывал пробелы, которые неизбежно возникают из-за разной специфики работы над проектами

Варианты решения

Парное проектирование

Плюсы

• Наставничество. Джун работает в паре с опытным специалистом, что позволяет быстро учиться на практических примерах.

• Обзор различных подходов. Джун может увидеть разные стили и методы проектирования, применяемые в командах.

• Качество. Решения, принятые вдвоём, часто более обдуманные.

Минусы

• Требует координации. Нужно согласовывать рабочие графики и обеспечивать постоянное взаимодействие участников. Поэтому часто проводить такое не получится.

• Стресс. Для джуна может быть сложно представить свою работу на ревью перед опытными специалистами.

Самостоятельно обучение по курсам и книгам

Плюсы

• Стандартизация. Все джуны получают одинаковые знания и навыки.

• Масштабируемость. Одни и те же курсы можно использовать для обучения большого числа сотрудников.

• Гибкость. Джуны могут изучать материалы в удобное для них время и темпе.

• Большой выбор ресурсов. Существует множество книг, курсов и статей по проектированию.

Минусы

• Менее персонализированный подход. Не учитываются индивидуальные нужды каждого стажёра.

• Отсутствие практики. Теоретические знания без практики могут быть неэффективными.

• Риск изучения устаревших или нерелевантных материалов. Не все доступные ресурсы актуальны для конкретной компании.

• Невозможно убедиться, что материал хорошо усвоен.

Наша методика

Мы в компании используем подход учебного проектирования. В результате сотрудник получает необходимую насмотренность, повышает грейд и дальше развивается в этом направлении самостоятельно.

1. Постановка и описание задачи

Берём максимально понятные и при этом интересные платформы. Делаем скриншоты. В задании должны быть загвоздки и подводные камешки: важно, чтобы стажёр поломал голову над реализацией, в этом вся польза. 

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

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

Любая задача на разработку по макетам примерно так и выглядит: дизайнер нарисовал картинки, а бэкенд и фронтенд должны вместе посидеть, подумать и сделать «как на картинке».

Примеры задач с описанием

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

Для примера возьмём приложение для изучения иностранного языка.

Экран 1: Настройка тренажёра 

Описание 

Настройка своих занятий, где пользователь выставляет норму-челлендж в N тренировок в день. Тренировкой считается попытка выполнить N заданий по словам. 

Параметры тренировок:

• Количество тренировок в день

• Длительность тренировок

• Типы упражнений, которые будут в тренировке: 

  • написание

  • аудирование (прослушать аудиозапись и выбрать верный перевод)

  • выбор правильного изображения

  • проверка произношения слова (соответствие эталону)

• Наличие неправильных глаголов

Подсказки-вопросы студенту:

• Как хранить специфичные настройки приложения с возможностью будущих доработок?

• На что влияет настройка тренажёра (данные в БД в предложенной схеме), и как это отражается на текущем числе тренировок, которые надо сделать сегодня?

• В настройках указываются абстрактные параметры, понятные и удобные пользователю. Действительно ли удобно так хранить параметры?

• Нужно ли хранить историю изменения этих настроек?

Заметки проверяющему:

• Хранить данные нужно так, чтобы при каждой смене дизайна не пришлось менять API. Поэтому это должно быть число слов, количество упражнений

• Часто джуны, которые учатся проектировать, хотят приводить всё к одной нормальной форме. В случае настроек смело можно пользоваться JSON-полями в БД

• Обсудить структуру JSON-поля, чтобы типы тренировок и остальные будущие доработки можно было настраивать действительно гибко 

Экраны 2-3: Статистика

Описание 

Активность занятий пользователя:

• Подробная статистика тренировок за неделю, физические 7 дней

• Агрегированная статистика за последние N месяцев

Подсказки-вопросы студенту:

• Как хранить эту статистику?

• Как обрабатывать галочку о выполнении всех заданий?

• Представьте, сколько места будет занимать статистика по всем пользователям, которые каждый день учат слова. Какие оптимизации можно предложить, основываясь на этих макетах?

• Обратите внимание на то, что подробная статистика по неделям показывает количество делений: сколько тренировок пользователь планировал пройти и сколько действительно прошёл

Заметки проверяющему:

• Рассказать про snapshot. Можно хранить подробную статистику за крайний месяц, а всё остальное агрегировать фоновыми задачами, сохранять слепки и удалять лишние записи

• Спросить у подопечного, как можно сделать дополнительную подписку, с которой можно увидеть более подробную стату. Идея в том, что фоновые задачи не будут удалять записи пользователей, которые платят за это деньги

• Нужно добавить требование, что в статистике за неделю нужно видеть план по тренировкам в определённый день недели. Т.е. в зависимости от настроек количество делений в каждый день недели должно меняться

• Нужно подвести к выводу, что нужно хранить историю изменения настроек тренажёра

• Предложения о флажке в API «все задания выполнены» сразу отметаем. Если данные не отображаются (6/6) заданий, это не значит, что фронт не справится с отрисовкой компонента с условием

2. Подготовка решения

Несколько экранов-задач вместе составляют один большой блок. 

Подопечному отводится неделя на то, чтобы подумать над его полной реализацией. На выходе должна получиться схема в Miro или Draw.io и документация в Swagger / Postman.

Процесс такого учебного проектирования не быстрый: человеку нужно разобраться и как следует подумать. Работа состоит только в проектировании. Мы останавливаемся на том, чтобы вычленить все сущности, прописать связи, запросы, продумать, как их оптимизировать, поискать паттерны для реализации той или иной механики. В итоге джун сделал API, подумал, как он должен выглядеть и как запросить картинки с фронтенда, чтобы это выглядело достаточно качественно.

Реализация подобного решения вместе с пет-проектом заняла бы кучу времени. Нас интересует именно верхнеуровневое проектирование.

Когда джун-подопечный разобрался с одним блоком задач, можно выдать следующий. Например, выше мы взяли механики тренажёра слов — это будет первой итерацией. После этого возьмём какой-то другой сервис. Будем докручивать микросервисную архитектуру, единую авторизацию сервисов, усложнять задачу и добавлять интересные механики. Так от маленьких схем это может стать большой системой и быть тренировкой уже не джуна, а мидла первого или второго уровня.

3. Сдача готового решения

Для сдачи мы назначаем личную встречу.

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

Даю подопечному самому додуматься до правильного ответа. Цель таких разговоров с подопечными — чтобы они самостоятельно дошли до какой-то проблемы. Не нужно говорить напрямую, что именно не так. Например, на код-ревью мы сразу говорим — вот здесь ошибка, здесь неоптимально. Тогда человек просто правит ошибки, возможно, без понимания.

До каждой проблемы в решении нужно дойти окольными путями, чтобы учащийся сам осознал её, придумал решение и принёс исправление на следующей итерации.

Обычно со 2-й итерации решение уже выглядит хорошо, и его не стыдно было бы передать в разработку при проектировании реальной системы.

Важно серьезно отнестись к проверке и каверзным вопросам. Если такое мероприятие провести просто для галочки, разработчик может переоценить свои силы вместе с ментором и при первой же ответственной задаче сильно облажаться.

В ходе реальной работы всегда попадаются подводные камни. При учебном проектировании ментор должен создать эти камни сам: подопечный предлагает решение, а ментор выступает в роли менеджера и моделирует такие ситуации, когда предложенное решение перестаёт быть хорошим. Тогда нужно откатиться назад и перепроектировать сервис, чтобы решить проблему, но не увеличивать энергозатраты.

Роль ментора — задать все каверзные вопросы, чтобы максимально проверить подопечного на прочность. Если джун-стажёр просто набросал схему — скорее всего, он нигде не ломал голову и мало что усвоил. Чем больше вы его подловите, тем лучше.

---

Ниже — пример проверки подопечного по задаче проектирования тренажёра слов. Все остальные этапы проверяются и проговариваются схожим образом.

Экран 1, настройка тренировок для изучения слов

Текущее решение. Чтобы хранить количество тренировок и типы зданий, используется many-to-many.

Проблема: В настройках тренажёра стоят три варианта с минутами, но на самом деле при работе с БД этот параметр ничем не поможет. Внутри минут — всегда количество слов, которое им соответствует: 

• 3 минуты — 10 слов

• 5 минут — 16 слов

• 10 минут — 33 слова.

Бэкенд должен отображать глобальную ситуацию и состояние пользователя, а не визуальный интерфейс. 

Если формат типа заданий поменяется, и вместо минут будут повторения, то с каждым редизайном придётся переделывать модель. 

Решение: Т.к. тренировка — это всегда какое-то количество слов, именно с ним мы и работаем в БД. Тогда неважно, какие данные отправлять, все внешние изменения будут происходить на фронтенде.

Поэтому размер тренировки на бэкенде всегда равен количеству слов.

В чём ещё польза таких тренировок

Если человек начинает хорошо справляться с такими заданиями, в какой-то момент он точно научится проектировать.

А вот что ещё дают подобные тренировки.

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

Познакомитесь с новыми технологиями. За свою карьеру вас, возможно, уже не раз переводили на новый проект, и вы тоже сталкивались со ступором перед новыми неизвестными задачами. Так же и джун впервые сталкивается с задачами на проектирование. Тренировочный кейс закроет проблему «чистого листа», и вы будете знать, куда двигаться.

Проверите познания в широком диапазоне. Это своеобразный скрининг. Например, вы думали, что ваш подопечный уже хорошо справляется, но возможности широко проверить скилы не было. Кейсы тренировочного проектирования комплексные и объёмные, которые подсветят то, чего не хватает разработчику. 

Сократите цену ошибок. Все принимали неправильные решения, из-за которых срывались сроки проектов или появлялись дополнительные проблемы с бюджетом. Тренировочное проектирование позволяет уменьшить эти потери. Всё, что ментор разберёт со своим подопечным на таких заданиях, учащийся сохранит в память. Он уже не будет совершать такие же ошибки, будет иметь представление о вещах, которые ещё не проектировал в реальных условиях.

Научитесь отстаивать решение. Бэкендер может получить задание от менеджера вида: «Нужно, чтобы всё приходило за один запрос». Джун должен сам разобраться, где хорошо пойти на уступки, где нужно подумать, а где вообще нельзя идти на компромисс, потому что это решение сломает систему при масштабировании.

В моменте проектирования API разговор про всё это обязательно заходит, и сотрудник будет знать больше кейсов, что можно делать, а что нельзя.

Советы при внедрении методики

Встречи с наставником

Если в вашей компании тоже развита культура наставничества, то можно постепенно внедрить подобные активности через встречи менторов и подопечных. Например, если на встречах нет чётких целей, можно посмотреть разные сервисы и попробовать для начала вместе разобрать некоторые фрагменты. Если дело пойдёт, дальше можно немного расширить задание.

Тренировочное проектирование в других направлениях

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

Отзывы джунов, выполнявших задание

Дмитрий Долинский, бэкенд-разработчик KTS

На этой практике я отработал умение проектировать и прокачал другие навыки:

• Лучше познакомился с концепцией индексов в базе данных: узнал о необходимости индексирования foreign key и разобрался, как готовые решения типа Django ORM снимают большую часть работы с разработчика

• На примере увидел применение денормализации

• Понял, как удобно хранить неструктурированные данные в базе в формате JSON

• Ближе познакомился с принципами работы технологии websocket при проектировании чата. Понял, что это не так просто, как казалось на первый взгляд: необходимо обдумывать такие моменты, как отправку сообщений при обрыве соединения и получение сообщения при восстановлении соединений

Дмитрий Ивахненко, бэкенд-разработчик KTS

Я считаю, что любое обучение происходит эффективнее с наставником, и проектирование — не исключение. Ментор акцентирует внимание на неочевидных моментах, предлагает альтернативы. Благодаря тому, что процесс разбивается на несколько итераций и проводится в формате one-to-one, есть возможность спокойно обдумать подсвеченные ментором проблемы или ответить на поставленные вопросы. Думаю, что это уникальный опыт и хороший способ отвлечься от рутинных задач и багфиксов.

В чем ёще может быть интерес у джунов:

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

• Безопасно. Людей очень расслабляет, что эта новая архитектурная ответственность не свалится на их плечи уже завтра. Это тестовый режим, и все хотят попробовать эту серьёзную нагрузку на тренажёре

• Интересно. Многие говорили, что некоторые механики они никогда не видели. Например, можно зайти в Notion, посмотреть API и текущее решение команды, поискать собственное решение. Такие челендж-задачи могут быть интереснее, чем задачи на проектах

Заключение: пайплайн обучения

1. Ментор выдает подопечному часть выделенных в один блок экранов на проектирование. Пример задач

2. Подопечный выполняет задачу в соответствие с требованиями и подсказками

3. После каждого блока проводится ревью, на котором подопечный рассказывает о своей реализации и защищает её. Все недочёты обсуждаются и фиксируются

4. Ментор даёт обратную связь по итогам созвона. Если были допущены тривиальные или недопустимые для грейда ошибки — например, неверно реализованный M2M — можно отдельно указать на это. Но удачные, хорошие решения тоже нужно подчеркнуть

5. Подопечный исправляет недочёты. Эта часть проходит без ревью, потому что вы это уже проговорили

6. Ментор выдаёт новый блок приложения. Задача аналогичная. Cо второй итерации можно начинать обсуждать микросервисную архитектуру. В процессе проектирования можно изменять ранее проверенные схемы в целях оптимизации

7. Повторение пунктов 3-5

8. Сдача

---

Другие наши статьи по бэкенду и асинхронному программированию для начинающих:

• Цикл статей «Первые шаги в aiohttp»: пишем первое hello-world-приложение, подключаем базу данных, выкладываем проект в Интернет

• Визуализация 5 алгоритмов сортировки на Python

• Разбираемся в асинхронности: где полезно, а где — нет?

Другие наши статьи по бэкенду и асинхронному программированию для продвинутого уровня:

• Пишем свой Google, или асинхронный краулер с rate limits на Python

• Пишем асинхронного Телеграм-бота

• Пишем Websocket-сервер для геолокации на asyncio