Реквизит

Реквизит

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

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

Мы обсудили недостатки проекта, выявили, что он написан на Wordpress и тут же узнали, что заказчик хочет делать проект на Битриксе, так как он проще в управлении и более гибок к масштабированию. Далее, мы попросили заказчика запустить отрисовку дизайна и ждали макеты.

Бизнес-аналитика

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

После ознакомления с дизайном мы решили провести глубинное интервью и уточнить у Заказчика, каким образом он планирует монетизировать этот проект, так как контент в карточках и колонках был достаточно разноплановый: Услуги, Афиши, Достопримечательности, Организации, Новости, Блог, Объявления и другое. То есть, контент агрегатора можно было сразу же поделить на коммерческие и некоммерческие направления.

Например, рубрику Новости и Достопримечательности будут читать жители региона и его туристы. А рубрику Объявления, Организации будут просматривать как заинтересованные в покупках различных услуг (например, такси или маникюр) жители региона, так и сами рекламодатели.

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

• Заказчик рекламы может выкупить любое место в любой колонке;
• Рекламное место выкупается на определенный срок, после чего объявление нужно снять с публикации;
• Эталонно администрировать это силами редакторов заказчика, которые будут получать заявки на размещение от отдела продаж, чтобы не держать в штате разработчика;
• В день могло быть неограниченное количество корректировок в связи со снятием рекламных блоков с публикации, либо продлением публикации на новый срок;
• Отдельные блоки и сам адаптив управляются независимо от типа устройства (на адаптиве часть блоков отсутствовала).

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

Этап 1. Проектирование и написание ТЗ проекта

Мы построили майндмап, позволяющий отразить структуру модуля и учесть все сценарии работы пользователя сайта и редактора, а также поведения элементов верстки при внесении настроек публикации:

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

Для реализации этого проекта потребовалось собрать команду из менеджера проектов, Front-end разработчика (знающего VueJS) и Back-end разработчика, умеющего работать с Rest APi.

В рамках ТЗ определили последовательно шаги процесса разработки:

• Подготовка среды разработки
• Настройка локальных копий и демо-среды для клиента.
• Back-end (реализация на уровне независимого Модуля Битрикс)

1. Архитектура модуля
2. Rest APi (с описанием методов и запросов)
3. Кеширование под проект, с уклоном на большие нагрузки (html, memcache)
4. Проработка возможностей SEO
5. Проработка возможностей Автотестирования
6. Front-end

• Интеграция верстки в реактивную среду Vue. js
• Проработка связи js контейнера с Rest APi
• Отладка производительности приложения на клиентах
• Проработка возможностей Автотестирования при деплое
• Совместное тестирование внутри компании

Этап 2. Реализация проекта

Для администрирования модуля была создана группа пользователей «Редакторы», попадая в которую, сотрудники Заказчика могли видеть все доступные инфоблоки, а также разработанный модуль.

Сценарии работы редактора можно было отразить следующим образом, пошагово:

Шаг 1: Заходит на сайт в административную панель.

Шаг 2: Создаёт физически новость в разделе «Данные» — Новости — Создать элемент. Устанавливает галочку «Показывать на главной», являющуюся признаком отправки элемента в таблицу модуля.

Шаг 3: Переходит во вкладку модуля в админке (Вынесен в меню отдельно).

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

Шаг 5: Видит список новостей (помеченные для отображения на главной).

Шаг 6: Находит нужную новость среди опубликованных на главной, либо через поиск по названию новости

Шаг 7: Устанавливает параметры сортировки (порядок вывода блока в колонках), сроки закрепления публикации (поля для ввода интервала даты активности)

Шаг 8: Блок выведен на главную страницу с указанными редактором или администратором параметрами.

Администрирование в модуле заложили по следующим параметрам:

01. Автоматическое управление интервалами активности

02. Ручное управление публикацией элементов:

03. Для разделов по умолчанию:

04. Отображение блока в зависимости от устройства

Ретроспектива

В конечном итоге, после окончания реализации модуля, мы сделали ретроспективу и выделили для себя такие выводы к успеху подобных реализаций на основе своих ошибок:

1. В любой гениальной идее может и имеет место быть две стороны «медали»: бизнес-логика заказчика и логика возможностей сценариев работы решения. Они могут совпадать (и в идеале) стремятся к закрытию единой задачи — автоматизации бизнеса, минимизация операций и рутины. Чтобы на старте учесть все подводные камни и синхронизировать ожидания заказчика и разработчика, категорически важно согласование пожеланий и точное снятие потребностей при помощи визуальных инструментов: логических карт, прототипов, описание пользовательских сценариев.
2. Важно вести документацию проекта и его API с самого начала работ.
3. На берегу важно начать с определения формата взаимодействия специалистов и выделить время на созвоны и обсуждения участников проектной команды.
4. Нужно уделить внимание определению основных пользовательских сценариев, после финального тестирования составить обучающий документ для клиента, подготовить фото/видеоматериалы для обращения к ним в процессе взаимодействия с модулем, реализовать подсказки в интерфейсе редактора. Для понимания между клиентом и исполнителем важно провести презентацию всех сценариев совместными усилиями, чтобы избежать конфликтов и негатива, связанных с неправильным интуитивным самостоятельным тестированием клиента.

Тезисы руководителей

Прошкина В.

Руководитель производства

Этот проект являлся одним из первых продакшн проектов в стеке API-based (VueJS/Bitrix) в нашей компании, что также накладывало трудности и в реализации, и при том же проектировании системы. Однако, этот проект стал самым нетиповым и интересным для нас. Благодаря ему, мы почувствовали, что действительно способны разработать любое решение для любого бизнеса, которое действительно будет решать его основные задачи в онлайн.

Стек технологий