Что такое техническая поддержка и почему она должна быть не на разработчике

Уровни технической поддержки

L0

Тип проблемы

Типовые запросы, которые можно решить пользователю самостоятельно.

Пример обращения

Восстановить пароль, включить темную тему, проверить статус заказа.

Кто выполняет

Роботы, чат-боты, инструкции.

Что делает?

Присылает ссылку на пункт мануала, предоставляет форму самообслуживания

Обычный режим работы и время реакции

24/7, Мгновенно

‍

L1

Тип проблемы

Простые кейсы, не требующие глубокой проработки и которые можно решить с помощью специальной панели оператора.

Пример обращения

Например, оплаченный заказ в статусе “не оплачен” — проверить оплату и перевести статус вручную.

Кто выполняет

Специалисты техподдержки. Имеет доступ оператора и к мониторингу.

Что делает?

Меняет вручную по прописанному сценарию или подсказывает, как обойти проблему, пока она не решена.

Пишет и дополняет инструкции (пользовательские и для СТП). Обучает пользователей системы.

Обычный режим работы и время реакции

24/7, обычно в рамках 1 часа

‍

L2

Тип проблемы

Более сложные кейсы, не описанные в инструкциях.

Пример обращения

Есть проблемы синхронизации задач.

Кто выполняет

Продвинутые специалисты техподдержки. Имеет расширенный доступ оператора.

Что делает?

Решает не описанные в документации кейсы. Может сделать сложную последовательность действий (что-то поправить в базе, придумать временное решение проблемы). Агрегирует и передает проблемы в L3.

Пишет и дополняет инструкции (пользовательские и для СТП).

Обычный режим работы и время реакции

8/5, обычно в течение рабочего дня

‍

L3

Тип проблемы

Кейсы, переданные из L2.

Пример обращения

“Есть системная проблема, так она воспроизводится, на этом месте возникает ошибка”

Кто выполняет

Разработчики. Не должен иметь доступ на запись в продуктив (только через git и процедуры разворачивания).

Что делает?

Дорабатывает код.

Обычный режим работы и время реакции

8/5, планово

‍

L4

Тип проблемы

Проблема, которая не может быть решена на предыдущих уровнях, требует глубокого понимания продукта и даже переработки ядра.

Кто выполняет

Вендор (поставщик решения).

Что делает?

Дорабатывает код.

Обычный режим работы и время реакции

Зависит от вендора и сложности проблемы

Техподдержка — это L1 и L2.

Если разработчик не передаёт проект в службу техподдержки (СТП), а сам занимается операционным сопровождением системы, он:

• производит меньше ценности;

• не заинтересован в том, чтобы интерфейс был понятен службе техподдержки и тем более обычному пользователю;

• не вводит в должность оператора системы (это работа службы техподдержки);

• не отдыхает (техподдержка — круглосуточная работа);

• не поддерживает актуальность документации по проекту — ему «и так всё понятно» , а о тех, кто ещё будет решать проблему, он не думает. СТП пользуется документацией и передает документацию из смены в смену — значит, её прочли и отредактировали несколько людей.

• не ведёт статистику по обращениям с багами (техподдержка — ведёт);

• для клиента стоит дороже, чем техподдержка.

СТП не должна быть частью компании-разработчика!

Частое явление — подразделения техподдержки входят в структуру компаний по разработке. Это порождает конфликт интересов и смещение фокуса менеджмента с техподдержки на разработку. СТП в таких случаях, как правило, справляются с L1, но не в состоянии обеспечить L2 — эта зона ответственности остаётся у разработчиков. Это нарушает корректную обратную связь между разработчиками и специалистами техподдержки и размывает зоны ответственности. Качество техподдержки становится хуже по всем уровням.

Мы уверены, что СТП должна иметь полностью независимый менеджмент и зарабатывать только на технической поддержке.

Пример компании, занимающейся только техподдержкой, — https://stilt-itil.com

ITIL Wiki

‍