Продукт для запуска продуктов: как мы запустили собственную low-code платформу Oberton

Антон Макаров, руководитель Creonit / digital production, выступил на весеннем ProductCamp 2024. Рассказал про управленческие решения, которые подтолкнули Creonit к запуску платформы для low-code разработки Oberton, а также про возможности этого инструмента. Делимся пересказом доклада.

Всем привет! На связи Антон Макаров, руководитель Creonit. Мы с 2015 года разрабатываем цифровые решения для бизнеса. В какой-то момент произошла классическая история для аутсорс-компаний — не удержались и начали запускать собственные продукты.

Так у нас появились:

О первых двух продуктах расскажу в следующий раз.

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

На тот момент мы были в кризисе:

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

Я начал мыслить стратегически. Нужно было построить процессы таким образом, чтобы все структуры работали сообща, а не обособленно: продажи, производство, PR, маркетинг, HR.

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

Стратегия поможет компании быть устойчивой и развиваться. Решили, что она должна быть завязана на core-услуге или продукте, вокруг которого будем выстраивать HR, PR, маркетинг, продажи, позиционирование, треки развития сотрудников и всё остальное.

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

Продукт должен:

Мы пересмотрели все сделки, причины обращений к нам, победы и проигрыши в переговорах.

Начали с базовых вопросов:

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

Вылез и целый пласт проблем, связанных конкретно с разработкой:

Проиллюстрирую проблемы кейсами из нашего опыта.

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

Дальше цитата руководителя на этапе продажи: «Мы дважды пытались оцифровать процесс и отказаться от Excel и как-то не получилось…». Производство вели ресурсами внутренней разработки.

Интересная история. Кто-то же делал проект, значит, у него должны были быть сроки, финансирование, планирование, команда и многое другое. Мы так и не поняли, как всё происходило, раз результат — «Ну, что-то не получилось».

Это, наверное, в свежей редакции PMBoK добавили новый этап проекта:

Итого компания потратила ~10 млн рублей и 6 месяцев, в результате получила... ничего. При этом очень часто у этих же компаний в стратегии развития прописано сделать IT дешевле.

Чтобы проверить распространённость проблем, которые мы обнаружили среди своих заказчиков, провели опрос в продуктовых сообществах и поспрашивали у коллег по рынку. Рассылали формы в чатах и коллегам, в итоге собрали 70 ответов. Это помогло найти дополнительные инсайты.

Какие проблемы обнаружили при исследовании:

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

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

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

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

Стало понятно: нужен инструмент, который избавит человечество от этих сложностей.

Мы могли бы решать боли рынка с помощью готовых решений. Стать вендором SaaS-продукта или коробки — это тоже давало бы ценность. Но наши амбиции не позволили стать вендором.

На пересечении наших амбиций и проблем клиентов начинаем строить продукт и услугу.

Снова формируем список требований, что хотим получить:

Всем этим требованиям отвечает low-code. Low-code платформа для нас может стать локомотивом, с помощью которого мы будем не только продавать разработку, но строить вокруг продукта и услуги все остальные направления работы компании.

Так мы за 4 месяца запустили собственную low-code платформу и назвали её Oberton, потому что мой деловой партнёр — музыкант.

Oberton работает по принципу декларативного программирования: разработчик высокоуровнево описывает, что он хочет получить, а система автоматически генерирует frontend и backend.

Высокая скорость разработки (~2 месяца). В сравнении с кастомной разработкой, продукты на Oberton делать в 2-3 раза быстрее, выдавая такую же ценность заказчикам.

Короткий цикл разработки. Пропускаем этапы визуального проектирования и frontend-разработки. За счёт этого ускоряем запуск продукта.

Меньше команда проекта. Минимальная команда для разработки проекта на Oberton – 4 человека. При классической разработке минимальный состав команды – 7-8 человек.

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

Лёгкость в разработке. Разметка для построения интерфейса пишется на Python. Под эту технологию легко искать специалистов — их много. У разработчиков нет большого отрыва от программирования. То есть они не чувствуют себя запертыми в какую-то систему, как при разработке на CMS. Делают интерфейс и интеграции. Как писали на Python, так на нем и пишут. Не появляется специализации “программист на Oberton”.

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

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

Подходит не для всех проектов. Не подходит для разработки некоторых типов продуктов (сайты, B2C интернет-магазины).

Oberton разрабатывали 4 месяца. Руководил процессом мой партнёр, у которого 20 лет опыта в программировании и управлении командой.

Вложили 9 млн. в производство. Считаю, что это не очень много.

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

Сделали на Oberton 5 продуктов за 3 месяца.

Перестали боятся делать продукты.

Можно сказать, мы открыли стартап-студию внутри компании, потому что сняли с себя блокер в виде скорости и бюджетов. Раньше у нас было 0 экспериментов, а сейчас параллельно 3.

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

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

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

Платформу можно применять для разработки любого B2B-продукта, где не нужен уникальный дизайн. Мы заложили максимальную гибкость.

С помощью Oberton можно разработать:

Мы хотели дать бизнесу максимум вариантов использования продукта без кастомизации ядра. Чтобы с помощью одного инструмента можно было сделать LMS, ERP, HR-портал, CRM, B2B-магазин, PIM-систему и даже то, что ещё не придумали. У нас это получилось. Создали продукт, который закрывает все основные боли заказчиков.

Завязали стратегию на наш продукт и услугу: продажи, найм, маркетинг и производство строятся вокруг Oberton.

Вот и всё… Неплохая получилась история. Интересная, весёлая, порой немного грустная, а главное – поучительная…

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