Обратная сторона «Зарядья»: как строился парк в digital

Осенью 2016 года мы выиграли тендер на разработку сайта и мобильного приложения для парка «Зарядье», строительство которого стало одним из самых спорных, нашумевших и претенциозных проектов московского правительства за последние годы. И digital-часть этого проекта должна была стать примером для родственных городских пространств.

Архитектура digital-пространства и подводные камни

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

• Приложение. Во многом оно дублирует функции сайта — там тоже можно посмотреть афишу и записаться на мероприятия, купить билет. Но в приложении абсолютно другая навигация по афише, а также добавлены маршруты по окрестностям «Зарядья».

• Личный кабинет. Можно авторизоваться — через соцсети или Госуслуги — и пользоваться сайтом и приложением через личный кабинет. А также: смотреть свой календарь избранных мероприятий, хранить билеты.

• Корпоративный портал. В нем осуществляется групповая работа над задачами, обновляется внутренняя лента новостей, доступна визуальная структура проекта и телефонный справочник компании.

• Интернет-магазин. В нем можно увидеть сувенирную продукцию парка, а также изделия от известных дизайнеров.

Звучит не так уж сложно? На деле для того, чтобы все это реализовать, мы интегрировались с 7 сторонними коммерческими сервисами и еще с 3 городскими.

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

В чем особенность digital-проектов для общественных пространств?

Под общественными пространствами мы подразумеваем такие места, где постоянно проходят массовые мероприятия: это могут быть крупные парки вроде «Зарядья», музеи, выставочные центры.

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

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

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

Мы столкнулись со всеми этими сложностями во время проекта, который мы делали для «Зарядья». Расскажем, как удалось с ними справиться.

«Зарядье» — парк будущего: в чем суть digital-пространства?

На одно лишь строительство и реконструкцию парка «Зарядье» городские власти потратили 14 млрд рублей. Проект получил массу номинаций и премий в области градостроительства и туризма: победил в международной премии ArchDaily, попал в рейтинг «Топ-100 лучших мест мира» по версии журнала Time в 2018 году, стал финалистом престижной архитектурной премии MIPIM Awards 2018.

Естественно, digital-представительство такого проекта должно быть на уровне. Сайт и приложение «Зарядья» — дополнительные инструменты для привлечения в парк как местных жителей, так и туристов. И эти платформы должны быть красивыми, функциональными, иметь сложную архитектуру и работать быстро и без перебоев.

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

Первые сложности начались еще на этапе согласования ТЗ — после того, как мы выиграли конкурс и стали обсуждать с заказчиком подробности задачи. Сначала были какие-то мелочи: тут подправить, это убрать, а вот это добавить.

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

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

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

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

Почему же все оказалось так сложно?

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

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

Что еще нужно учесть, если вы проектируете сайт/приложение общественного пространства или другого проекта со множеством интеграций?

• Создайте мастер-хранилище — единое место, куда все системы будут передавать информацию
• Убедитесь перед началом разработки, что все участники интеграционного процесса работают по единому сценарию. Если появляется новый участник, он должен ознакомиться со всеми существующими артефактами ДО того, как присоединиться к процессу
• Если работаете с городом, закладывайте больше времени на все процессы. Для интеграции с городскими системами требуются специальные ключи и сертификаты. На получение каждого уходит от 3 дней до 2-3 недель, техподдержка отвечает долго. Наберитесь терпения.
• Общайтесь! Как и в отношениях между людьми, в процессе разработки важно постоянно обсуждать все со всеми подрядчиками, получать обратную связь и вовремя вносить коррективы
• Управляйте требованиями. Если изменится хотя бы одно требование хотя бы к одной системе, нужно пересматривать весь процесс интеграции — потому что это изменение наверняка затронет как минимум одну другую систему, и скорее всего это будет ваш сайт

Проект по разработке сайта и приложения для «Зарядья» оказался очень амбициозным — одновременно непростым и крайне увлекательным. Это был один из самых технически сложных проектов за всю многолетнюю историю существования агентства Notamedia.

Сегодня сайт и приложение парка уже запущены — ими ежедневно пользуются тысячи туристов и жителей Москвы.