Убийца Excel: как no-code адепту подступиться к заказчику

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

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

Архитектура приложения в конструкторе «всё-в-одном»

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

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

airtable.com – замена Excel и Google-таблиц: этакий Excel на стероидах

creatium.io – конструктор сайтов, претендующий на «всё-в-одном»

bpium.ru – российский аналог Airtable с элементами автоматизации

directual.com – конструктор баз данных, процессов и форм

ideav.online/ru – конструктор баз данных и веб-приложений

Подобные сервисы предназначены для создания прототипов и MVP, но часто позиционируют себя как инструмент для полноценной разработки. И, надо заметить, на некоторых из них можно сделать серьезный проект, дотянув до продвинутой ERP-системы, и писать код при этом действительно придется мало.

Что умеют конструкторы no-code

Перечисленные сервисы обычно заявляют о таких ценностях:

1. Всё просто и интуитивно понятно даже для новичка

2. Можно быстро и самостоятельно собрать продукт «без кода»

3. Большое количество проектов и довольных клиентов

4. Если чего не хватает, то можно легко интегрироваться с другими сервисами

5. Хорошие отзывы реальных пользователей

6. Большое сообщество специалистов, готовых помочь

7. Доступно множество шаблонов и наработок, бесплатных и платных

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

Локальная лицензия на установку конструктора на серверах заказчика, включающая сопровождение – устранение дефектов и установка обновлений.

Договор на консультирование заказчика и/или организацию заказной разработки внешней командой, которую подбирает исполнитель.

Сопровождение – почасовая оплата пакетами по 10-20-50 часов. Это консультации и доработки по проекту, но чаще это просто нахождение в дежурном режиме в готовности быстро помочь в случае необходимости.

Наша целевая аудитория – бизнес от 50 до 700 человек, у кого есть свой отдел IT и/или бюджет для найма разработчиков со стороны. Чаще все таки разработкой занимаются свои сотрудники – 2-3 человека из тех, кто что-то программирует в компании, например, ERP и разную локальную автоматизацию. У них достаточно компетенций чтобы сопровождать IT-продукты или быстро написать что-то несложное.

Глоссарий

ЛПР – лицо, принимающее решение о покупке

Босс, ЛДПР – лицо, действительно принимающее решение (окончательное)

Действующие лица:

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

Босс – директор или владелец, он несет ответственность за компанию и управляет всеми её ресурсами. Его задачи: жизнеспособность бизнеса, чтобы отделы не конфликтовали, задачи выполнялись и был контроль.

Сотрудники – в основном, мощный костяк сопротивления переменам, просто люди, приспособившиеся к текущим условиям. Часто проект нацелен на уменьшение вреда от них (воровство, безответственность)

Энтузиасты – единичные сотрудники, ждущие перемен и помогающие проекту из совершенно разной мотивации

Потребность ЛПР – улучшать, укреплять и упрощать своё IT-хозяйство, в частности, внедрять и сопровождать новые продукты. Обычные его проблемы: нет нормальной управленческой отчетности, потому что программа многое не позволяет. Он следит за трендами IT и иногда изучает новые инструменты.

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

  • Чёткие временные и финансовые рамки проекта
  • Уверенность в успехе проекта
  • Значительное улучшение возможностей IT

Так возникает идея проекта, который состоит в замене главной IT-системы компании или создании новой большой системы для управления чем-либо ключевым (логистикой, заказами, договорами, объектами, проверками, аттестациями и т.д.). Например, давайте сделаем ERP или продвинутую CRM:

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

Проект возникает не от хорошей жизни. Часто у участников присутствует заметный скепсис, а в четверти случаев на стороне заказчика можно даже наблюдать некоторое отчаяние. В любом случае, у инициаторов нет уверенности в успехе – по статистике 84% IT-проектов завершаются не в срок, вне бюджета или с худшей отдачей, чем ожидалось.

В половине случаев (50%) у ЛПР есть некое подобие ТЗ, иногда (25%) проработанное до степени готовности к точной оценке. В 75% случаев есть эксели и подобные таблицы/материалы/системы, которые используются как суррогат задуманного проекта, и по которым можно в принципе понять что происходит и создать нормальное IT-решение.

ЛПР ищет решения на рынке, потому что и сам стремится улучшить своё положение, получить бонус, пополнить резюме.

Как правило, выбор ЛПР таков, если смотреть по убыванию его риска:

А. Развивать самописные системы, которые есть в компании вместе с кучей экселей

Б. Закупить или доработать продукт из линейки 1С

В. Ничего не делать

Г. Найти готовый продукт

Д. Найти новый, более мощный, инструмент разработки или технологию

Е. Заказная разработка под ключ на стороне

В последних трёх случаях риск провала достаточно высок, и надо убедить ЛПР, что он всё предусмотрел и всё очень четко понимает. В этих случаях также наиболее высок риск саботажа со стороны сотрудников клиента.

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

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

Б. 1С – очень дорого, сотни тысяч за точечные доработки или миллионы за проект и сопровождение, найм дорогостоящих консультантов, проблемы при обновлении

В. Ничего не делать – нет бонусов и удовлетворения амбиций, недовольство начальства

Г. Готовый продукт – сотни тысяч за коробку, которую придется долго дорабатывать, настроить под себя – нереально, есть ограничения, из которых не все известны сразу

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

Е. Заказная разработка – миллионы за проект и, если мы говорим о большом проекте в рамках компании, этот вариант весьма редко рассматривается, потому что люди со стороны сделают всё плохо, не зная специфики и не беря полную ответственность

Где здесь мы

Мы – это вариант Д, но с привлечением консультантов и, возможно, покупкой лицензии.

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

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

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

Ещё небольшая часть уже находится в отчаянии, потому что уперлись в фатальные ограничения, например:

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

Знакомство с продуктом

Итак, ЛПР в надежде попадает в мир ноукода и начинает знакомство:

  • Понимает, что это за продукт и из чего он состоит, условия работы
  • Листает примеры решений и узнает среди них свой будущий проект
  • Убеждается, что компания работает давно и имеет достаточно клиентов
  • Тарифные планы продуманы и покрывают все случаи
  • Видит преимущества продукта в разных аспектах
  • Возможно, регистрируется в 1 клик, чтобы пощупать сервис
  • Может выбрать подходящий вариант начала работы
  • Решается заказать консультацию
При всей высоте ожиданий, простые таблицы с цветными метками радуют глаз

Если первый пункт сходу не сработал, то, вопреки мнению директологов, клиент – ЛПР – все таки прокручивает лендинг дальше. Это удивительная вещь, но мы получали звонки и выслушивали примерно такое: я просмотрел весь ваш сайт, почти ничего не понял, расскажите мне!

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

  • 100% под себя, в отличие от коробки, при примерно той же стоимости
  • С небольшим бюджетом, на порядок ниже, чем с 1С или заказной разработкой
  • Дальнейшее обслуживание будет недорогим и понятным

Что можно считать преимуществами варианта с конструктором

Основное – стоимость (скорость) разработки и доработок.

Второе – минимум ограничений, свойственных конструкторам.

Третье – высокая скорость работы и низкие требования к ресурсам.

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

Обычно на первой встрече (очно или в зум/мит/мост) мы показываем многие вещи на лету: загружаем данные, настраиваем структуру данных, раздаем права, делаем отчеты и формы, выводим данные в виде графиков, объясняем работу шаблонизатора и SPA (режим Single page application).

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

Например, мы загружаем в базу данных пару десятков тысяч записей за полминуты, а потом показываем какова была нагрузка (порядка 20% ЦПУ и 80МБ памяти) на этот сервер, в котором 1 ядро и 1ГБ памяти, и на котором сейчас работают и другие пользователи.

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

Предложение на сайте, которое мы выдаем разогретому клиенту

  • Зарегистрироваться в 1 клики и протестировать сервис
  • Связаться с нами (телефон, мессенджер, заказ звонка, письмо)
  • Купить пакет аналитики 5-10 часов, чтобы получить оценку и затем ТЗ
  • Посмотреть дополнительные материалы (видео, примеры, статьи и т.д.)

Онбординг

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

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

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

  • Позвонить по телефону на сайте
  • Обратиться в телеграм с сайта
  • Заказ звонка
  • Написать письмо

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

После контакта идет заказ демонстрации или счета на оплату первой фазы – прототип, проработка ТЗ, иная аналитика. Обычно первая фаза – это 30-50 тысяч предоплаты, чтобы проверить на что способен подрядчик.

Что интересует ЛПР

В хорошем случае клиент достает ТЗ или его аналог и начинает спрашивать по списку – можно это, а это, а это, а с этим как? Иногда у него есть эксели, которыми он может поделиться. Бывает поток мыслей в Miro, MindMap или чём-то подобном. В худшем случае – это скрины экранов.

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

Список вопросов примерно такой:

  • Базовые возможности. Что, у вас можно хранить таблички? А можно поля к ним добавлять? А связывать? А есть ли целостность данных? А как это выглядит – симпатично или нет? А справочники можно?
  • А сколько данных может хранить система? А как сильно она замедляется с ростом объемов? Долго ли вычислять что-то в миллионах записей?
  • Как делается импорт данных? А можно автоматически? А в каких объемах можно? А экспорт есть? А в 1С выгрузить/загрузить как?
  • Как организовано программирование бизнес-процессов? Как защитить их от дурака? Как вообще программируется изменение данных и всякие расчеты внутри?
  • Что с безопасностью? Ролевая модель есть? А можно дать доступ к отдельным полям? А можно назначить клиента менеджерам? А чтобы менеджер видел только своих клиентов? А чтобы босс видел всех?
  • Как сделать красивые рабочие места? Как сделать автоматизацию – взаимозависимые поля, расчеты и всё такое? Как перенести сюда формулы Excel?
  • Сколько это стоит – лицензия? А какие ограничения – по количеству пользователей, транзакций, установок и т.д.? Можно ли править код? Тестовые и прочие стенды сколько стоят?
  • Какой квалификации нужно быть нашему программисту, чтобы по вашим подсказкам сделать такой проект? А мелкие доработки пользователь сможет – отчет сделать или формулу поменять? А тут как с защитой от дурака?
  • Как будет организовано сопровождение? Какое время ответа в случае проблем? Как оформляется? Какая ваша ответственность?
  • Кому будет принадлежать интеллектуальная собственность на результат проекта? А мы сможем её продавать?
  • А что будет если вы завтра закроетесь, а мы подсели на вашу иглу? А как нам это тогда сопровождать? Где нам взять специалистов по этому конструктору?
  • А не изменятся ли ваши тарифы? Какие мы можем получить гарантии цен?

После ответов на все эти вопросы (те самые 2 часа) у ЛПР не остается сомнений в пригодности продукта и он занят мыслями, как будет продавать это Боссу.

Упрощенная структура данных в no-code конструкторе

Оформление и стоимость

Далее ЛПР идет к Боссу и продает ему этот выбор. Босс не колеблется с решением, если ЛПР сам уверен и может убедительно ответить всего на 2-3 вопроса. В рамках компании это незначительные затраты и всех больше волнуют риски, негатив и принципиальная реализуемость проекта. Торга обычно нет, он не имеет смысла, Босс и ЛПР воспринимают подрядчика как своего рода спасителя и не хотят его пока прессовать.

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

Ориентировочная стоимость проекта при выполнении его силами заказчика с помощью консультантов-аналитиков будет от 400 до 600 тысяч рублей, реже – в пределах миллиона рублей.

Для сравнения, подобный проект при заказной разработке будет стоить от 1.5 до 3 млн рублей при тех же существенных рисках.

Сопротивление программистов

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

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

Результаты опроса на Хабре в 2021

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

Выводы

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

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

Заказчикам мы предлагаем взглянуть смелее на подобные предложения и не пожалеть немного времени на тестирование гипотезы с конструкторами. А разработчикам мы советуем изучить направление no-code и low-code разработки – там уже есть работающие инструменты и методики.

Спасибо!

Вы бы доверили проект конструктору без кода?
Да
Нет
Возможно
Только самый простой проект, ради эксперимента
А что такое конструктор без кода?
Показать результаты
Переголосовать
Проголосовать
0
24 комментария
Написать комментарий...
Bo.G

1. Конмтрукторы "без кода" способны лишь на презентационные, статичные во времени типовые микрозадачи.
Любое, даже незначительное отклонение от типового процесса влечёт за собой два варианта для этих систем:
а) этого сделать нельзя
б) пилятся костыли
2. Ниюе сущесивует ни одного "типового" бизнеса. У всех - свои нюансы. Именно по этому нет ни одной ERP-конструктора, способного "из коробки" работать без "допилов".
Именно по этому десятилетия попыток энтузиастов и корпораций (Micrisoft, Oracle и тд) с бюджетами и ресурсами, которые вам во сне не снились иак и не смогли этого слелать.
Все свелось и сводится к предоставлению разного рода инструментария для разработчика и целой отрасли этих самых прикладеых разработчиков и интеграторов.
В Excel в свое время, писались очень большие и разветвленныеприложения и работали годами.
Для БД существую настольные конструкторы, типа Access и тд... имя им - легион.
В своёвремя, лет 20 назад, был популярен такой "революционный" пролукт, как Lotus Notes. Заявлялся, как первая ORDBMS, содержащая и интерфейсы и поддержку всех плюшек реляционных БД.
И где оно?
У вас не те вопрсы озвучаны.
1. Что показывают нагрузочные тесты при активном обновлении данных (какой то оптово-розничный склад у которого 100500 перемещений, отгрузок, приходов). Какое время отклика системы?
Самые "дорогостоящие" мутабельные операции: обновление и удаление.

2. Как быстро можно организовать интеграции с внешними системами не являющимися "типовыми".
1. Купила контора сервис МП, а у них свой протокол обмена.
2. Хочет клиент отправлять sms через свой шлюз. Как ему настройку сделать no-code?
3. Обновился протокол обмена с кассовым оборудованием (какая-то новая супер маркировка — "мамой клянусь" знак) , а оборудованиеюя много и оно старое, но можно его донастроить. Как быть no-code?

Все ваши междумордия это пыль по сравнению с задачами межсистемной интеграции

Ответить
Развернуть ветку
Alexey Sidorov
Автор

По п.2 "Что показывают нагрузочные тесты" давайте посмотрим:
https://www.youtube.com/watch?v=l0eg2xuC9Ks

Ответить
Развернуть ветку
Alexey Sidorov
Автор

Ну и вот про это ещё: "оптово-розничный склад у которого 100500", вы тут прямо угадали про количество:
https://www.youtube.com/watch?v=EHYro4QZa0Y

Ответить
Развернуть ветку
Bo.G

Посмотрел ролик.
А где в ролике метрики загрузки железа? и вообще характеристики железа и софта?
Что по дискам (самое узкое место всех ИС), по памяти, по cpu, как используется (и используется ли) многопоточность.
Какой пул софта в вашей системе, как он может быстро масштабироваться, что со standalone и т.д.

500 млн. это так себе.
что за "таблица пользователей"? какие данные туда добавляются? какова ее степень.
Если это БД, то как, чем и с чем она связана.
а что с модификацией данных? добавление это не самая дорогостоящая операция.
префиксный поиск - не покажет валидную просадку в отличии от инфиксного поиска с мета символами.

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

Данный пример показывает (вроде как) справочную информацию (логов о том, что кто-то проявляет активность мы не видим).

Посмотрел второй ролик. То же самое.
100 тыс - это не много. Опять мы ничего не видим, кроме каких-то непонятных действий пользователя. Что именно хочет показать пользователь? Что при "нагрузке" быстрый отклик интерфейса?

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

Ответить
Развернуть ветку
Alexey Sidorov
Автор

Давайте так, вот вам живой стенд, параметры его железа написаны внизу страницы. Как было загружено это железо в течение дня, я вам могу показать даже онлайн на хостинге, если есть интерес.
https://ideav.online/sber

Ответить
Развернуть ветку
Bo.G

Спасибо.
Для примитивного теста я сделал следующее.
Открыл 10 вкладок и последовательно нажал на каждой кнопку "Сгенерировать записи".
Потом свел все в простой график.

Смотреть надо снизу вверх по легенде (внизу находится первая по порядку запущенная и далее вверх на первом и втором графике одинаково расположение)

Что мы тут в самую грубую прикидку видим?
Простая генерация записей (добавление 5000 записей в каждой процедуре) при подключении 10 пользователей
просаживает время отклика в 2 раза.
При этом производительность (добавление данных в единицу времени) представляет классическую обратную корелляцию
(очередь растет, время увеличивается).
И тоже приблизительно в 2 раза (если брать средние на графике значения. у первых потоков до 500 кортежей\секунду, у последних - 200 и меньше.

Итого: 10 не очень активных пользователей при неизвестной доп нагрузке на железо просаживают производительность в 1.5-2 раза.
что будет, когда подключатся еще 10 пользователей и будут добавлять не 5000 а 30,40 и т.д. тыс записей?
Обновлять данные по ним (по большим периодам), делать отчеты?

Ответить
Развернуть ветку
Alexey Sidorov
Автор

Отлично, спасибо за содействие!
Давайте посмотрим загрузку ресурсов этого, повторюсь, ЕДИНСТВЕННОГО ядра с 1ГБ памяти, которое облуживало вас и остальных пользователей. Прилагаю графики за сегодня, и наша с вами недавняя активность на них заметна.
Надеюсь, вы не будете сильно строги, что ядро мальца замедлилось на 10 вкладках и десятках тысяч вставляемых записей? Там (по секрету) защита от DDoS.
Статья про то, что бизнес может поставить этот сервис локально, подкинуть туда ядер и памяти, и вы вообще его не сможете нагрузить до хоть сколько-нибудь заметного замедления.

Ответить
Развернуть ветку
Alexey Sidorov
Автор

Приветствую! Спасибо за развернутый комментарий.
По п.1 - в статье имеются в виду не конструкторы из кубиков, а конструкторы самих кубиков: когда вы делаете что-то с чистого листа. Там особо нет ограничений, например вот обработка бухгалтерской проводки, наподобие 1С, вполне себе нетипичная и нетривиальная задача:
https://www.youtube.com/watch?v=K7RpGL35k_4

Ответить
Развернуть ветку
Bo.G

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

Ответить
Развернуть ветку
Alexey Sidorov
Автор

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

Ответить
Развернуть ветку
Alexey Sidorov
Автор

Ещё по этому пункту: 2. Хочет клиент отправлять sms через свой шлюз. Как ему настройку сделать no-code?
Вот так можно отправить СМС через свой или чужой шлюз:
https://help.ideav.online/#rec220707188

Ответить
Развернуть ветку
Alexey Sidorov
Автор

Про этот пункт ещё: 3. Обновился протокол обмена с кассовым оборудованием.
No-code вам тут дает АПИ, и программист всегда может написать адаптер для вызова АПИ на стыке систем. Да, немного кода будет, поэтому ввели понятие Low-code: накликать 95% и 5% накодить — это быстрее и дешевле, чем 100% накодить.

Ответить
Развернуть ветку
Bo.G

Но ведь ваша статья называется "Убийца Excel: как no-code адепту подступиться к заказчику"
и тут вы говорите уже low-code
и .. дальше.. разработчик не найдет функционала в вашем интерфейсе разработки (такое сплошь и рядом, т.к. реализуются то, что актуально в данный момент) и он начнет вам задавать вопросы, но вы не сможете\захотите это реализовывать и тогда начнутся гонки на костылях.

Ответить
Развернуть ветку
Alexey Sidorov
Автор

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

Ответить
Развернуть ветку
Сергей Леопольдович

Кто-то в почти здравом уме работает с Excel в котором 1 млн строк?

Ответить
Развернуть ветку
Alexey Sidorov
Автор

До 1 млн обычно дело не доходит. Локально таблица Excel ещё может это, а коллективно - уже нет. Например, Google sheets падает уже на 150-200 тысячах записей. К нам приходили такие парни (учитывают стримы артистов на площадках и ведут взаиморасчеты) - у них Гугл таблицы грохнулись на 150+ тысячах строк, а сейчас у них под 5 млн уже в Интеграле.

Ответить
Развернуть ветку
Сергей Леопольдович

Спсб, теперь я знаю, что есть те кто думает что Excel бесконечен

Ответить
Развернуть ветку
Вячеслав Дмитриев

у нас все время так думают)))

Ответить
Развернуть ветку
Alexey Sidorov
Автор

Да, есть такие, кто пытался. Это биллинг, маркетплейсы, кто работает с котировками, если привести только несколько примеров.

Ответить
Развернуть ветку
Валентин Потапов

До 2017 года это не удавалось никому. С 1982 году работал на "подобном для задач того времени" начиная с ес-1022

Ответить
Развернуть ветку
Alexey Sidorov
Автор

Да, чего только не было в те времена. Есть вот хрестоматийный случай, правда на 10 лет позже, и это как раз та проблема, которую, наконец, решили в этом веке уже:
https://www.red-gate.com/simple-talk/opinion/opinion-pieces/bad-carma/

Ответить
Развернуть ветку
Andrey Ilinskiy

Всем привет!
Студия Sinneo (https://sinneo.dev/) создаст вам No-code продукт: маркетплейсы, соц.сети, обучающие платформы, мобильные приложения, CRM/ERP системы и другие. Также недавно начали работать с AI - сделаем интеграцию с Chat GPT для решения ваших задач на стороне продукта.

Связаться с нами вы можете через виджет на сайте.

Ответить
Развернуть ветку
Alexey Sidorov
Автор

Бэкенд на чем делаете?

Ответить
Развернуть ветку
Andrey Ilinskiy

Если речь идет о вебках, делаем на Bubble - там бэк на стороне Bubble.
Если говорим о мобилках, в последнее время работаем только с Flutter Flow - там бэк на файрбэйсе.

Ответить
Развернуть ветку
21 комментарий
Раскрывать всегда