Платформу собирали с нуля, и сложность была не в экранах. Пользователь работает с цепочкой зависимых сущностей: коннектор передаёт данные, устройство их хранит, виджет показывает, правило реагирует. У LoRaWAN, MQTT и трекеров при этом разная логика, а общей модели, как всё это работает вместе, у команды не было.
Развёл сущности по ролям и собрал модель продукта: общая рамка подключения с отдельными ветками под каждую технологию, управляющие виджеты — сразу с правами, состояниями и поведением при ошибке, событие отдельно от правила в алармах, визуальный редактор правил на BPMN, ролевая модель дилера — до интерфейса.
Технические сущности сложились в один последовательный путь: подключить устройство → получить данные → увидеть их → описать реакцию правилом → управлять клиентами. Платформа дошла до MVP, первые пользователи уже работают с ней. Массовых продуктовых метрик пока нет — и я их не приписываю.
Контекст
Kilo IoT — B2B-платформа, которая развивается в моделях B2B2C и B2B2B. Пользователь работает не с одним экраном, а с цепочкой зависимых сущностей: коннектор передаёт данные, устройство хранит метрики, виджет показывает их, а правило или аларм реагирует на изменения.
Моя задача была собрать эти части в понятную модель продукта и помочь команде договориться, как она должна работать.
Подключение устройств
У LoRaWAN, MQTT и трекеров разная техническая логика. Пользователь при этом хочет получить один понятный ответ: что подключать, какие данные понадобятся и что делать, если соединение не работает.
- Разделили выбор подключения и его настройку.
- Сделали отдельные ветки для облачного и внешнего MQTT.
- Добавили состояния проверки и ошибки.
- Связали коннекторы со списком устройств.
- Мастер устройства разложили на шаги: описание, подключение, маппинг данных и команды.
Дашборды и управление
Дашборд должен был не только показывать показатели, но и позволять управлять оборудованием. Поэтому к графикам и значениям добавились переключатели, кнопки, слайдеры и поля ввода.
Для каждого управляющего виджета мы прорабатывали источник данных, допустимые состояния, права пользователя и поведение при ошибке.
Алармы
Здесь важно было развести само событие и правило, которое его создаёт. Мы разделили входящие срабатывания, определения алармов и настройки, а сложные параметры собрали в последовательный сценарий.
Правила
Алармы отвечают на вопрос «что случилось». Правила отвечают на вопрос «что с этим сделать». Мы сделали визуальный редактор на BPMN: пользователь собирает сценарий из нод прямо на холсте, не открывая код.
- Ноды: старт по сообщению, шлюз с условием, вызов внешнего API, обогащение данными, скрипт, команда на устройство, создание аларма и обработка ошибки.
- Холст: режимы просмотра и редактирования, drag & drop, автосохранение и история версий.
- Деплой: правило собирается в контейнер, перед сборкой проверяется корректность схемы, есть реестр артефактов и остановка контейнера.
- Отладка: точки останова, значения переменных, watch и пошаговый проход по схеме.
Дилерская модель
Следующим уровнем стала B2B2B-модель. Дилер управляет клиентами, сотрудниками, тарифами и white label, а иногда входит в организацию клиента для поддержки.
Нужно было не просто добавить новые страницы, а определить роли, границы доступа и различия между обычным пользователем, дилером и дистрибьютором.
AI-агент
Мы рассматривали AI не как отдельный чат, а как новый способ управлять платформой. Агент должен объяснять состояние системы и помогать выполнять действия: подключить устройство, создать аларм или собрать виджет.
За диалогом стоит оркестратор и суб-агенты по доменам: устройства, правила, алармы, дашборды, отчёты и организация. Пользователь при этом видит один разговор, а не набор инструментов.
Дизайн-система
По мере роста платформы становилось сложнее поддерживать одинаковые состояния и поведение компонентов. Мы собрали токены, темы, компоненты и продуктовые паттерны для повторяющихся сценариев.
Библиотека устроена по уровням: атомы, из них молекулы, из них экраны. Для каждого компонента зафиксированы состояния, отступы и размеры текста — чтобы правило можно было проверить, а не обсуждать.
Результат
Мы собрали основу платформы, где сложные технические сущности складываются в последовательный путь: подключить устройство → получить данные → увидеть их → описать реакцию правилом → управлять клиентами.
Главный результат моей работы на стадии MVP — согласованная модель продукта, проработанные сценарии и система, которую команда может дальше развивать.