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

Привет! Меня зовут Маргарита Комиссарова, я руковожу отделом аналитики и проектирования в агентстве Notamedia.

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

В этой статье я расскажу, как мы «строили» парк и сколько грабель собрали по пути. А также поделюсь своими соображениями, как этого всего можно было избежать.

Я должна сразу признаться: разработка сайта и мобильного приложения для «Зарядья» далась нам непросто и держала в тонусе всю нашу команду от начала до самого конца.

Проект состоял из следующих компонентов:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#разработка_сайта