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

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

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

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

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

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

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

• Glide — конструктор мобильных приложений
• Adalo — конструктор мобильных приложений
• Airtable — база данных, электронные таблицы
• QuintaDB — база данных
• Itegromat — синхронизация данных между различными частями общего IT решения
• Zapier — синхронизация данных между различными частями общего IT решения
• Sherpa RPA — программные роботы для автоматизации рутинных процессов

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

• Bubble - конструктор приложений и база данных
• Stacker - личные кабинеты пользователей

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

• Простота входа и использования — последние полгода разработка упала на меня. Опыт в разработке у меня был совсем небольшой и управленческий. Из программирования я вообще изучал только Basic в школе.
• Стоимость использования — для стартапа на стадии Pre-Seed доступных вложений всегда минимум, а большинство из инструментов полноценно использовать получается только на платных тарифах.
• Полнота функционала — минимизация общего стека IT-решений.

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

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

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

• От задумки к разработке концепции продукта.
• Проверили, какие проблемы мы можем решить нашим продуктом через кастдев: взяли серию интервью и опросов потенциальной аудитории.
• Исследовали рынок на предмет его потенциала, игроков, бизнес-моделей и конкурентов.
• Определили собственные продуктовые гипотезы и бизнес-модели.
• Разработали первые концептуальные прототипы в Miro и Figma.
• Подготовили техническое задание на разработку и UI/UX дизайн в Sketch.
• Разработали MVP командой разработчиков на React Native (среда программирования).
• Сделали первую публикацию в Google Play.

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

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

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

В итоге:

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

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

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

• Потеряли команду разработчиков.
• Потеряли время.
• Возможности инвестирования собственных средств стали скромнее — только на разработку мы потратили 600 000 рублей и еще легко отделались: мы работали с дружественной командой разработчиков, а оценка нашего MVP по рынку, без всех последующих корректировок, связанных с темой онлайн была от 1,5 до 2,5 млн. рублей.
• Надо было начинать все заново.

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

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

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

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

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

• Искать решение для внешней БД - выбирал между Airtable и QuintaDb. Благо повод разобраться с БД у меня уже был раньше и я рассказываю о нем в статье.
• Искать решение для синхронизации данных между внешней БД и Adalo. Выбирал между Zapier, Integromat или прямой коммуникации посредством API (API - это отдельная тема, которая не менее важна в разработке, чем БД. Здесь я описываю свой опыт изучения этого вопроса)
• Надо было найти и изучить инструменты парсинга данных с последующей чисткой их для передачи в БД с минимизацией ручного труда. Для парсинга выбирал между программами-парсерами и программным роботом Scherpa RPA (для чистки данных: Excel, Google Таблицы, Airtable).

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

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

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

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

• Есть готовый набор функций, возможных конструкций интерфейса, типов пользовательских экранов, которые закрывают существенную часть потребностей мобильного приложения. Выбираете и пользуетесь. Как в Лего — есть несколько типов блоков из которых можно собрать и машинку, и космическую ракету. Минус — сделать что-то кастомное крайне сложно, а может и не возможно, ни по возможностям, ни по дизайну. Плюс в этом же. Большинство логических конструкций уже разработаны и очень большой шанс, что их вам будет достаточно. Готовый дизайн с минимальными возможностями что-то корректировать не позволит сделать явную клюкву. Предлагаемых модулей и функций действительно много. Как и готовых шаблонов, на базе которых вы за 15-30 минут можете получить свое приложение с собственными данными.
• База данных — пока только Google Таблицы. Минус — Google таблицы не особо годный инструмент для ведения БД. Не случайно сам Glide расширяет недостающие возможности Google Таблиц набором собственных функций и типами полей. Базам данных в Google Таблицах не хватает нескольких десятков типов столбов, нормальных реляционных связей между таблицами и мощностей, чтобы обрабатывать данные. Если в таблице более 1000 строк — скорость работы падает. Для работы в Glide необходим аккаунт в Google. Зато если вы себя хоть сколько-то уверенно чувствуете в Google Таблицах или в Excel или в Numbers, умеете структурно заносить информацию, то уже готовы к работе в Glide. Не надо будет мучиться с настройкой синхронизации данных — берёте свою гугловскую таблицу, подключаете — и всё: приложение почти готово. А данные как вносили через Google, так и вносите — всё уже синхронизировано. UPD: В комментариях меня поправили - собственная БД Glide может работать и без связи с Goggle таблицами. Да, это верное уточнение. Собственная БД вполне функциональная, хоть и имеет несколько странный инструмент связи данных в разных таблицах.
• Пока нет возможности публикации в сторах, только PWA. Минусы у этого прежде всего маркетинговые. Объяснить пользователю, что установка ярлыка PWA-приложения на рабочий стол превращает его в нативное приложение — не самая простая задача. Так что если пользователи не фанаты вашего проекта или не сотрудники вашей команды, то только из-за PWA формата вы можете недополучить существенную часть своей потенциальной аудитории, что обидно, потому что ничего плохого в PWA формате нет. Но учить рынок — так себе затея. Плюсы — это отличный PWA, многим лучше PWA того же Adalo, по моему субъективному мнению.

Главное, что точка входа и понимание логики программы в 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 бесплатных тарифов быстро стало недостаточно в обоих инструментах, но следующего по стоимости тарифного плана хватило с лихвой:

• Glide — 32$ в месяц (на бесплатном — лимит по карте, скрытие данных зарегистрированных пользователей, всего 500 записей на все таблицы);
• Adalo — 50$ в месяц (на бесплатном — не подключить внешние БД, и вовсе 50 записей на все таблицы).

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

• Насколько хорошо продуман UI/UX дизайн в Airtable, настолько же он устарел в QuintaDB. Причины ясны: QuintaDB на рынке с 2008 года и уже не раз проходил через редизайн, но вся его база на прошлых решениях в области UI/UX дизайна и принципиально обновиться — очень непростая задача. Airtable — достаточно новый сервис, который смог на старте взять всё передовое. В остальном возможности обоих инструментов близки, а в ряде случаев у QuintaDB есть функции, которые нашему проекту необходимы, но на Airtable их нет.
• Несколько десятков типов колонок, реляционные связи, персональные отчеты, поиск, фильтрация, группировки данных в обоих инструментах сопоставимы, но снова — UX/UI значительно удобнее в Airtable.
• API есть у обоих инструментов, но у AirTable он хорошо интегрирован в Adalo: формулы для выборки, поиска и прочего не надо формулировать специальными командами API, а достаточно их использовать в настройках соответствующих компонентов самого Adalo. Все формульные выражения Airtable поддерживаются и в Adalo, когда внешняя БД на Airtable. Думаю, что этими формулами можно обойти такое существенное ограничение в Adalo, как отсутствие аргумента «или» — что важно, когда у тебя сложная система фильтрации данных из БД в конкретный пользовательский интерфейс.
• Предполагаю, что возможности формульных выражений в AirTable шире, чем в QuintaDb, как для очистки данных, полученных парсингом, так и для создания разнообразной статистики. Чувствуется, что Airtable развивает парадигму электронных таблиц, а QuintaDB развивает парадигму простоты использования БД.
• Оба сервиса позволяют использовать БД и для автоматизации бизнес-процессов, и в качестве проектного инструмента — информационные сущности, помимо собственных характеристик, могут иметь производственные статусы и отображаться в виде канбанов. Но если в QuintaDb это заложено на уровне возможностей инструментария, и ещё надо придумать, как из этого собрать решение, то в Airtable эта возможность оформлена в виде готовых блоков и функций, что существенно упрощает использование.

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

• Главная причина — на QuintaDb можно организовать пользовательские порталы и личные кабинеты, а на Airtable, без другого инструмента — нет. Это уже давнее решение QuintaDb, оно продумано и у него большой спектр специфичных для такой функции настроек, набор инструментов для интеграции ЛК на собственный сайт.
• Стоимость ощутимо ниже, особенно когда предполагается штат как внутренних редакторов, так и массив внешних пользователей. Тарифная линейка больше, чем у Airtable и гуманнее.
• Русскоязычная поддержка. Русский интерфейс, документация и поддержка уже многим упрощает жизнь, но хочу отметить оперативность и искренность в желании помочь специалистов службы поддержки. Всегда получал оперативную и очень толковую помощь.
• Зрелость сервиса. QuintaDB существует с 2008 года и имеет большой перечень локализаций и отдельные домены для ряда национальных зон. Думаю, что и как хостинг данных сервис прокачан достойно — по скоростям и надежности. По крайней мере, за 3 года моего знакомства с сервисом и работы с ним серьёзных проблем я не помню.

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 и прочее.

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

• Сложность входа. Нужен хороший технический бэкграунд и скиллы разработчика. Думаю, что этот инструмент потребует отдельного хорошего специалиста в команде. Не уверен, что подходит для тех проектных специалистов не из IT отдела, которым надо лишь расширить пул личных возможностей.
• Как я понял, Bubble пока не предоставляет возможности публикации в сторах без помощь других инструментов.

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

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

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

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

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

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

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

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

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

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

Пожалуй, это самый главный лозунг современного 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:

• Разработал конструкции и связей БД. Выбрал QuintaDB.
• Разработал сценарии синхронизации. Выбрал Integromat.
• Разработал пользовательские интерфейсы БД: авторский и редакторский порталы в QuintaDb.
• Разработал и развивал первичный прототип приложения в Adalo.

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

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

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

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

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

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

И тут:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Разработчики и программисты. Много рутины и начальных прототипов быстрее и проще решить инструментом зерокода. Благодаря зерокодингу будет хороший приток новых специалистов - придут те, кого останавливала необходимость на старте изучать код.
• Основатели технологических стартапов и продуктовые менеджеры. Зерокодинговые инструменты делают проще и быстрее проверку продуктовых гипотез и помогают передать задание разработчикам.
• Руководители любых бизнесов. Обучите ваших ключевых менеджеров инструментам зерокодинга и развитие бизнеса пойдёт быстрее и проще, так как возможности современных IT-решений станут доступнее.
• Линейные специалисты, менеджеры, управленцы среднего звена. Зерокодинг поможет решить ваши операционные задачи, круто прокачивает скиллы и компетенцию — soft skills, которые повышают вашу стоимость на рынке труда.

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

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

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

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