Разработка сайта Атомстройкомлекса

Разработка

Далее Атом предложил нам воплотить дизайн в жизнь. Мы основательно подготовились к реализации этой задачи:

1. Выделили отдельную команду под проект. На старте проекта в звене разработки было 2 специалиста, в самые сложные моменты — 6 человек. В дальнейшем меняли состав команды в зависимости от требований проекта.
2. Заранее познакомились с новыми элементами стека, исключив фактор автобуса: позаботились, чтобы на GraphQL и Next.js писал не один член команды.

Особенности реализации интеграции с 1С

Ещё один сложный этап разработки — интеграция базы загружаемых на сайт объектов с системой 1С. Структура выгрузки данных идеально подходила для старого сайта, но не годилась для нового. У Атома сформировалась собственная и достаточно большая структура информации, под которую нам пришлось подстраиваться. Чтобы синхронизировать данные, нам пришлось учитывать множество индивидуальных особенностей имеющейся иерархии и свойств объектов, а также их разные типы – квартиры, апартаменты, парковочные места, кладовые. Понадобилось больше полугода, чтобы адаптировать выгрузку и подготовить базу данных.

В основном для идентификации использовались шифры «Объектов», куда заносилась информация по всем помещениям. В отдельных случаях требовались дополнительные поля, чтобы определить очередь, дом, уровень, этаж и тому подобное.

Основная информация про квартиры интегрировалась без проблем, а вот с кладовыми и паркингами пришлось поработать дополнительно. Дело в том, что информация по этим объектам «нанизывалась» на скелет информации по квартире. В итоге какие-то из полей оказывались ненужными, а где-то информации для идентификации не хватало. Мы обратились к команде поддержки 1С на стороне клиента. По нашим рекомендациям они создавали отдельные поля, которые мы использовали для идентификации объектов, например, <Паркинг>, <Уровень> и <Кладовая>. При появлении новых объектов мы также взаимодействуем с поддержкой 1С, чтобы объекты заводились корректно и потом легко идентифицировались на нашей стороне.

В финальном варианте интеграция работает следующим образом:

Мы предусмотрели два вида загрузки данных:

1. Полная выгрузка каталога. Периодичность — каждые полтора часа в течение рабочего дня. Эта выгрузка основана на xml-файле от 1С, в котором содержится список объектов со списком квартир, их свойствами и статусами. Если помещение уже есть в базе сайта и найдено в файле, то его статус и цена перезаписываются на предоставленные в файле.
2. Обновление «по требованию». Отрабатывает мгновенно. Эта выгрузка данных затрагивает только одно поле – статус объекта недвижимости. 

Для быстрого контроля в панели администратора предусмотрен дашборд, по которому можно отслеживать, всё ли в порядке с оперативным обменом.

Тестирование интерфейса

Параллельно с разработкой мы регулярно проводили тестирование результатов и собирали обратную связь:

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

Инструменты в работе с сайтом

Сайт Атома в конечном итоге состоял из большого количества шаблонов. Всей командой держать в памяти, куда и откуда можно попасть, было практически невозможно, а в лучшем случае малоэффективно. Чтобы облегчить работу над проектом, оперативно собирать фидбэк от команды и оставаться прозрачными для клиента, мы использовали следующие инструменты и сервисы:

• Карта проекта на Miro;
• Дневники разработчиков;
• Trello для клиента;
• EasyRetro.

Нас часто выручала платформа Miro — с ее помощью удобно визуализировать и структурировать различные процессы, например обновление информации или загрузку контента.

Карта проекта в Miro позволила нам понять, насколько «глубоко» находятся те или иные разделы, и вынести ближе наиболее важные. Также мы смогли оценить, насколько сложен и вариативен путь до разделов.

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

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

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

Для проведения ретроспективы и сбора фидбека со всех участников команды использовали платформу EasyRetro. Весь процесс разделили на три блока, в рамках которых отвечали на вопросы, предлагали изменения, голосовали и обсуждали проект. Такая относительно простая структура позволяет держать фокус на обсуждении.

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

Релиз сайта

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

Замена адресов была необходима по следующим причинам :

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

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

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

К концу первой недели после запуска новый сайт работал в штатном режиме, а к концу августа мы поправили выявленные баги. Текущий функционал сайта (без кладовых) был выполнен.