Собрать приложение стало проще. Что дальше?

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

Это меняет и мои ожидания от платформы. Хочется, чтобы человек мог быстро попробовать свою идею, а затем спокойно развивать ее: дать людям попользоваться, понять, что получилось, внести изменения. Чтобы на платформу можно было положиться и больше внимания уделять самой задаче. С этим представлением мы и строим Navixy V4.

Первая версия вашего приложения помогает понять задачу и проверить направление решения

Допустим, вы собрали с агентом приложение для диспетчера. Оно показывает доставки и предупреждает о возможных опозданиях. Уже можно открыть его вместе с человеком, который будет им пользоваться, и посмотреть, помогает ли оно в работе.

В таком разговоре появляются детали, которые трудно было предусмотреть заранее. Оказывается, диспетчер знает о регулярной очереди на одном из складов. На другом ему важно заранее позвонить получателю. А часть уведомлений он просто пропускает: они приходят слишком часто и не требуют никаких действий.

Теперь у вас есть основания для следующей версии. Можно изменить уведомления и проверить, стало ли проще замечать доставки, которым действительно нужно внимание.

Дальше возникают три вопроса, от которых зависит повседневная работа приложения: на каких данных оно строится, как его поддерживать и что можно поручить агентам.

Данные, на которые опирается приложение и которым доверяют пользователи

Вопрос «машина опоздала?» кажется простым, пока не нужно выбрать событие для расчета. Въезд на территорию склада и приемка груза могут произойти с разницей в полчаса. Запрос выполнится в обоих случаях, но ответы будут означать разное.

Согласованное с клиентом правило имеет смысл определить один раз и использовать во всех его приложениях. Тогда утренний отчет и помощник диспетчера будут считать прибытие одинаково. А если клиент изменит правило, будет понятно, с какого момента действует новая версия и можно ли сравнивать ее результаты с прежними.

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

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

После запуска вам предстоит поддерживать и развивать приложение для ваших пользователей

Допустим, диспетчер привык получать отчет к началу смены. Однажды отчет не пришел. Что случилось: задержались данные, не завершился расчет или приложение вообще не запустилось?

Разобраться помогает история выполнения: какие шаги прошел процесс, сколько времени занял скрипт или запрос, где он остановился. Сообщение об ошибке полезно, когда из него понятно, что произошло и на каком шаге. Для агента важен и текущий статус: он еще работает, завершился с ошибкой или ждет подтверждения человека. Ожидание решения и сбой требуют разных действий.

Поэтому наш подход — делать эту историю доступной для разбора. Посмотреть поток данных в Inspector в IoT Logic, обратиться к логам в IoT Query, сопоставить их с выполнением приложения. Тогда человек или агент, который помогает с анализом, получает материал для поиска причины. На этой основе проще внести исправление, проверить новую версию и при необходимости вернуться к предыдущей.

Но даже исправно работающий инструмент может оказаться неудобным. Если после обновления диспетчер получает вдвое больше уведомлений, стоит выяснить, помогают ли они ему замечать нужные доставки или просто отвлекают. Здесь данные о работе приложения помогают проверить решение вместе с пользователем: что изменилось и стало ли от этого лучше.

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

Аутентификация и авторизация для агентов

Помощнику, который готовит сводку, достаточно читать данные. Агенту, которому поручили менять задания водителям, нужны другие полномочия. Эта разница определяет доступ агента: какие данные он может читать и какие действия выполнять.

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

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

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