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

Цель задания:
Продемонстрировать навыки анализа поступающих инцидентов, формализации требований к разработке и управления процессами технической поддержки.
Описание:
Вы — руководитель технической поддержки личного кабинета, и перед вами стоит задача обработать обращения пользователей, поступившие через разные каналы связи (почта, чат, телефон). Ваша задача — сформулировать постановку задач для разработки (backend, frontend, DevOps), определить критичность и приоритетность обращений, а также предложить возможные пути решения.

Задача №1 — получения ошибки начисления бонусов в личном кабинете

Ошибка начисления бонусов в личном кабинете
Источник: обращение через чат + тикет в CRM.
Описание проблемы:
Пользователь сообщает, что после совершения покупки бонусные баллы не были начислены в личном кабинете. Проверил несколько раз, обновил страницу, но баланс остался прежним.
Дополнительные детали:
Сумма покупки: 5 000 ₽.
Оплата: онлайн-картой.
Ожидалось начисление: 500 баллов.
У других пользователей с аналогичными заказами начисление прошло успешно.
Задача: Опишите постановку задачи для backend, frontend и DevOps, указав, какие проверки и исправления нужно выполнить.

Логика решения

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

Регламент действий для инженеров ТП:

1. Эмпатия — это основное. Пользователь очень переживает о том, что бонусы не начислены, об этом говорят два идентичных запроса в разные каналы. Важно понимать, что решение очень важно для Пользователя и если у ТП нет оперативного решения необходимо предоставить обходное решение.
2. Сотрудник ТП должен проверить, что бонусы действительно не начислены, возможно что данные у Пользователя закэшировались и требуется очистка кэша.
3. Инженер ТП должен проверить и диагностировать, что бонусы действительно не начислены и проблема не в кэше.
4. Инженер ТП или РП связывается с Пользователем с предложением обходного решения — ручное начисление бонусов на счёт Пользователя. Параллельно у Пользователя уточняются шаги повторения проблемы, предложение снятия дополнительного har-лога.
5. Проверить и проанализировать логи Системы на наличие ошибок или предупреждений, связанных с начислением бонусов.
6. Повторить проблему описанную Пользователем.
7. Провести проверку начисления бонусов для разных ситуаций покупок — тестирование.
8. Проверить наличие записи в БД и проанализировать где ошибка в бэке или фронте.
9. Реализовать постановку для разработки (backend) с описанием шагов повторения проблемы.

Постановка задачи для разработки (backend):

1. Создать задачу.
2. Установить приоритет реализации задачи, как «Высокий».
3. Указать шаги повторения проблемы.
4. Приложить к задаче выгрузку логов с наличием ошибки начисления бонусов.
5. Указать данные аналитики из БД.

Постановка задачи для разработки (frontend):

1. Создать задачу и описать её.
2. Установить приоритет реализации задачи, как «Высокий».
3. Указать шаги повторения.
4. Описать в задаче, что в БД запись о бонусах есть, а в личном кабинете информация не отражается из чего ТП делает выводы, что это ошибка фронтенда.
5. Поставить задачу с ожиданием следующего результата — данные о бонусах обновляются сразу или по запросу пользователя при условии наличия данных в БД.

Постановка задачи для DevOps:

1. Создать задачу.
2. Установить приоритет.
3. Указать шаги повторения.
4. Приложить выгрузку логов.
5. Приложить аналитику из БД.
6. Ожидаемый результат — настройка автоматических тестов для проверки начисления бонусов.

Задача № 2 — некорректное отображение истории платежей

Некорректное отображение истории платежей
Источник: звонок в поддержку.
Описание проблемы:
Пользователь не видит последние платежи за подписку в веб-версии личного кабинета.
Задача: Опишите, какие проверки должны быть выполнены на стороне backend, frontend и DevOps, чтобы устранить проблему.

Первичная проработка задачи на уровне ТП:

1. ТП должна повторить шаги Пользователя для выявления ошибки.
2. При повторении ошибки необходимо проанализировать причины возникновения ошибки.
3. Необходимо проверить наличие записей последних платежей в БД.
4. Если записи платежей за подписку в БД есть, с очень высокой степенью вероятности это ошибка фронтенда.
5. Посредством postman необходимо проверить работу API, что Система для получения истории платежей работает правильно.
6. Проверить записи о работе Системы на наличие ошибок или предупреждений, связанных с отображением истории платежей на уровне логов.
7. Если ошибка повторяется и силами ТП исправление не получается — требуется поставить задачу для разработки.

Постановка задачи для разработчиков (backend):

1. Завести задачу с низким приоритетом.
2. Описать проблематику, анализ и методику тестирования, приложить логи, принтскрины работы с Postman.
3. Указать шаги повторения.
4. Указать текущий и требуемый результат.

Постановка задачи для разработчиков интерфейса (frontend):

1. Завести задачу с низким приоритетом.
2. Описать проблему с указанием проведённого анализа, приложить логи и принтскрины.
3. Указать почему ТП считает ошибку именно ошибкой интерфейса — данные о платежах не показываются на странице личного кабинета, либо отражаются неправильно.
4. Указать, что при проверке ошибки на уровне ТП выявили, что данные о платежах обновляются не сразу или обновляются на второй или третий раз по запросу пользователя.
5. Приложить проверку ТП с записью экрана по тестированию интерфейса для разных ситуаций отображения истории платежей.
6. Предложить рассмотреть в качестве устранения ошибки вариант проработки гипотезы связанности проблемы с серверным кэшированием данных либо аналогичной ситуации.

Постановка задачи для специалистов по автоматизации (DevOps):

1. Завести задачу и установить приоритет.
2. Приложить шаги повторения проблемы.
3. Приложить серверный лог, har-лог, выгрузку БД по данной записи, запись экрана тестирования проблемы на уровне ТП.
4. Итогом задачи требуется настроить автоматические тесты для проверки отображения истории платежей и настроить Систему для отслеживания правильности отображения истории платежей.

Задача №3 — ошибка смены email в личном кабинете

Ошибка смены email в личном кабинете
Источник: тикет через email.
Описание проблемы:
Пользователь пытается изменить email, но после подтверждения в личном кабинете продолжает отображаться старый адрес.
Задача: Опишите, какие возможные причины проблемы могут быть, какие проверки необходимо провести, и какие изменения нужно внести в backend, frontend и DevOps.

Первичная проработка задачи на уровне ТП

1. Самая распространённая причина данной проблемы — это кэширование пользовательских данных. 
2. Для проверки данной гипотезы — целесообразно предложить пользователю очистить кэш. Проверка гипотезы осуществляется через принудительную перезагрузку страницы с жёсткой очисткой кэша. 
3. Для развития данной гипотезы ТП нужно проработать следующие задачи.
4. Нужно убедиться, что процесс смены email работает правильно и кэш данных не задействуется при работе со страницей личного кабинета. Если отключение кэширования затруднительно, нужно создать принудительную очистку кэша при выполнении процедуры смены email. 
5. Нужно убедиться, что изменение email успешно сохраняется в базе данных.
6. Инженеры ТП должны проверить логи на наличие ошибок или предупреждений, связанных со сменой email.
7. Важно проверить и рассмотреть следующие гипотезы:
   1. Возможно, изменение email не было корректно записано в базу данных.
   2. Данные могут быть обновлены с задержкой, и старый email еще не был заменен на новый в базе данных.
   3. Данные о пользователе могут быть закэшированы, и изменения не отображаются сразу.
   4. Проблемы с инвалидацией кэша могут приводить к тому, что данные о сессии становятся неактуальными.
   5. Если данные о пользователе синхронизируются между различными системами, задержка может приводить к тому, что изменения не отображаются сразу.
   6. Различия в данных между системами могут вызывать конфликты, приводящие к отображению старого email.
   7. Возможно, процесс подтверждения изменения email не был завершен корректно.
   8. Возможно, интерфейс не обновляет данные в реальном времени или неправильно отображает их.
   9. Интерфейс может обновляться с задержкой, и изменения не отображаются сразу.
   10. Ошибки в управлении сессиями могут приводить к тому, что изменения не сохраняются или не отображаются.
   11. Данные о сессии могут обновляться с задержкой, и изменения не отображаются сразу.

Постановка задачи для backend:

1. ТП должна завести задачу на разработку со средним приоритетом.
2. ТП должна приложить шаги повторения проблемы.
3. Приложить к задаче логи, принтскрины БД и интерфейса.
4. Указать версию ТП для проверки связности проблемы с кэшированием данных с последующим исправлением по предложению ТП, либо другую проработанную со стороны ТП версию.

Постановка задачи для frontend:

1. Создание задачи.
2. Указание шагов повторения.
3. Отразить, что новый email не корректно отображается на странице личного кабинета.
4. Отразить, что данные обновляются не сразу или обновляются только после нескольких запросов от пользователя.
5. Указать логику тестирования со стороны ТП и приложить видео повторения ошибки. Такжи приложить логи Системы, har-лог, принтскрины БД.
6. Указать текущий и желаемый результат

Постановка задачи для DevOps:

1. Создать задачу со средним приоритетом.
2. Приложить шаги повторения и логи.
3. Указать качество результата по выполнению задачи — настройка мониторинга отслеживания успешности смены email и настройка автоматических тестов для проверки смены email.

Задача №4 — разлогинивание после авторизации через внешнюю систему аутентификации

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

Первичная проработка задачи на уровне ТП

1. Первостепенной задачей ТП до передачи проблемы на разработку является первичный анализ проблемы с тестированием, повторением шагов воспроизведения ошибки, анализом логов и изученим записей в базе данных.
2. Необходимо провести тестирование по проверке логики аутентификации и убедиться, что процесс авторизации работает правильно.
3. Проверить гипотезу по ошибкам в работе пользовательских сессий и убедиться, что сессия пользователя создаётся и поддерживается корректно.
4. Очень важно проверить и проанализировать логи на наличие ошибок или предупреждений, связанных с авторизацией.
5. ТП должна проверить основные гипотезы возникновения данной проблемы:
   • сессия пользователя настроена на очень короткий срок и она истекает сразу после авторизации;
   • Токены аутентификации могут быть некорректно обработаны или иметь слишком короткий срок действия — проверить через Postman или инструмент разработчика в браузере;
   • Задержки в сети — провести проверку на наличие проблем с сетью и возможные задержки в передаче данных;
   • возможные воздействия на Систему со стороны AVP Пользователя.
6. Итогом решения проблемы должно стать тщательное тестирование, анализ логов и выявление конкретную причины.

Постановка задачи для backend:

1. Завести задачу на разработку с высоким приоритетом.
2. Указать шаги повторения проблемы.
3. Указать рассмотренные ТП гипотезы и результаты выводов по ним.
4. Приложить лог, har-лог повторения ошибки, принтскрины экрана с отражением ошибки.

Постановка задачи для frontend:

1. Создать задачу с высоким приоритетом
2. Указать шаги повторения.
3. Отразить рассмотренные ТП гипотезы и результаты.
4. Приложить видео с отражением, что что Пользователь успешно авторизуется и далее не остаётся в Системе. Приложить лог, har-лог.
5. Отразить, что данные о сессии обновляются не сразу или обновляются только после нескольких запросов пользователя.
6. Приложить результаты тестирование интерфейса для различных сценариев авторизации с отражением ошибки.
7. Указать текущий и желаемый результат.

Постановка задачи для DevOps:

1. Создать задачу с высоким приоритетом.
2. Указать шаги повторения. Приложить логи Системы, har-лог, видео лог.
3. Положительным результатом выполнения задачи должен стать настроенный мониторинг для отслеживания успешности авторизации, а также настроенные автоматические тесты для проверки авторизации.

Финальные вопросы

Составьте таблицу приоритетов задач (высокий, средний, низкий).
Какие процессы технической поддержки можно улучшить или автоматизировать на основе этих инцидентов?
Какие метрики необходимо отслеживать для повышения качества работы технической поддержки?
Формат сдачи:
Документ с разбором задач, таблицей приоритетов, рекомендациями по автоматизации и метриками для оценки работы технической поддержки.

Финальный вопрос №1 — таблица приоритетов задач

Финальный вопрос №2 — рекомендации по автоматизации процессов технической поддержки

1. Автоматизация сбора информации: Настройте автоматическое создание тикетов в CRM на основе обращений через чат, email и телефон.
2. Автоматизация тестирования: Внедрите автоматизированные тесты для проверки основных функций личного кабинета.
3. Мониторинг и алертинг: Настройте мониторинг ключевых метрик и систему уведомлений для оперативного реагирования на проблемы.
4. Интеграция с системами управления задачами: Интегрируйте CRM с системами управления задачами (например, Jira) для автоматического создания задач для разработчиков.

Финальный вопрос №3 — метрики для оценки работы технической поддержки

1. Время первого ответа: время, которое требуется поддержке, чтобы ответить на обращение пользователя.
2. Среднее время разрешения: среднее время, за которое проблема решается.
3. Уровень удовлетворенности клиентов: оценка, насколько пользователи довольны работой технической поддержки.
4. Количество повторных обращений: количество обращений по одной и той же проблеме.
5. Количество закрытых тикетов: количество тикетов, успешно закрытых за определенный период. Также важно отслеживать данный показатель в процентном соотношении тикетов к сотрудникам и общему количеству заведённых тикетов.
6. Количество инцидентов: количество инцидентов, возникших за определенный период. Здесь также важно процентное соотношение возникших инцидентов к другим метрикам.

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

Подводя итог по анализу поступающих инцидентов в техническую поддержку важно заметить, что основная задача технической поддержки — это решение проблем на своём уровне компетенций, а не передача инцидентов на уровень выше. Техническая поддержка должна уметь работать с логами, запросами на уровне Postman, анализировать записи в БД, уметь снимать har-лог, уметь анализировать и проверять гипотезы. Немаловажным фактором является актуальная база знаний для ТП и разработки с описанием условий и методов проверки проблем.