Low-code вместо месяцев разработки. Как сократить цикл MVP до 14 дней и сэкономить бюджет. Кейс «ИТ-Проба»

Оглавление

Почему мы пришли к low-code?

Что такое «ИТ ПРОБА»

Как работает low-code?

Примеры реализации

Наши кейсы

Куда мы движемся?

Почему мы пришли к low-code?

Все началось с классической истории: сделали продукт, отдали заказчику и получили фидбек «всё не то». Требования менялись быстрее, чем мы успевали их реализовывать.

Мы поняли: проблема не в разработчиках. Проблема в подходе.

Нужен был инструмент, который позволит:

• быстро проверять гипотезы;

• оперативно вносить изменения;

• не зависеть от длинных циклов разработки.

Так появилась «ИТ ПРОБА».

Что такое «ИТ ПРОБА»

Если коротко – это low-code платформа для создания бизнес-приложений без программирования.

Платформа состоит из трех частей:

1. Приложение (непосредственно сами бизнес-приложения пользователя).

2. Конструктор (визуальная настройка логики, экранных форм и жизненных циклов объектов).

3. Администрирование (доступы и роли пользователей, общее управление платформой).

С помощью конструктора можно собрать множество различных ИТ-решений, например:

• CRM;

• системы управления проектами;

• документооборот;

• управление справочниками;

• базы знаний;

• отраслевые решения.

Как это работает

В основе – визуальное моделирование данных. Мы создаем типы объектов (например, «Проект» или «Контрагент») и настраиваем:

• поля;

• связи;

• жизненные циклы;

• бизнес-логику.

Фактически аналитик сам собирает систему.

Для каждого типа данных можно настроить свой уникальный «Жизненный цикл». Это тоже делается с помощью визуального редактора: мы создаем состояния («Черновик», «На согласовании», «Архивный») и стрелочками-связями настраиваем переходы. Причем для каждого состояния (скажем, «Архивный») можно галочками запретить редактирование, удаление или создание версий. А для вычисляемых полей аналитик может сразу задать логику. Например, для поля «Десятичное число» можно поставить галочку «Формула» и прямо в конструкторе написать что-то вроде [field_sum] + [field_nds] * 1.2. Поле само все посчитает. 

Как работает low-code? Смысл low-code не в том, чтобы «убрать» разработчиков, а в том, чтобы сократить путь от идеи до рабочего решения и упростить дальнейшие изменения.

Что мы получили:

• MVP за 1–2 недели;

• применение изменений непосредственно в систему, сокращая релизный цикл и TTM;

• повышение эффективности продуктовых команд и команд разработки, команды делают больше, за тот же промежуток времени;

• гибкость под нужды бизнеса.

Kafka, Nuxeo и Headless

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

Фича №1. Headless-режим 

Платформа может работать как frontless (или headless) система. Это значит, что заказчик может реализовать свой собственный, полностью кастомный фронтенд на любом стеке, а «ИТ ПРОБУ» использовать как готовый бэкенд. 

В этом режиме платформа берет на себя всю «грязную» работу. Например, управление жизненным циклом документов, пользователями, ролями и всей бизнес-логикой.

Фича №2. Оркестрация данных через Nuxeo 

Мы не работаем с базами данных (Postgres Pro и Elasticsearch) напрямую. В качестве оркестратора и проводника для работы с данными у нас выступает Nuxeo. 

В Nuxeo есть ORM (Object Relation Mapping), с помощью которого мы работаем с объектами, а он уже сам транслирует все запросы в нужную БД. Все управление лежит на его стороне, поэтому в чистом виде транзакциями данных мы не управляем. 

Фича №3. Асинхронность и интеграции на Kafka 

Для обмена сообщениями и построения событийной модели мы используем Kafka. Это решение дает нам сразу три преимущества:

• через Kafka мы можем подключать любые внешние системы, будь то 1С или что-нибудь совсем кастомное;

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

• в одном из наших ИТ-продуктов есть документы с десятками тысяч полей, которые нужно обработать и рассчитать. Чтобы система не «ложилась», в Kafka мы выстраиваем очередь и налаживаем асинхронную работу.

Как масштабировать, обновить и защитить

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

Инфраструктура и CI/CD 

Для отказоустойчивости и масштабирования мы выбрали инструменты контейнеризации (Kubernetes или Docker). Если нагрузка на сервис растет, автомасштабирование само поднимает дополнительный экземпляр, который «проглатывает» эту нагрузку. 

Секреты, разумеется, в открытом виде не храним – для этого у нас есть Vault. В CI/CD реализована стандартная «светофорная» история. 

Еще есть несколько dev-контуров для экспериментов и разработки. Есть стенды – копии прода, которые мы отдаем аналитикам и тестировщикам для проверки релизных веток. Дальше идет предпрод в закрытом контуре в ЦОДе для финального тестирования и только потом – прод.

Эволюция схем

Самый интересный вопрос, которым мы задались: «Как обновлять схемы на живой системе, особенно когда у нас их две».

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

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

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

Но 100% бесшовной замены у нас пока нет. Мы честно просим у пользователей технические окна – либо ночные, либо на выходных – и в это время проводим замену компонентов.

Примеры реализации

Основной эффект, который мы видим, – это сокращение времени и, как следствие, костов на разработку. 

Как показывает практика, экономия на бизнес-решениях может доходить до 30%, поэтому наша целевая метрика – выводить MVP (минимально жизнеспособный продукт) от идеи до готового решения не более чем за один спринт, то есть за две недели. И это реально, если мы говорим о решениях, которые можно собрать в конструкторе.

Наши кейсы

Маркетплейс

Мы собрали корпоративный маркетплейс для использования внутри группы компаний, который объединяет (на создание витрины продуктов, ушло 3 недели 1FTE разработчика):

• услуги;

• внутренние сервисы;

• цифровые продукты.

Что реализовано:

• каталог продуктов и услуг, навигация по маркетплейсу;

• управление товарами и услугами;

• управление пользователями;

• продуктовая аналитика – для сбора информации, какие продукты и услуги интересны посетителям;

• запрос демонстраций по продукту и демо доступы к ИТ-продуктам компании;

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

Результат:

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

Управление аграрным холдингом

Решение для цифровизации аграрного бизнеса.

Что автоматизировали:

• учет земель и культур;

• планирование работ;

• контроль выполнения;

• аналитика урожайности.

Результат:

• прозрачность процессов;

• снижение ручного труда;

• повышение точности планирования.

Технологическая карта корпорации

Система для управления бизнес-процессами и архитектурой компании.

Что реализовано:

• описание процессов;

• связи между подразделениями;

• контроль изменений;

• единое хранилище данных.

Результат: единая цифровая модель компании.

Куда мы движемся?

Мы видим, что low-code становится стандартом:

• бизнес хочет быстрее;

• ИТ не успевает за классическими методами;

• требования постоянно меняются.

«ИТ ПРОБА» закрывает разрыв между запросами бизнеса и скоростью разработки классическими методами. Там, где раньше требовался длинный путь от технического задания до релиза, теперь можно собрать MVP, показать его пользователям, быстро внести изменения и масштабировать решение без переписывания системы с нуля.

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