Год в традиционной разработке и полгода в зерокодинге: опыт и выводы продюсера стартапа

Нашему технологическому стартапу «Мероприятия района» два года. Мы только сейчас подходим к стадии Seed, и это уже третья попытка. С одной стороны для стартапа это ещё приемлемый срок, с другой — если бы мы знали об инструментах зерокодинга раньше, то пришли бы к текущей стадии быстрее и с меньшими потерями.

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

Также о практическом опыте использования конкретных инструментов — краткое их описание и какие-то субъективные выводы.

Сегодня различных зерокодинговых инструментов больше сотни*, и когда передо мной встала задача выбрать инструментарий, я не стремился изучить все доступные, а решил посмотреть на те из них, которые на слуху (или языке, клавишах клавиатуры) у тех, кто уже погрузился в это направление раньше меня.

* ссылки на несколько обзоров: один, два, три

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

Бегло изучил:

Что было критичным для окончательного выбора:

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

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

Сначала мы шли традиционным для технологического стартапа путем:

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

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

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

В итоге:

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

Что было к этому моменту:

В декабре 2020 года я прошел небольшой, но очень толковый интенсив от ProductSense «Интенсив по техническим скиллам для менеджеров». Интенсив был посвящен нюансам классической разработки, но на последнем блоке этого курса Вад Михалев, основатель Университета Зерокодинга, рассказал про зерокодинг и провел несколько практик на примере конкретных инструментов.

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

Открыл материалы семинара и решил попробовать, что из этого выйдет. Через пять дней у нас был первый черновик прототипа нашего MVP. Это и стало основой решения, которое определило весь наш текущий период.

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

В нашем случае, пришлось:

Сегодня на рынке доступны несколько десятков зерокодинговых конструкторов, которые решают задачу разработки мобильного приложения без кода. Glide и Adalo точно среди лидеров: тут я спокойно доверяюсь экспертизе Университета Зерокодинга и его основателю Вадиму Михалеву. Именно эти два решения он предлагал на интенсиве для продуктовых менеджеров. Подтверждением тому можно считать активные чаты в русскоязычном сообществе по Glide и Adalo.

На Glide собрал практически финальную версию MVP нашего проекта и если бы не ограничения самого конструктора, то этой версии могло бы хватить.

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

Какие у Glide ограничения:

Главное, что точка входа и понимание логики программы в Glide занимает несколько часов. Собрать прототип или сразу финальную версию собственного приложения можно за один или пару дней. Предложенная логика и возможности разработчика не только ускоряют процесс входа и простоту работы, но ещё и могут запросто подкинуть вам несколько толковых идей по UI/UX дизайну или набору функций, которых у вас самих бы и не родилось.

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

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

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

Но далеко не для всех это критично, а возможность подключения внешних БД как напрямую по API, так и с помощью Zapier или Integromat с помощью блоков интеграции для Adalo практически нивелируют этот минус.

Если же вы сторонник Airtable, то вам круто повезло — интеграция с Airtable прекрасная. Все формулы этого зерокодингового инструмента работают в сложных фильтрах и прочих настройках Adalo. Airtable интегрирован практически как собственная БД, чего не скажешь про другие внешние БД — тут с качественной синхронизацией придётся повозиться. Возможно, что нужна будет помощь специалиста по API.

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

В отличие от Glide, где центральная часть экрана отдана или действующему превью вашего приложения или БД, в Adalo на главном экране вся ваша верстка: все экраны и связи между ними. Для сложных продуктов, по-моему, это важнее, чем превью. Оно в Adalo есть — просто надо кликнуть по специальной кнопке.

С дизайном вы можете делать все, что душе угодно, невзирая на UI/UX. Adalo не озабочен, насколько вы понимаете, что творите. Есть свои шаблоны стандартных решений, но их не навязывают. Хотите творить с чистого листа — творите. Шаблонов других проектов пока мало. Инструментарий работы с дизайном не самый удобный, инструментов выравнивания и точного позиционирования крайне мало, но думаю, что это напрямую связано с требованиями к адаптивности интерфейса приложения не только под разные мобильные операционные системы, но и под различные пропорции экранов смартфонов. Тем, кто привык к графической вёрстке, сначала может быть дискомфортно.

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

Возможности Adalo, как я понял, можно расширять компонентами на java. В собственном маркетплейсе есть ряд компонентов от различных авторов, пока все бесплатные. А есть компании, которые разрабатывают компоненты на продажу или под заказ. Говорят, что вполне приемлемый ценник даже для России.

Для нашего MVP бесплатных тарифов быстро стало недостаточно в обоих инструментах, но следующего по стоимости тарифного плана хватило с лихвой:

Выбрать между двумя этими инструментами, в качестве решения внешней БД, было трудно.

И всё-таки, при все этих плюсах скорее в пользу Airtable, мы выбрали QuintaDb:

QuintaDB - для потребностей нашего MVP, 11$ в месяц и есть запас прочности. На наш пилотный запуск его должно хватить с запасом, и это третий тарифный план и дальше тоже хороший выбор. К тому же, есть вариант заплатить сразу за выбранный тариф и больше не оплачивать подписку, и это уникальная сторона сервиса. Тариф распространяется на все проекты (БД) в аккаунте. Всего 8 тарифных планов, включая 1 бесплатный.

Airtable - 12$ в месяц за пользователя. При штате редакторов сумма возрастает существенно, в нашем случае вышло бы как минимум 100$. У каждого проекта свой тарифный план, платных тарифов два, есть один бесплатный и один для корпораций.

Если вы только начинаете пользоваться БД и не планируете ее серьезно масштабировать - начинайте с Airtable.

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

Если нет возможности разбираться c API, то на помощь придут Zapier и Integromat.

Zapier больше раскручен маркетингом, но дороже и, как мне показалось, более капризен.

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

Zapier — 59$ в месяц

Integromat — 9$ в месяц, с риском вырасти до 29$, хотя за доплату в 9$ можно докупить нужные операции, если лимит будет выбран на них.

Мы выбрали Integromat.

Соприкоснулся с этими инструментами, когда искал решение для нашего MVP и пока отказался от их использования, но запомнил — есть шанс, что они могут быть очень полезны и для нашего проекта на какой-то стадии масштабирования.

Это, конечно, промышленный масштаб конструктора, который включает в себя и широкий функционал для БД, и для производства сайтов, возможность использования low-code и прочее.

Что отпугнуло (пока):

Основная специализация этого инструмента – создание ЛК конечных пользователей вашего приложения, этот инструмент надо использовать в связке с другими решениями. Так мы его и рассматривали, как инструмент, расширяющий возможности Airtable.

Слишком дорогой для нас — 60$ в месяц самый дешёвый тариф, потянул бы за собой и платный тариф Airtable (если я верно понял).

Крутой и интересный инструмент от наших отечественных разработчиков, что важно, c русскоязычной поддержкой.

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

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

Простой вход, хорошая документация, много примеров и шаблонов, хорошая поддержка.

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

Полгода назад понимание ситуации на старте захода в тему зерокодинга было следующим:

Что из этого нашло подтверждение, а что нет.

Пожалуй, это самый главный лозунг современного no-code сообщества.

Свою почтовую рассылку конструктор мобильных приложения Adalo уже традиционно подписывает: «A world where only 0.3% of people can create software is a world missing 99.7% of its potential».

"Мир, в котором только 0,3% людей могут создавать программное обеспечение, - это мир, в котором отсутствует 99,7% его потенциала".

Лозунг крутой и красивый! Но 1%, или даже 2% - это сильно больше, чем 0,3%, но это по прежнему не "каждый".

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

В общем, надо достаточно критично отнестись к гипотезе, что изучение зерокодинговых инструментов из не разработчика сделает разработчика.

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

Хотя все есть жизненный опыт и весь он важен.

Сегодня со своим опытом зерокодинговой разработки я бы пришел к нужному результату за месяц. Но когда столкнулся с зерокодингом впервые, то потратил три месяца на разработку полноценного MVP.

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

После месяца экспериментов начал разрабатывать весь комплекса IT-решений нашего MVP:

Если весь этот период разделить условно на 3 части, то:

1/3 времени — непосредственно разработка;

2/3 времени — тестирование, выявление ошибок, отладка, новое тестирование уже на больших объемах данных, новые ошибки, новая отладка. Потом отработка различных сценариев работы со стороны пользователя и со стороны редактора. И все заново.

Чем больше ваш стек — количество инструментов в общей IT конструкции — тем больше слабых мест и причин для ошибок и сбоев. Как результат — существенные затраты на тестирование и отладку.

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

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

И тут:

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

- или команда разработчиков обладает настолько серьезными компетенциями: low-code или уверенные навыки программирования, что зерокодинговые инструменты оптимальный выбор, а не результат лимита компетенций.

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

Приложение можно будет поддерживать тоже собственными силами весь жизненный цикл за приемлемые стоимость и время.

Когда мы говорим про зерокодинговые инструменты, доступные не профессиональному разработчику, то они обычно:

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

- дорого стоят. Обычно это SaaS и чем больше проект, тем дороже тарифный план, что вместе с большим стеком может привести к большим бюджетам на поддержку, даже дороже, чем команда программистов в штате.

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

Не факт, что надо будет разом менять все инструменты зерокодинга, это может происходить поэтапно. При первой попытке создания MVP, БД у нас была на QuintaDb, а приложение писали на React Native, и это была вполне стабильная и масштабируемая связка на достаточно продолжительный срок жизни проекта.

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

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

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

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

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

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

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

Решение об использования зерокодинга для создания MVP показало свою состоятельность:

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

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