Организация с несколькими отделами, множеством систем и месячным отчётом, собранным вручную

Заказчик не назван, а цифры даны в долях. Это израильская организация с несколькими отделами и множеством внутренних систем, которая работает с нами по долгосрочному договору на разработку. До SLAtech Vantage месячный отчёт собирали вручную, часы не были привязаны к задачам, а о сбоях мы узнавали от пользователей. Сегодня почти каждая задача приходит через синхронизацию, каждый час привязан к задаче, и заказчик сам видит весь месяц.

Как это выглядело раньше

Часы вели в таблицах, месяц за месяцем: строка с датой, описанием, отделом и числом часов. Задачи в строке не было, поэтому на вопрос "на что ушли эти часы" отвечали по памяти.

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

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

Что мы подключили

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

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

Что заказчик видит сегодня

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

Над отчётом находится месячная сводка, которая автоматически составляется по тем же данным. Рядом чат, который отвечает на вопросы обычными словами; его поиск ограничен проектом заказчика и теми видами материалов, которые ему явно открыты.

Прежде чем текст уйдёт во внешнюю языковую модель, имена, номера удостоверений, телефоны и адреса электронной почты заменяются метками.

Что изменилось, в долях

Надёжного замера "до" у нас нет, поэтому здесь нет фразы "сэкономили столько-то часов". Есть доли, которые можно проверить:

• Около 98 задач из 100 приходят через синхронизацию из системы обращений. Остальные открываются из почты, из переписки или вручную, и ни одну не приходится вводить дважды.
• Каждый час, записанный в системе, привязан к задаче. Час без задачи просто некуда записать.
• Больше 99% участников переписки распознаны как люди проекта, а не как строки адресов.
• Почти половину вопросов в чат задаёт сторона заказчика.
• Около семи из десяти действий заказчика в портале приходится на открытие месячного отчёта.

Сбои: короткий список вместо историй

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

• В среднем больше тысячи повторений одной ошибки считаются одной группой.
• Около 98% групп отнесены к настоящим ошибкам, остальное составляет шум или внешний сервис.
• Выше "низкой" оценена меньше чем одна группа из пятидесяти. Именно это и требует внимания.
• О новой группе уходит одно письмо, а о группе, которая вернулась после закрытия, отдельное.

Что не сработало и чего пока нет

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

Что мы поняли

1. Подключать, а не просить отчёты. То, что и так записывается в рабочих инструментах, попадает в отчёт без необходимости кому-то помнить, что это нужно записать.
2. Историю помечать честно. Годы месяцев, загруженных из таблиц, помечены как "принят (история)". Это отдельный статус, не связанный с приёмкой в системе: кнопку там никто не нажимал и снимка отчёта у них нет, поэтому это не выдают за то, чего нет.
3. Механизм без материала пуст. Решения и статьи пишет человек, иначе их нет.
4. Заказчик приходит за отчётом. Журнал доступа в портале открывали так редко, что пункт меню убрали. Сама страница остаётся доступной по своему адресу.

Частые вопросы