Cистема управления курсами
Как я с нуля спроектировал систему, которая убрала ручной перенос данных из процесса производства курсов
Экономия:
до 4 200 000 руб/год
О проекте
Контекст
Команда вела программы курсов в Google-таблицах и вручную переносила их в админку. Каждая правка требовала повторного переноса, и ошибки доходили до студента. Я спроектировал систему, в которой методист и координатор работают с программой напрямую, без ручного переноса и дублирующих документов. По предварительной оценке, система экономит 1,8–4,2 млн ₽ в год на ручной синхронизации данных
До внедрения системы
Контекст и бизнес-задача
Курс собирает много людей. Методист готовит программу, координатор переносит её в админку, и всё, что там настроено, студент видит у себя в кабинете: на сайте и в приложении. Любая правка запускает перенос заново. Ошибка при переносе сразу оказывается у студента на экране
Проблема пользователя и инсайты
Команда работала в Google-таблицах. Методист и координатор вели раздельные файлы, и после каждой правки координатор вручную переносил данные в админку
Дублирование документов
На одну программу приходилось несколько документов с повторяющимся содержимым. Обновлять их нужно было параллельно
Отсутствие стандартов
Каждый отдел вёл документацию по своему шаблону. Единого формата и процесса не было
Изменения нигде не фиксируются
Правки не сохранялись централизованно. Историю можно было восстановить только вопросом к ответственному
Разрозненность хранения
Единого хранилища не было. Паспорта программ лежали в разных папках и файлах, поэтому искать их было сложно
Проектирование
Разбор процесса
Чтобы увидеть эти проблемы целиком, я разбирал процесс с нуля: схемы не существовало, методист не знал, как работает координатор, и наоборот. Я собирал картину интервью за интервью, с каждой группой отдельно
Бизнесс процесс
Согласование User Story
Я изучал потребности каждой роли отдельно. Итогом стали согласованные User Story с приоритетами: что реализуется сначала, что переносится на следующие этапы
User Story
Гипотезы
Единый интерфейс с переключением ролей
Один интерфейс с переключателем «методист / координатор» и общим набором экранов, которые подстраиваются под выбранную роль. Такой подход экономит разработку: один набор компонентов вместо двух
❇️ Плюсы
Скорость разработки
Один набор компонентов вместо двух, разработка дешевле
Общая логика не дублируется
Версионирование и хранение работают одинаково на всех экранах, без повторной реализации
Правки в одном месте
Изменения в общих элементах, например в структуре программы, вносятся один раз, а не в двух местах
🛑 Риски
Экран перегружен
Приходится либо показывать сценарии обеих ролей сразу, либо прятать часть функций за переключателем
Координатору мешают чужие функции
Чтобы быстро увидеть актуальное состояние программы, координатору пришлось бы продираться через функции методиста
Переключение ролей
Действие, которое не решает ни одну задачу пользователя
Два разных интерфейса
Отдельный интерфейс для методиста и отдельный для координатора, каждый со своей навигацией и своим набором задач. Я выбрал эту гипотезу, потому что она сразу снимает проблему два: ролям не нужно продираться через чужие сценарии, чтобы найти свои
❇️ Плюсы
Только свои сценарии
Каждая роль видит только то, что ей нужно, без лишней навигации
Независимое развитие
Интерфейс методиста можно менять и дорабатывать отдельно от интерфейса координатора
Изоляция ошибок
Правка или сбой в одном интерфейсе не затрагивает другой
🛑 Риски
Два интерфейса вместо одного
Больше объём разработки и поддержки на старте и дальше
Синхронизация общих сущностей
Программу, версии и историю нужно согласовывать между двумя интерфейсами
Переключение ролей
Если задачи ролей со временем начнут пересекаться, два интерфейса придётся сращивать заново
Что выбрали
Я выбрал вторую гипотезу. Методист и координатор работают с одним массивом данных, но решают разные задачи: один создаёт и версионирует программу, другой принимает изменения и запускает потоки. Общий интерфейс пришлось бы либо перегружать всеми сценариями сразу, либо прятать часть функций за переключателем, и оба варианта усложняли бы работу вместо того, чтобы её упрощать
User Flow
Я спроектировал отдельный user flow для каждой роли. Общий принцип, что все действия происходят внутри системы без ручной синхронизации
UX-Flow методиста
Тестирование
UX тест
Собрал два интерактивных прототипа, для методиста и для координатора. Каждый прототип закрывал свои ключевые сценарии
Прототип
Что работало хорошо
Структура и логика редактирования читались сразу
Подсказки модератора никому не понадобились. Навигацию и правку модулей и занятий считывали уверенно, и ни один респондент не переспросил, как что-то поменять
Черновик понятен с первого взгляда
Большинство респондентов верно поняли, что это такое: правки в черновике не затрагивают версию в проде. Поэтому и экспериментировать не боялись
Программа делается без внешних сервисов
Никто не искал способ выйти за пределы системы. Программу создавали и правили прямо в ней, а экспорт в CSV не вызвал ни одного уточняющего вопроса
Изменения прозрачны, передача занимает один шаг
Респонденты видели, кто и что менял: история хранит авторство и время правок. А передачу изменений координатору закрывали без лишних действий
Что работало плохо
Непонятные элементы таблицы
Чекбокс и кнопка «+» сбивали с толку. Было неясно, за что отвечает каждый
Похожие кнопки с разным смыслом
«Утвердить УП» и «Обновить УП по последнему потоку» пользователи путали между собой
Незаметный чекбокс
Чекбокс передачи изменений координатору часто оставался незамеченным. Важное действие терялось на экране
Неожиданный автопереход
Автоматический переход внутрь созданного элемента заставал врасплох. Система действовала за пользователя и не предупреждала об этом
Что ушло в реализацию
Итерация после UX-теста
После теста я доработал интерфейс и упростил ключевые сценарии. В итоге получились два отдельных интерфейса под две роли, с разной логикой и разным набором задач
Методист
Программу теперь создают и правят целиком в системе. Методист больше не держит несколько файлов и не синхронизирует их руками. Версии, черновики и передача правок живут в одном месте
Координатор
Больше не переносит данные в админку руками после каждой правки. Актуальное состояние программы всегда под рукой
Результаты
Эффект в масштабе портфеля
В портфеле компании 261 курс. Каждый обновляется минимум раз в год, и ещё 4-5 новых запускаются ежегодно
до 4 200 000 ₽
в год ожидаемой экономии на ручной синхронизации данных
Обновление курсов
На синхронизацию одного обновления уходило от 8 до 20 часов одного человека, то есть 5 000–12 500 ₽ на каждое обновление. При 261 обновлении в год это 1 305 000–3 262 500 ₽ в год
Новые курсы
На производство нового курса уходило около 200–300 часов синхронизации, то есть 125 000–187 500 ₽ на каждый новый курс. При 4-5 запусках в год это 500 000–937 500 ₽ в год
Что я бы сделал иначе
Я не тестировал похожие по смыслу кнопки «Утвердить УП» и «Обновить УП по последнему потоку» до UX-теста. Проблема всплыла только на прототипе, а могла быть пойманной раньше, на этапе интервью с демонстрацией черновых макетов