Пользовательские интерфейсы для бизнеса: адаптация без потерь

Предыстория

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

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

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

Проблема

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

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

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

Выбор стратегии

Перед командой встали два варианта действий:

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

Что выбрать? Быстрое внедрение новой версии с последующим развитием на основе обратной связи? Или постепенный перевод пользователей после полной готовности продукта?

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

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

Как решали задачу

1. Первым шагом стало определение подходящего фреймворка и необходимых библиотек. Критерии выбора включали долгосрочную поддержку, удобство использования и совместимость с языком программирования старого фреймворка. Так как изначальная версия была написана на JavaScript, выбор пал на Vue.js — легкий и производительный фронтенд-фреймворк, который удобно интегрировать. Стек разработки состоял из Vue.js и Quasar.

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

3. Для поддержки обоих интерфейсов на всех тестовых стендах потребовалось изменить код маршрутизации на серверной стороне. Устранили проблемы с CORS и подключили статические файлы интерфейсов.

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

К каким результатам пришли

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

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

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

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