Как мы в «Девман» автоматизировали процессы и разработали собственную систему документации

Привет, меня зовут Евгений Евсеев, и я основатель школы программирования «Девман». Я — программист, занимаюсь коммерческой разработкой больше 16 лет — всю свою сознательную жизнь.

Бытует мнение, что EdTech-компании — это технологические компании, в которых программисты создают крутые веб-сервисы. Но на самом деле в EdTech слово technology означает не столько цифровизацию процессов, сколько способность обучать чему-то, что раньше считалось невозможным.

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

При массовом обучении преподаватель занимается большим количеством учеников разом. И образовательные технологии на нашем IT-рынке недалеко ушли от этого формата: преподаватель даёт массив теоретической информации студентам и вынужден проверять огромный объем работ, постоянно отвечать на вопросы. Автоматизация процесса обычно сводится к видеолекциям и песочнице формата: «Напишите код и прогоните его через автотесты».

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

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

На одно ревью может приходиться до 20 ответов, как улучшить код. Нередко приходится проводить ревью на большие работы в тысячу строк кода, это долго и сложно. Поэтому мы создали специальный интерфейс, который позволяет написать большое и подробное ревью, потратив всего лишь от 10 до 30 минут. Даже в командах, которые проводят ревью в процессе коммерческой разработки, таких показателей не бывает, потому что регулярно делать ревью 1000 строк кода и предлагать 20 правок-улучшений с объяснениями — нереально.

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

Так выглядит автоматизация предложений по улучшению кода в едином интерфейсе

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

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

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

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

Мы построили целую внутреннюю экосистему. Сервисы автоматизации обучения языку Python — это не один сайт, а пять полноценных сайтов, десять микросервисов, несколько чат-ботов и множество программных продуктов, которые хитро взаимодействуют между собой. Мы создали их самостоятельно, чтобы работать эффективно на продвинутых технологиях. У нас задействованы Python, Django, асинхронный Python, Docker, Kubernetes, Terraform, Яндекс.Облако.

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

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

Это наша собственная разработка, которая называется Product Flow. Она позволяет документировать требования к продукту — ТЗ. Но при этом делать это не в виде массива текста, а в формате специального документа, адаптированного под быстрый поиск и точечные быстрые правки. В нём можно менять один фрагмент независимо от других и быстро находить ту часть, которая нужна здесь и сейчас. В этот продукт встроен механизм UX-тестирования. То есть такое ТЗ — набор юзабилити-тестов для программного продукта, описывающих, как продукт должен себя вести.

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

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

На этот продукт уже переведено всё управление разработкой. Мы используем Product Flow ещё на этапе сбора требований, проектирования будущего продукта, разработки дизайна. Он используется и в маркетинге, и в продажах. Есть и планы по переводу учебных продуктов на Product Flow. Это поможет будущим программистам понимать, что и зачем они делают, учиться смотреть на продукт глазами пользователя, тестировать не только функциональность, но и удобство.

А что еще нужно улучшить или автоматизировать в онлайн-обучении программированию? Ждем ваших идей и мыслей на этот счет. А попробовать эти и другие фишки нашего курса вы сможете уже сейчас: записавшись на пробную неделю нашего курса Python-разработки.