Ритуалы команды IT-поддержки: дежурства, ротация, retro, on-call

Daily stand-up — 10 минут, которые меняют день

Stand-up — не «отчётность перед руководителем», а синхронизация команды. Формат стандартный:

• Что закрыл вчера (1-2 фразы)
• Что в работе сегодня (приоритетные тикеты)
• Что блокирует (нужна помощь, ждёшь ответа от X, упёрся в проблему)

Главная польза для поддержки — раскрытие блокеров. Часто оператор сидит над сложным тикетом 3 часа, потому что не знает, к кому обратиться. На stand-up он говорит «застрял на доступе к 1С через VPN», и лид через минуту знает, что у Петрова была такая же история неделю назад, и можно посмотреть его комментарии. Тикет закрывается за 15 минут вместо ещё 3 часов.

Правила, которые помогают сделать stand-up рабочим:

1. Строго 10-15 минут. Стоят, не сидят (отсюда название). Длиннее — теряется фокус.
2. Параллельно открыть helpdesk-дашборд с тикетами — все видят, кто чем занят
3. Подробные обсуждения — после stand-up, в формате «приходите ко мне после», а не на 30 минут перед всеми
4. Не каждый день, а только когда команда > 3 человек. Двоим достаточно «привет, что нового».

Weekly retro — что не идёт и что улучшить

Если daily — про текущий день, то retro раз в неделю — про процессы. Формат:

• Что работало хорошо (что хочется продолжать)
• Что не сработало (где буксовали, конфликты, узкие места)
• Что попробуем поменять на следующей неделе (конкретные action items с владельцем)

Типичные темы, которые всплывают на retro в поддержке:

• Эскалация на 2-ю линию работает медленно — заявки лежат полдня
• Категории в helpdesk перепутаны — никто не понимает, куда направлять «не могу подключиться»
• База знаний устарела — половина статей про старую версию AD
• Между поддержкой и DevOps нет процесса передачи Major Incident

Каждая такая тема → action item: кто и к какому сроку фиксит. Через 2-3 месяца такого ритма команда становится заметно эффективнее, потому что мелкие застарелые проблемы перестают «копиться».

Опасность: retro может выродиться в жалобы. Лечится правилом «жалоба без предложения — это не вход в retro». Жалуешься на категории — предложи лучший вариант. Жалуешься на 2-ю линию — обсуди с ними напрямую и принеси договорённость.

Ротация ролей внутри команды

Постоянная работа на «фронте» (новые заявки от пользователей) выматывает быстрее, чем на «глубине» (сложные тикеты, KB, доработки). Поэтому в зрелых командах есть ротация:

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

Что обычно идёт не так: ротацию вводят, но в первый раз — и забывают. Через 3 недели все возвращаются на старые места. Лечится: график ротации в общем календаре + правило «если кто-то меняет роль раньше — заводит заявку на ротацию с обоснованием».

On-call дежурства — кто реагирует ночью

Если у вас есть SLA на критические инциденты 24/7 — нужен on-call. Это дежурный по расписанию, который доступен по телефону вне рабочих часов.

Несколько правил, которые делают on-call устойчивым:

1. Дежурство — неделя минимум. Сутки — слишком короткий период для контекста (передача дел занимает 30% дежурства). Месяц — слишком долго, выгорает быстрее.
2. Доплата за дежурство. Не «спасибо за работу» — конкретная сумма за каждый день. Стандарт в РФ: 500-2000 руб/сутки за «спокойное» дежурство (тревога 0-2 раза), повременная оплата при подъёмах.
3. Compensatory time off. Если был подъём ночью с реальной работой — следующий день за свой счёт сменить на полу-выходной (выйти к 13:00).
4. Чёткий runbook что считать «вызовом on-call». Иначе пользователи будут звонить в 23:00 «у меня Excel завис». Правило: on-call поднимается только по автоматическому алерту мониторинга или по эскалации от вашей же team. Не от пользователей напрямую.

Если on-call регулярно поднимают чаще 2-3 раз в месяц — это не on-call, это вторая смена. Нужно либо смотреть, что ломается ночью (и фиксить root cause), либо нанимать ночную команду.

Knowledge sharing — обмен опытом

Поддержка генерирует огромный объём «эфемерных» знаний — оператор разобрался с проблемой, закрыл тикет, и через 2 месяца другой оператор тратит 2 часа на ту же проблему с нуля.

Простые форматы, которые работают:

• «Tip of the week» в чате команды по пятницам — кто-то из операторов делится одной находкой недели
• Парная работа над сложным тикетом — два оператора 30 минут разбирают вместе, не «один работает — другой смотрит», а оба думают и спорят. Учит обоих
• Post-mortem после Major Incident — blameless документ: что произошло, почему не сработало, что меняем. Открытый в KB для всех
• Внутренняя wiki-страница «Я нашёл странность» — без структуры, просто заметки операторов. Через год превращается в самый ценный источник знания о специфике вашей инфраструктуры

Когда вы видите статью в KB на 50 строк, написанную операторами для операторов («если 1С не видит лицензионный сервер — проверь сначала это, потом это, потом это») — это сэкономило команде десятки часов работы за следующий год.