Сколько на самом деле стоит цифровая разрозненность

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

На ВДНХ таких сайтов было 14. Они отличались по дизайну, структуре и технологиям. Контент приходилось дублировать, пользователи терялись при переходах, а рост посещаемости создавал проблемы с производительностью.

Проблема

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

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

Причина

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

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

В этой ситуации простой редизайн не помог бы. Новый интерфейс сохранил бы старую разрозненность.

Решение

Все проекты объединили на одной платформе с общей базой событий, мест и новостей.

Пользовательская часть была отделена от административной системы и обработки данных. За счет этого каждый компонент можно развивать независимо.

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

Главная сложность

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

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

Вторая сложность была связана с афишей. Более 100 параметров фильтрации создавали слишком много вариантов запросов. База данных переставала справляться даже при небольшой активности.

Чтобы не формировать каждую подборку заново, события заранее распределили по упорядоченным наборам. После этого сложные фильтры стали обрабатываться за 3‑5 мс, а нагрузка на базу сократилась на 90%.

Результат

Проект занял 6 месяцев вместе с дизайном, согласованиями и документацией.

Время отклика серверной части сократилось с 900 до 62 мс. Первый экран загружается менее чем за 2 секунды даже при высокой посещаемости.

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

Платформа осталась на прежней инфраструктуре, но получила запас для роста нагрузки.

Что важно учесть руководителю

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

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

Четвертое. Заранее определите показатели результата. Для крупного портала это могут быть скорость отклика, загрузка первого экрана, нагрузка на базу и время публикации материала.

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