Продукт для запуска продуктов: как появился Oberton

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

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

1. Сервис для размещения товаров на маркетплейсах.
2. Сервис мониторинга пользовательского опыта в приложениях.
3. Платформа для low-code разработки Oberton. 

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

Как появился Oberton

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

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

1. Не управляем ростом компании. Растем на 20% ежегодно, вместо желаемых 40%.
2. Слишком много направлений в разработке: отделов, разнопрофильных стеков, технологий, которые постоянно меняются. Это дает большую нагрузку на руководителей. Не можем нормально построить структуру в каждом из отделов и управлять ими. 
3. Низкая рентабельность. 
4. Сложно нанимать людей. Под некоторые стеки тяжело найти специалистов. Не всем специалистам мы могли предложить нормальный трек развития.

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

От тактики к стратегии

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

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

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

Рецепт core-продукта

Шаг 1: сформулировать требования к результату

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

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

1. Позволять нам делать то, что любим: автоматизировать рутину и повышать операционную эффективность заказчиков.
2. Решать текущие проблемы с HR, производством и продажами.
3. Снизить страдания. Помочь приносить больше ценности как компании.

Шаг 2: проанализировать сделки за 3 года

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

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

• кто наш клиент;
• что у нас чаще всего покупают;
• почему выбирают нас.

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

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

1. Большие сроки.
2. Высокая стоимость производства и запуска продукта.
3. Неудовлетворённость результатом.
4. Нельзя использовать готовые решения (SaaS, No-Code), чтобы удешевить процесс.
5. Коробочные решения не во всем подходят — требуется много кастомизаций.

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

Кейс нефтяной компании, у которой что-то не получилось

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

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

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

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

1. Инициация.
2. Планирование. 
3. Выполнение.
4. …«Как-то не получилось».

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

Шаг 3: погружение в проблемы

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

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

1. Длинные цепочки согласований — 36%.

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

2. Высокая стоимость разработки с 0 — 28%.

3. Нельзя использовать No-code и SaaS-решения — 23%.

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

4. Нет культуры создания продуктов с нуля — 10%. 

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

5. Правки после разработки — 3%.

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

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

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

Шаг 4: рождение продукта

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

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

• Высокая скорость разработки веб-сервиса — ~2 месяца.
• Открытый исходный код и деплой куда угодно. 
• Отзывчивый интерфейс, построенный на дизайн-системе. 
• Универсальный инструмент с огромным количеством вариантов использования без кастомизации ядра (чтобы можно было сделать почти любой веб-сервис: от LMS до ERP). 

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

Oberton

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

Преимущества Oberton   

Высокая скорость разработки (~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-система для размещения товаров на маркетплейсах. Она бы никогда не увидела свет, если бы нужно было делать фронтенд и бэкенд. Это тонна времени, а сделать сервис требовалось за две недели. 

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

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

Польза для заказчиков

• Готовый продукт получаем за ~2 месяца без учёта интеграций.
• В 2 раза меньше согласований: нет этапов дизайна и фронтенда. 
• Управление ожиданиями: заказчик получает демо-стенд на пресейле за 5 дней. Его можно «потрогать» и понять, подходит ли бизнесу такое решение.
• Стоимость разработки с нуля в 2-3 раза ниже. Делали за 10 млн, теперь делаем за 3-4 млн. 
• Стоимость владения продуктом меньше в 2-3 раза. Готовый сервис может поддерживать любой python-разработчик. Мы готовим проектную документацию при передаче исходного кода.

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

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

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

1. Интерфейсы вместо Excel-таблиц
2. Управление поставками
3. Взаимодействие с поставщиками
4. B2B интернет-магазин / порталы
5. Согласование графика отпусков сотрудников
6. Софт для составления смет
7. Мини-ERP 
8. HR-портал
9. И многое другое.

Итого

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

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

Если хотите быстро запустить продукт с помощью Oberton или узнать подробности — пишите нам на сайте.