Самая дорогая часть исправления ошибки — это не само исправление

Мы продолжаем говорить о продуктивности разработчиков. Но мы оптимизируем не то.

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

Тем не менее, один из самых распространенных рабочих процессов в разработке программного обеспечения до сих пор начинается с чего-то столь же простого, как:

"Приложение вылетело."

То, что происходит дальше, редко бывает эффективным.

Ошибка — не узкое место. Узкое место — это контекст.

Кто-то сообщает об ошибке. Не подробный отчет об ошибке. Просто сообщение.

"Уведомления не работают."

"Я не могу войти."

"Приложение вылетело."

В этот момент кажется, что у инженеров есть работа. Но чем больше времени я проводил, работая с командами поддержки, тем больше я понимал, что сама ошибка не замедляет компании. Замедляло все, что происходит после. Поддержка просит скриншоты. Клиент не может точно вспомнить, что произошло, кто-то спрашивает, какую версию приложения он использует, инженеры присоединяются к разговору и запрашивают логи, продукт создает задачу, QA спрашивает, может ли кто-нибудь воспроизвести проблему, кто-то копирует разговор в Jira, кто-то вставляет скриншоты в Slack, кто-то открывает панель мониторинга для поиска логов. К тому времени, как разработчик наконец-то начинает заниматься проблемой, уже потрачено двадцать или тридцать минут — не на решение проблемы, а просто на сбор достаточного контекста для ее понимания.

Я видел этот рабочий процесс как в стартапах, так и в крупных организациях. Инструменты меняются. Процесс редко.

Люди стали уровнем интеграции

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

"Уведомления не работают."

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

Увеличение количества отчетов об ошибках на самом деле может быть хорошим знаком

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

ИИ не должен заменять поддержку. Он должен устранять невидимую работу.

Я не думаю, что будущее ИИ в поддержке клиентов заключается в написании более дружелюбных ответов или замене агентов поддержки. Речь идет об устранении невидимой работы, которая происходит между поддержкой, продуктом, инженерией и QA. Потому что цель не просто быстрее отвечать клиентам. Цель состоит в том, чтобы убедиться, что когда инженер наконец открывает отчет об ошибке, он может немедленно начать решать проблему — вместо того, чтобы тратить первые тридцать минут на выяснение того, что на самом деле произошло. Именно здесь я считаю, что ИИ становится по-настоящему ценным. Не тогда, когда он ведет себя как еще один член команды. Но когда он тихонько занимается работой, которую люди вообще не должны были делать. Именно такой рабочий процесс мы изучаем в BridgeApp: не просто помогая командам быстрее реагировать, но и гарантируя, что каждая ошибка доходит до инженеров с уже приложенным контекстом.