ADVANTA — трансформация системы управления проектами
Пересобрал ключевые сценарии и интерфейс продукта для работы с большими объёмами данных.
Результат
Пользователи стали дольше работать в системе
Пользователи стали чаще заходить в систему ежедневно
Обновление и дополнение модулей увеличило число лицензий
ADVANTA стала понятнее и ближе к современным IT-решениям
Контекст
Почему началась трансформация?
В условиях импортозамещения у компаний появилась потребность переходить на отечественное ПО, что усилило конкуренцию между российскими разработчиками за новых клиентов.
Для развития ADVANTA предстояла масштабная техническая перестройка и переход на Linux. На тот момент продукт был функционально зрелым, но сложным и перегруженным, а по скорости и части функциональности уступал конкурентам.
Поэтому техническую трансформацию решили использовать как возможность одновременно пересобрать UX и UI продукта.
Проблемы и исходная точка
Для определения проблем мы провели ряд исследований, включающих в себя JTBD и CustDev-интервью, для ряда текущих разделов системы собирали CJM.
На чем мы сфокусировались
01. Производительность
Система медленно загружалась, а работа с большими объёмами данных была неудобной.
02. Сложные сценарии
Создание объектов и другие операции были разбиты на несколько последовательных шагов.
03. Разрозненная структура
Часть связанных сущностей существовала отдельно, а страницы объектов содержали больше информации, чем было нужно конкретному пользователю.
04. Функциональные разрывы
Не хватало привычных инструментов для управления задачами, коммуникации и работы с данными.
Ключевые решения
Как мы сделали работу с данными быстрее
Проблема
Пользователи редко работали с большими объёмами данных в ADVANTA из-за медленной работы системы и сложных сценариев. Поэтому часто использовали импорт из таблиц. Это подтверждали интервью и данные тепловой карты. Пользователи также отмечали, что таблицы были перегружены нерелевантной для пользователей информацией.
1.1. Переработали таблицы
Оставили только ключевые поля по умолчанию и добавили настройку состава и ширины колонок.
1.2. Добавили inline-редактирование
Теперь объект можно создать и сразу редактировать непосредственно в таблице, не открывая отдельную страницу.
1.3. Добавили быстрое создание
Пользователь может последовательно создавать несколько объектов, а обязательные данные заполнить через дровер, не покидая текущий экран.
Компромисс: скорость vs контроль
Нам нужно было ускорить массовое создание задач, но сохранить единый стандарт данных. Поэтому мы оставили быстрый режим создания, а обязательность дополнительных полей сделали настраиваемой на уровне компании.
2. Ввели единые паттерны взаимодействия
Проблема
В старой версии создание, фильтрация и просмотр объектов происходили через отдельные страницы и модальные окна. Пользователю приходилось постоянно покидать текущий рабочий контекст.
2.1. Создание и редактирование
Объект создаётся и редактируется поверх текущей страницы.
2.2. Фильтрация
Фильтры открываются в дровере, при этом пользователь остаётся в рабочем контексте.
2.3. Предпросмотр
Основную информацию можно посмотреть без перехода в полную карточку объекта.
3. Закрыли сценарий управления задачами внутри ADVANTA
Проблема
В ADVANTA не было Kanban для управления задачами, поэтому пользователи вели их в сторонних сервисах, а артефакты хранили в ADVANTA. Это разрывало рабочий процесс и вынуждало переключаться между системами.
Таким образом, мы добавили Kanban-доски и обновили сценарии работы с задачами.
Что в нашем канбане особенного?
Мы не создавали отдельную сущность, которая существует параллельно основной модели ADVANTA. Kanban встроен в существующую логику продукта и может строиться на основе любого реквизита-процесса или классификатора.
Например, если у клиента уже настроен собственный жизненный цикл задач, его можно использовать в Kanban — без создания дополнительных статусов и сущностей.
Гибкие карточки
Пользователь самостоятельно определяет, какие реквизиты и поля объекта показывать на карточке.
Такой подход позволил сделать Kanban частью существующей модели данных, а не отдельным инструментом внутри системы.
Проверка решений
UX-тестирование
Мы регулярно тестировали решения через интервью с пользователями. Это помогало проверять гипотезы ещё на этапе прототипов и находить слабые места до разработки.
При этом тесты не всегда подтверждали наши идеи — иногда пользователи показывали, что выбранное направление не решает их задачи. Например, при разработке модуля «Рабочие столы» интервью показали, что первоначальная концепция MVP не отвечала ключевым потребностям клиентов. На этом этапе мы скорректировали решение и направление развития.
Итоги
Обсуждение результатов
На количественные показатели, представленные выше, наибольшее влияние оказали следующие системные изменения:
Техническая модернизация: Переход системы на Linux и обновление технологического стека. Это не только повысило быстродействие, но и заложило техническую основу для внедрения новых функций.
- Инлайн-редактирование: Внедрение этой функции трансформировало пользовательский опыт, сделав платформу похожей на интуитивный табличный редактор. Это увеличило частоту использования и скорость работы с данными.
- «Дровер»: Это решение унифицировало ключевые пользовательские пути — создание, фильтрацию и редактирование объектов, — значительно сократив сложность взаимодействия.
- Канбан-доски: Данный инструмент стал мощным двигателем для управления задачами. Его ценность была очевидна клиентам уже на этапе демонстрации, что напрямую повлияло на увеличение среднего чека, поскольку он оказался востребован всеми группами пользователей.
