No code против кастомной разработки (часть вторая)

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

  • Стоимость разработки

Мы отмечали, что низкая стоимость разработки при помощи инструментов без кода, особенно на начальных этапах, открывает широкие возможности для стартапов. Стоимость, безусловно, увеличит внедрение неких уникальных функций и интеграций, требующих от разработчика большого технического опыта. Также возможны т.н. low-code решения, когда применение традиционного программирования сведено к минимуму, а основная часть реализуется без кода. Как мы уже писали — это безупречный вариант разработки MVP.

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

Сложности с no code возникают тогда, когда решение требует внедрения сложных уникальных функций, например, искусственного интеллекта, нейронных сетей или аналитических модулей, работающих с большими объемами данных. Однако такие проекты всегда стоят дорого. Согласно статистике Soltech, конечная стоимость кастомных проектов по разработке уникального ПО начинается от $40 000 и заканчивается $250 000.

  • Скорость реализации

Кастомные проекты почти всегда требуют много времени. Иногда заявленное командой время в процессе разработки, правок и дополнений увеличивается в 2, 3, а порой и в 5 раз. No-code решения, напротив, созданы для быстрой, а иногда мгновенной разработки. В таких проектах максимум времени можно уделить точному формулированию бизнес-требований, проработке дизайна.

Основные хронологические риски No-code - это вероятность проблемы сложных функций и интеграции в готовые системы. В некоторых инструментах их нет вообще, а в иных они предполагают традиционное программирование. Кастомное программирование требует несопоставимо временных затрат. Например, согласно данным Goodfirms, среднее время разработки составляет не менее 4,5 месяца. Именно столько занимают все этапы кастомной разработки до момента запуска. В случае с no-code время реализации редко выходит за пределы 1,5-2 месяцев, за счет оптимизации рутинных задач и высокой скорости визуального программирования.

  • Длительность обучения, уровни прав и гибкость управления

Многие считают именно вопросы скорости освоения и управления системой наиболее значимым различием между no code и кастомными платформами. В первой части мы писали, что гибкость реализации на no code обычно ниже, чем при использовании традиционного программирования. Если говорить о пользовательской настройке, то всё с точностью до наоборот.

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

No code позволяет быстро изменить дизайн, поменять шрифты, скорректировать процессы пользовательского взаимодействия, мгновенно меняя UX и UI, чтобы улучшить интерфейс. Обычно, чтобы что-то поменять в кастомном проекте, нужно обращаться к разработчику, с no code пользователь вносит большинство изменений сам, а в ряде решений сам является разработчиком. За счет этого решения в no code проектах понятнее для пользователей.

  • Требования к хостингам, интерактивность, инновации

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

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

  • Интеграция готовых решений

No-code, как правило, предполагает стандартные, заранее определенные средства интеграции, например, с платежными агрегаторами, CRM-системами, мобильными и облачными сервисами. Сами no-code платформы уже являются готовым API. Сложности могут возникнуть лишь тогда, когда предполагается нестандартная интеграция, например, если по дефолту интеграция не предусмотрена и приходится прибегать к Lo-code.

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

  • Безопасность

У людей пока существует психологический барьер относительно безопасности систем без кода. Между тем, дыры существуют везде и если речь идёт о критических данных, необходимо любое решение тестировать на взлом. Пока, когда речь идет об особых мерах безопасности, традиционным считается кастомная разработка. Между тем, у no-code платформ о безопасности дополнительно заботится компания, представляющая сервис. И в проектах с менее жесткими требованиями к безопасности можно рассчитывать на уровень, который по дефолту предоставлен платформой.

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

Поддержка и обслуживание

Сами платформы разработки без кода не предоставляют услуг мгновенной поддержки в случаях, когда возникает системная ошибка. Но это делают no-code разработчики. Иногда проблема решается, когда сервис выкатывает очередное обновление, иногда приходится ждать двух или трёх. Хорошей новостью является то, что ошибку в любом случае поправят. Плохой, что скорее всего это произойдет не сразу, если она будет не на уровне разработчика, но на уровне платформы.

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

Критерии выбора

На основании представленного детального сравнительного анализа преимуществ и недостатков традиционной разработки и no-code решений можно сформулировать критерии выбора той или иной для конкретного проекта.

No-code подойдёт, если проект соответствует перечисленным условиям в следующих условиях:

  • Небольшая компания с ограниченными ресурсами
  • Есть стандартные функции, интеграция и модификации минимальны или решаются стандартными средствами no-code платформы
  • Создается MVP, чтобы протестировать продукт в реальных условиях
  • Необходимо реализовать проект за короткое время. При этом следует учитывать, что этапы, предшествующие разработке, займут такое же время, что и при реализации no-code решения.
  • Заказчик проекта готов к тому, что с ростом посещаемости разработанного сайта или сервиса, увеличении объема хранилища данных, количества пользователей или страниц продукта, придется платить больше чем в начале разработки (переход на другой тариф например, подключение сторонних, платных модулей). правда, оплата может быть и единоразовой, в каждом отдельном случае нужно разбираться.

Факторы, которые стоит учесть

При выборе no code инструмента не стоит уповать на великий рандом и тыкать пальцем в небо, нужно учесть ряд факторов:

  • Интуитивность и удобность интерфейса управления (или разработки, если вы хотите разрабатывать самостоятельно)
  • Доступность и корректность работы плагинов, шаблонов, инструментов, а также их стоимость.
  • Оперативность поддержки со стороны сервиса и команды разработчиков.
  • Стабильность поставщика услуг.
  • Отзывы.
  • Комьюнити - численность пользователей и задачи, которые они реализовывают при помощи платформы.

Не менее значимым являются факторы выбора команды кастомной разработки:

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

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

Начать дискуссию