Трибуна
Pavel Ershov
4309

«Кубики» вместо кода — год спустя

Ровно год назад мы опубликовали пост на трибуне, в котором рассказали историю low-code платформы Directual. Сегодня я поделюсь тем, что мы узнали на практике за год, и куда мы дальше двигаемся. Спойлер: кровавый энтерпрайз ушел на второй (и даже третий) план, а облачная версия платформы — на первый.

В закладки

Что такое low-code?

Это подход, когда ИТ-продукты можно разрабатывать в визуальном интерфейсе. Также для этого в ходу близкие термины no-code или zero-code. Идея «накидывать приложение мышкой» появилась давно, но только в последнее годы такие продукты стали использоваться массово. Например, сейчас никто не кодит лендинги — их собирают на Tilda или Readymag. Даже наш текущий сайт на 100% сделан только дизайнером на no-code платформе Webflow. Предпосылки для такого подхода очевидны: программисты дорогие, плюс гибкость становится решающим фактором. Подвигать элементы мышкой и задеплоить по кнопке — это 5 минут. Писать ТЗ, ставить задачу и тестить — это дни, в лучшем случае.

Я бы выделил три группы low-code платформ:

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

Мы как раз сделали фокус на последнем пункте. Исторически, в нем меньше всего конкурентов, и он самый «программистский». Например, Firebase от Google можно частично отнести сюда. Или более простой Airtable. Причин неразвитости этого сегмента несколько. В том числе — стереотип, что на конструкторах можно сделать поделку на коленке, а для нормального решения надо нанимать программистов. Мы в Directual на своем примере доказали, что на современных low-code решениях можно делать как MVP стартапа, так и промышленные системы.

Смена фокуса в 2019

Начинали 2019 мы так:

  • Крупные заказчики, для которых наша же команда делала на платформе проекты: ПИК, МТС. Для примера, среди решений были: внутрення база знаний (замена Confluence, в котором не хватало системы согласования), конструктор договоров, оптимизация логистики панелевозов.
  • Пайплайн разработки строился, в первую очередь, под нужны консалтинг-офиса. Иногда в жертву функциональности приносилось удобство и продуманность фичи.
  • Стратегия «заработать денег на крупняке», а потом уже инвестировать в публичное облако для широкого рынка.

Что из этого вышло — далее.

Цикл продажи в крупную компанию — год. Минимум. За этот год надо выстроить отношения, сделать бесплатный пилот (для которого, возможно, нужны доработки в платформу), договориться с безопасниками и айтишниками об установке в контур. И под это нужен штат: продажники, инженеры, менеджеры. Собственно, половина консалтинг-команды трудилась на разных пресейлах.

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

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

В конце 2019 года мы решились на следующее:

  • Сокращаем всю команду внедрения. Часть устраиваем к клиентам. Часть — переводим на партнерские отношения.
  • Текущие проекты не бросаем, но делаем силами партнеров-студий.
  • На основе отзывов, которые мы получили от 300 облачных бета-пользователей, делаем новую версию платформы. И открываем с ней публичное облако.
  • К релизу готовим качественные учебные пособия.

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

Что можно сделать на Directual?

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

Что полностью разворачивается и настраивается на Directual:

  • База данных. Отлично масштабируется, можно делать импорт/экспорт в Excel, ставить слушатели на внешние SQL-базы. Тут же хранится и ролевая модель, и файлы, и логи приложения. Под капотом: MongoDB (для данных) и PostgreSQL (для метаданных).
  • Логика бэкенда. Наши сценарии (потоковая обработка данных) + отчеты (пакетная обработка). Из сценария можно постучаться во внешнюю систему через шаг http-запроса.
  • API и RBAC. По-сути — один модуль, исторически называется Security layer. Это конструктор API с кучей настроек: фильтры, сортировки, синхронные сценарии и т. д. Для Академии пришлось делать два отдельных урока по API-конструктору.
  • Портал Directual. Фича пока в альфе. Это то, что просили наши бета-тестеры. Не все готовы программировать свой фронтенд. Портал — это простой шаблон сайта, который поддерживает авторизацию. На страницы этого сайта можно накидывать компоненты, взаимодействующие с данными через API. Пока компонента три: текстовый блок, форма и отображение данных в виде карточек. Вот пример портала на Directual . Еще удобная функция: любую страницу можно вставлять как iframe к себе на сайт (в том числе собранному на конструкторах типа Webflow или Tilda).

Что не делается на Directual:

  • Тонкий клиент веб-приложения, для которого платформа работает как REST-интерфейс. Хотя, как я писал выше, можно вставлять embedded-элементы. Сам фронт можно делать хоть на чем: React, Angular, Vue, JQuery. Для ReactJS мы сделали и выложили в open source: библиотеку компонентов Directual.design и boilerplate для упрощения работы с платформой как бэкендом.
  • Мобильное приложение. Разрабатывается отдельно нативно или PWA, но может работать с теми же API-методами. Пример недавно запущенного iOS-приложения с бэком на Directual — Up&out (это что-то среднее между Tinder и Linkedin).

Для эффективного использования полезно знать основы проектирования баз данных и базу JavaScript (достаточно самого простого курса на той же Codecademy).

Предвосхищая вопрос: «Почему все на английском?», отвечу. Делать материалы на двух языках вдвое дольше. Поэтому мы пока выбрали один — международный.

Сколько стоит?

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

Тариф Startup. Дешево и сердито — $30 в месяц. С лимитами по нагрузке, которых вполне хватит на запуск MVP. Можно включить on-demand биллинг, тогда приложение не будет останавливаться при достижении лимитов, но будет сниматься дополнительная плата за превышение потребляемой мощности.

Business. За $300 вы получите в 20 раз выше лимиты, в 2,5 раза меньше цену за превышение. И SLA на 99% uptime. На таком тарифе у нас работают ребята из Schlumberger.

Что дальше?

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

Тактически, будем делать упор на продвижение через контент-маркетинг, блог и полезные материалы формата «пошаговая инструкция как с помощью Directual и синей изоленты запилить стартап». Также хорошо видно, что развитии low-code продуктов большую роль играют сообщества пользователей. Присоединяйтесь к нашему — платформа уже открыта для регистрации!

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

Также мы рады сотрудничать с веб-студиями. Обучим, поделимся лицензионными платежами, и даже клиентов можем подогнать.

{ "author_name": "Pavel Ershov", "author_type": "self", "tags": [], "comments": 33, "likes": 35, "favorites": 130, "is_advertisement": false, "subsite_label": "tribuna", "id": 118044, "is_wide": false, "is_ugc": true, "date": "Sat, 11 Apr 2020 12:06:54 +0300", "is_special": false }
Briskly
PR в стартапе: как и кому рассказать о себе после выхода на рынок?
Как попасть в топовые СМИ, зачем раскручивать основателя и почему вы должны быть первым, кто расскажет вашу историю…
Объявление на vc.ru
0
33 комментария
Популярные
По порядку
Написать комментарий...
3

Я ботика могу запилить 😂

Ответить
1

Low code интересная ниша.
Ребят, а есть сравнение с другими платформами? Тем же Bubble

Ответить
2

Баббл прекрасен для несложных решений. Постараемся написать сравнения лоу-код платформ в ближайшее время.

Ответить
0

Лоу код - по определению для несложных решений.

Ответить
2

А автомобиль никогда не станет популярнее лошади!

Ответить
1

Некорректное сравнение.

Ответить
0

Я хочу ездить - вот вам готовый автомобиль.
Я хочу быстро ездить - ну ок, вот вам быстрый автомобиль.
Но мне ещё нужен откидной верх - быстрый кабриолет ждёт вас.
И ковш как у экскаватора, ах да, он должен быть на гусеницах - эм... У нас нет вариантов для вас, создайте сами..

И тут Лоу код уходит на второй план.

Ответить
1

В итоге, у вас получился конструктор БЭ. БД вы взяли готовый, ФЭ тоже взяли готовый. Продукт полюбому придется в сотнях маст допиливать, надстраивать и интегрировать. Очевидный вопрос - зачем? Какую проблему конечного потребителя вы решаете?

Ответить
0

нет боли в этом и проблема )

Ответить
0

За LCDP будущее, но для хорошей реализации надо быть гением.

Ответить
2

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

Ответить
2

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

Ответить
0

Нет, это невозможно, потому что любое ПО это не только один код, а деньги, деньги и ещё раз деньги. Что вряд ли возможно в полном объеме для опенсорса

Ответить
0

Весь опенсорс построен на платном обслуживании бизнеса. 

Ответить
0

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

Ответить
0

 Ну если вести единый стандарт интеграций, как например с портами подключения на пк (usb), телефонах и т. д.

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

Ответить
2

Это почти как SQL задумывался как язык для домохозяек. Домохозяйки на нем так и не пишут, но подход реализован необычный)

Ответить
1

О, Павел, помню, как общались с вами по решению для email-маркетинга и dmp лет 5 назад. ( http://ritworld.com/proekt-directual-pobedil-v-nominacii-sberbank-awards-texnologii-budushhe-go-dlya-biznesa-v-ramkax-generations-2015/  ) те же блоки и схемы, входной порог от 3 млн.р., безграничные возможности в области решения узких задач. Название продукта решили оставить? Желаю удачи в этом pivot'е!

Ответить
1

Да, это развитие технологии. Спасибо!

Ответить
0

 кровавый энтерпрайз ушел на второй (и даже третий) план, на первое место выходят веб-студии

Намеренно убегаете от денег? То есть у вас нечто вроде социального проекта, призванного дать рынку еще один клевый, но невостребованный инструмент?

Ответить
1

Вы, наверное, не дочитали. Там описано, что энтерпрайз оттягивает на себя все ресурсы от продукта. И клевый инструмент по определению будет востребованным, иначе он не клевый на самом деле.

Ответить
1

клевый инструмент по определению будет востребованным

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

Ответить
0

клевый инструмент != востребованный. Что вы как в детском саду, честное слово ну.

Ответить
1

Зашёл к автору на его сайт, посмотрел видеоролик "О нас".
Девочка фигуристая очень понравилась.
К сожалению, как все разработчики, автор ничего не понимает в продажах своего сервиса.
Написал им предложение в Фейсбуке.
Как получу от них ответ - напишу здесь свой отзыв о клиенто-ориентированности этой компании.

Ответить
1

Как по мне, так это все мерзость. Из той же оперы, что и визуальный интерфейс мышкой накидывать. Как в Visual Basic или Storyboard в Xcode. Хорошо, что в свифт с приходом SwiftUI от этой дурной практики отказались. 

Ответить
0

Какому бизнесу это может быть интересно? В документации перекати-поле.
Нет, серьёзно - пусто: 1 заголовок и 1 скриншот: https://readme.directual.com/getting-started/app-interface-overview/reports

Ответить
1

Документацию приводим в порядок!
А по вопросу: какому бизнесу может быть интересно создание ит-продуктов быстрее и дешевле?

Ответить
1

Пока для себя отметил, что сгенерировать проект на Java или .Net по шаблонам даст бизнесу больше, чем предложенное решение.

Ответить
0

Дешевых генераторов дешевых IT продуктов уже очень много на рынке. Чем ваш лучше?

Ответить
0

У вас на странице https://readme.directual.com/features техписы придумали новый почтовый протокол - STMP 

Ответить
1

Спасибо, доку приведем в порядок

Ответить
0

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

Ответить

Прямой эфир