Осторожно, конструктор!

Руководитель проектов digital-агентства ZephyrLab Патрик Уинато рассказывает о трех кейсах, когда планы на использование конструктора сайтов разбились о жестокую реальность.

Противостояние «Разработка VS Конструктор сайтов» длится много лет. Только на vc. ru я насчитал семь материалов на эту тему, а потом перестал считать. Мнения выражаются полярные и, как правило, это объясняется тем, за какую команду «играет» спикер. Разработчики и SEO-специалисты традиционно ругают конструкторы сайтов, им возражают создатели конструкторов, подчеркивая плюсы готового решения: чаще к ним относят бюджет и скорость реализации.

Эта статья — не попытка занять чью-либо сторону, или устроить очередной холивар, а желание поделиться реальным опытом работы агентства ZephyrLab с шаблонными решениями. Наш профиль — дизайн сайтов, интерфейсов, мобильных приложений и сложных систем, но мы имеем отношение к разработке. Мы разрабатываем приложения и сайты с помощью наших партнеров и, в том числе, отвечаем за бюджеты и сроки разработки, но не зарабатываем на SEO и не продвигаем ни один из конструкторов.

Возможно, это будет самая независимая рецензия в истории.

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

С первым неудобством мы столкнулись при решении элементарной, как нам казалось, задачи: оптимизации раздела «Проекты». Она потребовалась, потому что кейсы было неудобно публиковать, а в разделе они выглядели не информативно и не наглядно: слева небольшое описание, а в основной части страницы скриншоты. При этом не было инструментов, которые позволяли бы комментировать скрины, вставлять текст непосредственно в тело страницы.

Тогда за работу взялись наши аналитики: добавили недостающую информацию, сделали четкую и понятную структуру. Затем дизайнеры создали новую страницу, разработчикам же оставалось только перенести отрисованные в Figma экраны. На этом этапе стало понятно: переделать структуру сайта очень сложно. А, если и сделать это, на выходе мы все равно получим непрактичный и неудобный инструмент — легче написать сайт с нуля на CMS или фреймворке и он будет удобнее.

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

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

«Водопад» не эффективен для разработки сложных продуктов, так как сильно увеличивает сроки работы по проекту, но у гибкой системы тоже есть свои минусы — при таком подходе невозможно заранее предусмотреть все функциональные требования (ФТ). Однако на старте нам казалось, что мы довольно точно спрогнозировали ФТ и они, если и будут выходить за пределы возможностей «Аспро», то не значительно — значит, предстоит небольшой объем работ со сторонним кодом. Кроме того, мы все еще не до конца разобрались в деталях работы по проектированию в конструкторе. Да, и проект сложный со всех точек зрения, и у «Аспро» сложный интерфейс, но не с таким работали — сделаем!

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

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

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

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

Если у вас ограничен бюджет, или требуется быстро проверить гипотезу, создать MVP (minimum viable product, минимально жизнеспособный продукт) или прототип для теста на пользователях — конструктор может быть реальным вариантом решения задачи.

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