Когда в проекте два квадратика, то легко написать всеобъемлющее ТЗ. Когда мы говорим о большом процессе, многое создается по ходу работы, которая длится годами. Отслеживание дублирования превращается в нетривиальную задачу.
На самом деле довольно часто используются low-code решения в больших бизнес-процессах, потому что так проще взаимодействовать с аналитиками и другими не-программистами. Им становится проще получить ответы на вопросы о том, как работает процесс.
Много компаний сейчас пошли в эту сторону, так что ваш шанс поработать с low-code возрастает.
Уточните, пожалуйста, вы имеете ввиду ТЗ на какие системы? На создание low-code платформы? Или на создание системы на платформе? Хочу понять сценарий, который вы имеете ввиду
Мы довольно часто используем, например, Camunda в задачах, где длинные бизнес-процессы. Могу для примера привести Order Management System (OMS) в екоме и ритейлере. У заказов есть разные статусы и условия перехода по этим статусам. Удобно бизнес-процесс описать визуально, а начинку сделать обычным кодом
Я думаю, что это прекрасная ниша и нужно писать на коленке на low-code MVP, чтобы проверить гипотезу. Но с самого начала надо обсудить с инвесторами, что это прототип, иначе можно обмануть ожидания. Есть хорошая картинка на тему, прикрепляю к комментарию.
Я бы не назвал UiWebKit платформой. Это скорее набор отдельных компонентов. У них же нет среды выполнения какой-то логики, кроме логики самих виджетов?
График условно линейный. Чтобы он был линейный нужно еще побороться. Если руки растут из правильных мест, то можно управлять сложностью. Если нет, то ничего не спасет. Но при low-code, когда нет рефакторинга и автотестов, ничего не поможет.
А в этих системах есть какая-то бизнес-логика отличная от стандартной? Может там цена ошибки так высока, что ты можешь брать только мега-отточенные и проверенные кубики, а не делать свое на коленке?
Как раз проблема в том, что они могут быть большими. Вы удивитесь сколько людей и компаний верит в то, что критически важные для бизнеса вещи, можно сделать в визуальном редакторе. Собственно, поэтому я эту статью и написал :)
На 100% и всеобъемлющее надеяться не стоит, но надо же быть уверенным до релиза, что система работает. Какой вы видите способ? Надеяться, что кто-то из аналитиков написал достаточно тестов после вашего недельного обучения? Как при этом делается релиз?
@eutistспасибо за пример, это интересный опыт. Не знал, что в этом мире есть такие островки. Заодно и стало понятно откуда ноги растут благодаря @Amor-roma
Да, я согласен, что Camunda где-то на грани. Теоритически в ней можно обойтись и без кода, но часто приходится добавлять обработчики. Тут я привел пример с Camunda, чтобы обесопасить тех, кто возьмет ее в работу, от того, чтобы писать код внутри этой платформы. Иначе этот скрытый код будет очень сложно обрабатывать.
Спасибо за комментарии. У вас чувствуется опыт за плечами.
Если говорить о том, во что я верю, то я скорее отдаю предпочтение набору готовы микросервисов с понятным входом и выходом. Я был бы готов платить за такие мини-инструменты и комбинировать их в своих системах. Что-то типа https://dadata.ru/ или https://kontur.ru/focus/api/how-to-work. Если бы таких сервисов с API было достаточно много, то и время разработки можно было сократить, переложив часть работы на внешние сервисы.
Правда при этом мы получаем новые точки отказа, но тут уже всё зависит от того, как мы построили свою систему, как мы реализовали fault tolerance и где мы подумали об SLA в нашей системе и какое SLA обещают внешние сервисы. В целом, я думаю, что это может сработать.
вокруг него нет всего того, что позволяет разработке сохранять адекватную стоимость внесения изменений и эксплуатации
Плюсую! В low-code первая версия выглядит обнадеживающе, а потом резкий рост сложности убивает проект. Когда-то писал об этом статью https://blog.byndyu.ru/2013/12/it.html
Я понимаю, что вы говорите. Да, можно обучить не-QA делать работу QA и этот человек будет писать какие-то тесты. Но что нам нужно от автотестирования в конечном счете? Я подразумеваю, что перед выкладкой на прод запускается набор тестов, который говорит, что ВСЯ система работает как надо. Тогда не нужен ручной регресс. Сделает ли непрофессиональный тестировщик такую работу?
Я бегло посмотрел инструмент. Если я правильно понял, вы предоставляете функционал для типовых задач розничного бизнеса. Что-то типа 1С в интерфейсе. Если вашим клиентам хватает кликов в интерфейсе, то все эти клиенты примерно одинаковые и, видимо, не такие большие как может показаться. Например, Леруа Мерлен не взяли бы себе ваш WMS (не в обиду вам, там просто очень много специфики, которую не накидаешь в интерфейсе).
Если вашим клиентам достаточно кликать в интерфейсе и не надо писать код, то у вас отличное low-code решение под вашу нишу. Если брать график, то решения заказчиков не уходят в "красную" зону.
С 1С не приходилось работать. А какая там специфика?
Когда в проекте два квадратика, то легко написать всеобъемлющее ТЗ. Когда мы говорим о большом процессе, многое создается по ходу работы, которая длится годами. Отслеживание дублирования превращается в нетривиальную задачу.
На самом деле довольно часто используются low-code решения в больших бизнес-процессах, потому что так проще взаимодействовать с аналитиками и другими не-программистами. Им становится проще получить ответы на вопросы о том, как работает процесс.
Много компаний сейчас пошли в эту сторону, так что ваш шанс поработать с low-code возрастает.
Уточните, пожалуйста, вы имеете ввиду ТЗ на какие системы? На создание low-code платформы? Или на создание системы на платформе? Хочу понять сценарий, который вы имеете ввиду
Мы довольно часто используем, например, Camunda в задачах, где длинные бизнес-процессы. Могу для примера привести Order Management System (OMS) в екоме и ритейлере. У заказов есть разные статусы и условия перехода по этим статусам. Удобно бизнес-процесс описать визуально, а начинку сделать обычным кодом
Я думаю, что это прекрасная ниша и нужно писать на коленке на low-code MVP, чтобы проверить гипотезу. Но с самого начала надо обсудить с инвесторами, что это прототип, иначе можно обмануть ожидания. Есть хорошая картинка на тему, прикрепляю к комментарию.
Я бы не назвал UiWebKit платформой. Это скорее набор отдельных компонентов. У них же нет среды выполнения какой-то логики, кроме логики самих виджетов?
Похоже на правду
Имеются ввиду метрики, например, Sonar.
График условно линейный. Чтобы он был линейный нужно еще побороться. Если руки растут из правильных мест, то можно управлять сложностью. Если нет, то ничего не спасет. Но при low-code, когда нет рефакторинга и автотестов, ничего не поможет.
А в этих системах есть какая-то бизнес-логика отличная от стандартной? Может там цена ошибки так высока, что ты можешь брать только мега-отточенные и проверенные кубики, а не делать свое на коленке?
Как раз проблема в том, что они могут быть большими. Вы удивитесь сколько людей и компаний верит в то, что критически важные для бизнеса вещи, можно сделать в визуальном редакторе. Собственно, поэтому я эту статью и написал :)
На 100% и всеобъемлющее надеяться не стоит, но надо же быть уверенным до релиза, что система работает. Какой вы видите способ? Надеяться, что кто-то из аналитиков написал достаточно тестов после вашего недельного обучения? Как при этом делается релиз?
@eutistспасибо за пример, это интересный опыт. Не знал, что в этом мире есть такие островки. Заодно и стало понятно откуда ноги растут благодаря @Amor-roma
Да, я согласен, что Camunda где-то на грани. Теоритически в ней можно обойтись и без кода, но часто приходится добавлять обработчики. Тут я привел пример с Camunda, чтобы обесопасить тех, кто возьмет ее в работу, от того, чтобы писать код внутри этой платформы. Иначе этот скрытый код будет очень сложно обрабатывать.
Спасибо за комментарии. У вас чувствуется опыт за плечами.
Если говорить о том, во что я верю, то я скорее отдаю предпочтение набору готовы микросервисов с понятным входом и выходом. Я был бы готов платить за такие мини-инструменты и комбинировать их в своих системах. Что-то типа https://dadata.ru/ или https://kontur.ru/focus/api/how-to-work. Если бы таких сервисов с API было достаточно много, то и время разработки можно было сократить, переложив часть работы на внешние сервисы.
Правда при этом мы получаем новые точки отказа, но тут уже всё зависит от того, как мы построили свою систему, как мы реализовали fault tolerance и где мы подумали об SLA в нашей системе и какое SLA обещают внешние сервисы. В целом, я думаю, что это может сработать.
Плюсую! В low-code первая версия выглядит обнадеживающе, а потом резкий рост сложности убивает проект. Когда-то писал об этом статью https://blog.byndyu.ru/2013/12/it.html
Я понимаю, что вы говорите. Да, можно обучить не-QA делать работу QA и этот человек будет писать какие-то тесты. Но что нам нужно от автотестирования в конечном счете? Я подразумеваю, что перед выкладкой на прод запускается набор тестов, который говорит, что ВСЯ система работает как надо. Тогда не нужен ручной регресс. Сделает ли непрофессиональный тестировщик такую работу?
Да, да, так я их и видел. Спасибо за комментарий.
Да, как раз так и думаю. Спасибо за уточнение.
Я бегло посмотрел инструмент. Если я правильно понял, вы предоставляете функционал для типовых задач розничного бизнеса. Что-то типа 1С в интерфейсе. Если вашим клиентам хватает кликов в интерфейсе, то все эти клиенты примерно одинаковые и, видимо, не такие большие как может показаться. Например, Леруа Мерлен не взяли бы себе ваш WMS (не в обиду вам, там просто очень много специфики, которую не накидаешь в интерфейсе).
Если вашим клиентам достаточно кликать в интерфейсе и не надо писать код, то у вас отличное low-code решение под вашу нишу. Если брать график, то решения заказчиков не уходят в "красную" зону.