Контекст
В агротех-продукте цифровой агент должен помогать пользователю работать с предметными сущностями: находить нужные записи, применять фильтры, видеть корректные названия и получать понятный результат. Для бизнеса это не только технический релиз, а проверка готовности нового пользовательского сценария.
Узкое место было на стыке данных и интерфейса. Если справочник содержит неоднозначные названия, API возвращает неполные поля, фильтр работает не так, как ожидает пользователь, или пустое значение отображается как ошибка, агент перестает быть помощником. Пользователь не разбирается, где источник проблемы: в данных, API, UX или правилах поиска. Он просто перестает доверять результату.
Задача
Бизнес-задача - подготовить цифрового агента к релизу так, чтобы пользовательский сценарий был понятным, проверяемым и поддерживаемым. Команде нужно было не просто "доделать API", а снизить риск релиза: убрать неоднозначность в справочниках, согласовать ожидаемые поля, настроить фильтры и описать поведение системы при пустых значениях.
Для разных ролей задача выглядела по-разному: владелец продукта должен понимать, готов ли агент к запуску и какие дефекты блокируют релиз; предметный эксперт отвечает за корректность названий, типов сущностей и правил поиска; API-команда должна зафиксировать контракт; поддержка и администраторы должны видеть, где проблема; пользователь агента должен быстро найти нужную сущность и получить результат без ручного обхода.
Решение
Команда собрала релизную готовность агента вокруг пользовательского пути: запрос пользователя -> фильтр -> справочник -> API-ответ -> отображение результата. Такой порядок помог смотреть на дефекты через влияние на сценарий, а не как на разрозненные задачи разработки.
- Уточнили API-контракт по обязательным и ожидаемым полям.
- Разобрали правила отображения названий, кодировок и пустых значений.
- Вынесли фильтры по имени, типу и полу сущности в пользовательские сценарии поиска.
- Связали доработки справочников с админским UX, чтобы поддержка работала по тем же правилам, что и пользовательский контур.
- Сформировали понятные точки диагностики: справочник, API, фильтр, отображение.
Метрики и бизнес-цели
Для релиза цифрового агента важно управлять не количеством закрытых технических задач, а готовностью пользовательского сценария.
Бизнес-цель этих метрик - выпустить агента как рабочий инструмент для пользователей, а не как демо с нестабильными данными. Такой подход снижает риск, что после релиза продуктовая команда будет объяснять ошибки вручную вместо развития сценариев.
- доля успешных поисковых сценариев: пользователь находит нужную сущность по ожидаемым фильтрам;
- полнота API-ответов: обязательные поля приходят стабильно и в согласованном формате;
- качество справочников: нет неоднозначных названий, ошибок кодировки и неописанных пустых значений;
- количество пользовательских ошибок и обращений в поддержку из-за непонятного результата;
- скорость диагностики дефекта: понятно, где источник проблемы - справочник, API, фильтр или UI;
- готовность релиза: нет критичных дефектов, которые ломают доверие к агенту.
Результат
Проект получил более управляемую основу для релиза цифрового агента: API-контракт стал понятнее, фильтрация стала частью проверяемого пользовательского сценария, а ошибки данных и отображения получили диагностируемые точки.
Для владельца продукта это дает понятный критерий релизной готовности. Для предметного эксперта - контроль терминов и справочников. Для API-команды - согласованный контракт. Для поддержки - понятный маршрут разбора проблем. Для пользователя - более предсказуемый поиск и меньше риска столкнуться с некорректным результатом.