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

1. Антон Викторов
Менеджер по обеспечению качества
Управление
инцидентами в Почте
Mail.ru

2. Что такое
инциденты и
почему это важно

3. • Инцидент
• Дежурный
• Баг
• Система управления инцидентами
• Реакция на инцидент
• Регистрация инцидента
• Оформление инцидента
• Расследование инцидента
• Закрытие инцидента
Про термины

4. Как из
непонятного
сделать «рутину»

5. До тасков
• Чат техподдержки и QA
• Не понятно, что
происходит
• И все остальные
проблемы отсутствия таск-
трекера
Когда я был маленьким

6. Когда появились
таски
• Большинство задач
долгие и непонятные
• Долгие и непонятные
задачи тяжко делать
Старый workflow

7. Как стало
• Каждый статус – это
микрозадача
• Выполнение микрозадачи
ведёт к следующей
микрозадаче
• Микрозадачи по одной задаче
могут выполнять разные люди
Новый workflow

8. Переносите
регламенты в GUI
трекера
• Текстовые регламенты сложнее
помнить
• Регламенты психологически
«давят»
Меньше регламентов –
больше кнопок

9. Закрась их все
• Визуализация сделанного и не
сделанного во всех задачах
• Только полезный результат: не
воспроизвел баг – не закрасил
• Можно фоново собирать
статистику скиллов и интересов
сотрудников
Геймификация

10. • Визуальное
представление
успехов и
провалов
• Фоновый сбор
статистики
SLA тоже можно
геймифицировать

11. Как заставить всех
заполнять поля, если
они вам правда так
нужны
• Не демотивировать при
регистрации инцидента и не
просить ничего заполнять
• Но требовать заполнять по
ходу работы над задачей
• Требовать заполнять только те
данные, которые точно есть на
этом этапе работы
Сбор данных

12. Про
автоматизацию

13. Постановка
тасков из
поддержки

14. От сотрудников –
в отдельную
очередь
С ними быстрее связаться, найти их проблему и
устранить её для всех

15. Быстрая реакция
Постановка задач через чат-бота

16. Хьюстон
Оповещает о новых инцидентах

17. Рассказывают обо всех
изменениях статусов
багов
• Все знают, что происходит – какие
задачи появились, какие в работе,
какие сделаны
• Можно делать быструю выборку
новых и сделанных задач даже с
телефона
Статус-боты

18. Jira-боты
• Автоприоритезация
• Автозакрытие
• Автоназначение и переназначение
• Автопинг

19. Автоназначение исполнителей
Автоматика

20. Как за всем следить
Kanban
• Выносим важное на кнопки и делаем из борда панель управления
• Выносим статусы (микрозадачи) в разные столбцы с группировкой по
потенциальным исполнителям

21. Про диагностику

22. Собираем всё, что можно унести
Что собираем мы:
• Версия операционной системы, модель устройства и useragent
• Версия сервисов Google Play
• Версия приложения
• Тип интернет-соединения
• Язык
• Логины авторизованных аккаунтов
• Включенность Java Script
• Referrer
• Разрешение экрана
Какие данные собирать с
клиента пользователя

23. Зачем
(для тех, у кого его вообще нет)
• Удалённая офлайн-диагностика
• Фоновый сбор статистики
Логирование

24. Что полезно уметь
• Удалённо запрашивать быструю отправку логов
• Удалённо узнавать всю информацию об устройстве
• Удалённо подключаться к пользователю
Удалённая диагностика

25. Чем можно пользоваться
• Charles для просмотра трафика, редактирования запросов-ответов и
имитации плохой сети
• Postman для ручного формирования запросов
• Browser Developer Tools для подмены UA, изменения пропорций
экрана, имитации плохой сети и слабого железа
• Лифт и поезда
Воспроизведение

26. Про сообщество

27. Как сделать из
сотрудников бета-
и альфа-тестеров
• Любить
• Платить чем можно

28. Антон
Викторов
Менеджер по обеспечению
качества
a.viktorov@corp.mail.ru
ICQ: @profile
Facebook: /victorov.anton