Admin24

Agile в работе технической поддержки: как гибкие методологии улучшают клиентский сервис

О, нет! Только не это модное слово «Agile»! Снова стендапы, канбан-доски и бесконечные ретроспективы. Кажется, что это просто очередной управленческий тренд, который заставит вас заполнять еще больше таблиц и проводить еще больше совещаний.

Но что, если за этим словом скрывается реальный способ сделать работу поддержки проще? В статье расскажем, что стоит за понятием Agile, и как его принципы помогают выстроить работу техподдержки.

ВРЕМЯ ПРОЧТЕНИЯ: 9 МИНУТ

Что такое Agile

Многие ошибочно называют Agile методологией – набором готовых правил и инструкций к действию. На самом деле, Agile – это философия и система ценностей.

Если заглянуть в словарь, слово «agile» переводится как «способный быстро и ловко двигаться» и «быстро соображать». Сложно придумать более точные качества для выживания в современном бизнесе.

Сегодня недостаточно просто создать хороший продукт или сервис. Нужно уметь мгновенно реагировать на смену трендов, действия конкурентов и запросы клиентов. Пока вы доводите до идеала релиз по старому плану, рынок может уйти в другую сторону.

Аджайл – это и есть системный подход к развитию той самой «быстроты и легкости» в работе компании.

Основу Agile составляют 4 основные ценности и 12 принципов. Они описаны в Agile-манифест, полный текст которого доступен на русском языке на официальном сайте.

Основные ценности Agile таковы:

Люди и взаимодействие важнее процессов и инструментов

Что это значит: Самый крутой софт для управления задачами не может полностью заменить «живое» общение и слаженную команду. Если люди не хотят помогать друг другу, даже лучшие инструменты и практики не дадут результата.
Работающий продукт важнее исчерпывающей документации

Что это значит: Клиенту нужна программа, которая решает его задачу, а не стопка написанных техзаданий. Документы важны, но они – вторичны.
Сотрудничество с заказчиком важнее согласования условий контракта

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

Что это значит: Мир меняется быстро. Упрямое следование плану, составленному полгода назад, может привести к созданию никому не нужного продукта. Гибкость здесь – это преимущество, а не слабость.

Интересный факт: Манифест Agile родился не в офисе,
а на горнолыжном курорте.

В 2001 году 17 человек, которых можно назвать «титанами» IT-индустрии (среди них были создатели Scrum, Extreme Programming и других методик), собрались в отеле The Lodge в Сноуберде, штат Юта.

Цель у них, казалось бы, была скромная – просто обсудить общие проблемы разработки ПО. Но у каждого разработчика был свой «рецепт» успеха, своя методология, и они могли бы потратить дни, споря, чья же лучше.

Однако в ходе дискуссий они обнаружили, что выступают против одного и того же – громоздкой и бюрократической «водопадной» (Waterfall) модели разработки. И что их объединяет вера в гибкость, людей и результат.

Всего за 2 дня IT-эксперты не просто договорились, а создали документ, который перевернул мир IT – «Манифест гибкой разработки программного обеспечения» (Agile Manifesto). Его ядро – 4 ценности и 12 принципов.

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

Автоматизируйте техническую поддержку
с Admin24 – Service Desk
15 дней бесплатно

Попробовать Подробнее

Agile, Waterfall и ITIL: в чем разница?

ITIL, Agile и Waterfall часто воспринимаются как конкурирующие подходы, но на самом деле они просто решают разные задачи. Давайте разберемся, как они связаны.

Agile – это гибкий подход к управлению проектами, основанный на итеративной* разработке. Проект делится на короткие циклы (спринты), в конце каждого из которых команда представляет конкретный рабочий результат. Главная цель – быстро адаптироваться к изменениям и постоянно взаимодействовать с заказчиком.

*Под итерацией понимается циклический процесс: команда выполняет задачу, анализирует результат и использует полученный опыт для улучшения следующих этапов. По сути, это принцип «проб и ошибок»: пробуем → проверяем → улучшаем.

Waterfall, или Каскадная модель – классический последовательный подход, противоположный Agile. Проект движется по строгому плану: сначала собираем требования, потом проектируем, затем разрабатываем, тестируем и внедряем. Каждый новый этап начинается только тогда, когда полностью закончен предыдущий. Изменить что-то в уже утвержденном плане крайне сложно.

ITIL (Information Technology Infrastructure Library) – это библиотека лучших практик для управления IT-услугами. Если Agile и Waterfall отвечают на вопрос «Как разрабатывать?», то ITIL отвечает на вопрос «Как стабильно предоставлять IT-услуги?». Фокус ITIL – стандартизация, управление рисками и обеспечение бесперебойной работы сервисов для бизнеса.

На первый взгляд ITIL не сочетается с Agile: первый настаивает на соблюдении правил (таких, как SLA), второй – на гибкости. Но это не значит, что они несовместимы. Напротив, их разумная комбинация дает отличный результат.

Например, в техподдержке:

Agile-подход применяется внутри команды:

Ежедневные стендапы для быстрого перераспределения нагрузки.
Ретроспективы для постоянного улучшения процессов.
Канбан-доски для визуализации потока запросов.

ITIL-процессы обеспечивают стабильность:

Соглашения об уровне обслуживания (SLA) гарантируют сроки решения проблем.
Управление инцидентами стандартизирует работу с сбоями.
База знаний постоянно обновляется на основе обратной связи.

Более подробно об Agile-подходе в службе саппорта рассказываем далее.

Agile делает техподдержку гибкой, а Admin24 помогает внедрить это на практике. Управляйте заявками, приоритетами и командой в одном месте — быстро и прозрачно.

Попробовать бесплатно

Agile в техподдержке

Реально ли использовать Agile в сервисном обслуживании? Не только реально, но и логично. Техподдержка – одна из тех сфер, где гибкие принципы Agile проявляют себя наиболее эффективно. Ведь работа в поддержке динамична и непредсказуема – поток обращений варьируется по сложности и приоритетам, а инциденты требуют быстрого пересмотра текущих задач. Аджайл здесь – это отказ от жестких схем в пользу здравого смысла и создание команды, способной быстро адаптироваться к изменениям.

Scrum или Kanban?

Agile реализуется через два самых популярных фреймворка – Scrum и Kanban.

Scrum – это работа короткими фиксированными циклами (спринтами) с четкими целями и ролями.

Kanban – это визуализация потока задач на доске с ограничением количества задач в работе, или WIP (Work In Progress), что позволяет гибко управлять приоритетами.

Для техподдержки чистый Scrum часто оказывается менее удобным, чем гибридный подход на основе Kanban. Давайте разберемся, почему.

В чем особенность работы технической поддержки?

Неравномерный поток задач – невозможно предсказать, сколько обращений поступит за день.

2. Высокий приоритет инцидентов – срочные проблемы (например, «сервер упал») требуют немедленного реагирования, что нарушает заранее составленные планы.

3. Разный объем задач – от простых запросов в 5 минут до сложных расследований, занимающих несколько дней.

Спринт – фиксированный период (например, 2 недели), в течение которого команда выполняет заранее определенный набор задач – плохо сочетается с хаотичным потоком заявок. Постоянные срочные инциденты «ломают» планирование, делая спринты неэффективными.

Kanban – это фреймворк, который оптимально подходит для процессов техподдержки.
Вот некоторые его принципы:

Визуализация работы

Все задачи (заявки) отображаются на Kanban-доске с колонками, например: «Новые», «В работе», «Отложено», «Решено».
Ограничение количества задач в работе (WIP, или Work in Progress)

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

Рабочий процесс нужно постоянно отслеживать, чтобы быстро адаптироваться к любым изменениям. Команда следит за движением карточек по Канбан-доске – если в каком-то месте возникает затор (эффект бутылочного горлышка) или задача надолго останавливается, это сразу становится заметно. В таком случае можно перебросить силы на проблемный участок, помочь коллеге или даже изменить этапы работы на самой доске, если процесс где-то неудобно устроен.
Снижение времени цикла (Cycle Time)

Это период от начала работы над обращением до его полного завершения. Чем короче цикл, тем удовлетвореннее клиент.
Понятные правила и цели

Когда в команде есть четкие и одинаково понятные всем правила, работа становится слаженной и предсказуемой. Каждый участник знает: какие задачи и в каком порядке выполнять; как правильно работать с канбан-доской; когда можно перемещать карточки между этапами; к кому обращаться за помощью. Вместо неопределенности и суеты в команде есть четкое понимание своих ролей и общей цели.

В свою очередь из методологии Scrum для команды техподдержки можно взять следующее:

Ежедневные стендапы (Daily Scrum)

Это 15-минутные собрания, где каждый отвечает на три вопроса: «Что я сделал вчера для помощи клиентам?», «Что сделаю сегодня?» и «Что мне мешает?». Стендап улучшает коммуникацию между сотрудниками, помогает быстро находить и решать проблемы, а значит – отпадает необходимость в дополнительных совещаниях.
Ретроспектива (Retrospective)

Регулярные встречи (раз в 1-2 недели) для анализа: «Что прошло хорошо? Что можно улучшить в наших процессах?». Это отличный инструмент для постоянного развития команды.
Работа с бэклогом (Backlog Refinement)

Периодический разбор «зависших» тикетов, чтобы понять причину их долгого разрешения. Нередко заявки зависают из-за самого клиента (нет обратной связи, ответов на вопросы), который в итоге обвиняет в задержке саппорт. Регулярная работа с бэклогом позволяет выявлять такие случаи.

Принципы Agile в техподдержке

Гибкие методологии и клиентская поддержка хорошо подходят друг другу – и то, и другое строится на сотрудничестве и коммуникации. Ранее мы упоминали 12 принципов Agile, с которыми можно ознакомиться на официальном сайте. Ниже рассмотрим 7 из них, адаптированных специально для службы поддержки. Эти принципы помогают выстроить рабочие процессы и значительно повысить качество обслуживания клиентов.

Удовлетворяйте потребности клиента за счет быстрого и непрерывного оказания поддержки.

Помогайте клиентам на всех этапах. Для комплексной поддержки клиентов оптимально подходят системы класса сервис-деск, например, Админ24. Быструю помощь клиентам обеспечат чат-боты, ИИ-агенты и база знаний, а с помощью автоответов вы сможете держать пользователей в курсе решения их обращений.

Перед тем, как помочь клиенту, всегда изучайте историю взаимодействия с ним – переписку, комментарии и т.д. Это поможет лучше разобраться в ситуации и быстрее решить вопрос.
Будьте в курсе изменений продукта, чтобы помогать клиентам лучше
Гибкие методологии поощряют реакцию на изменения, а не простое следование инструкциям. Постоянные обновления продукта – это хорошо, но они могут сделать ваши материалы поддержки устаревшими. Как это исправить? Привлекайте команду поддержки к участию в обзорах спринтов продукта. Так специалисты будут заранее знать о грядущих изменениях и смогут:
- Рассказывать клиентам об обновлениях персонально.
- Своевременно обновлять базу знаний.
- Самостоятельно вносить правки в материалы, не дожидаясь указаний.
Поддержка, продукт и разработка должны работать вместе

В основе гибкого подхода лежит совместная работа. Делитесь отзывами клиентов с командами маркетинга и разработки – это поможет создавать действительно полезные и востребованные продукты.

На практике удобнее всего использовать теги. Специалисты поддержки (например, третьей линии, куда поступают самые сложные проблемы) проставляют их в заявках. Остальные команды отслеживают теги и берут релевантные задачи в работу.

Создавайте команду из увлеченных специалистов
Основа успешной поддержки – это люди, ориентированные на решение проблем, а не на формальное выполнение задач. При найме сотрудников саппорта оценивайте не только профессиональные качества, но и совпадение ценностей.

Создавайте среду, где каждый специалист сможет сам расставлять приоритеты и выбирать способы решения задач. При этом он должен руководствоваться простыми, но важными принципами:
- Действовать решительно – брать инициативу и выстраивать сотрудничество.
- Искать нестандартные подходы – каждый день находить возможности для улучшений.
- Быть честным – действовать открыто и прозрачно.
- Проявлять уважение – создавать атмосферу взаимной поддержки.
Такой подход раскрывает потенциал команды: когда люди могут творчески подходить к работе и самостоятельно принимать решения, это повышает и мотивацию, и эффективность.
Решенные проблемы – главный показатель прогресса

Многие команды поддержки ориентируются на такие метрики, как CSAT и NPS (индексы удовлетворенности клиентов), FCR (доля решенных обращений с первого раза), AFRT (среднее время первого ответа) и др.

Однако, чтобы оценить реальную пользу саппорта, смотрите не только на цифры, но и на то, как меняется отношение клиентов: становятся ли они более лояльными, остаются ли с вами, рекомендуют ли вас другим.
В гибком подходе главным показателем успеха считаются решенные проблемы. Причем иногда простое рабочее решение ценнее «идеального», но долгого в реализации плана.
Чем проще – тем эффективнее
Принцип простоты как «искусства минимизации лишней работы» – это прямое руководство к действию для сервисной службы. Главная цель – не просто быстрее отвечать на запросы, а исключить рутину: ручной учет заявок, переключения между программами, назначение ответственных и прочие однотипные операции.

Здесь напрашивается только одно верное решение – автоматизация с помощью сервис-деска. Она позволит:
- Автоматически регистрировать заявки из различных каналов в единой системе.
- Распределять обращения по ответственным через систему умной маршрутизации.
- Автоматически контролировать выполнение заявок

Итог – в обращениях наведен порядок, а команда освобождена от лишних манипуляций. Сотрудники могут сосредоточиться на том, что действительно требует человеческого участия – решение сложных задач и живое общение с клиентами, где так важны эмпатия и гибкий подход.
Регулярный анализ – основа эффективной команды и качественной работы
Еще один ключевой элемент гибких методик – ретроспектива. Простыми словами – это встреча, на которой команда отвечает на вопросы:
- «Что прошло хорошо?».
- «Что можно улучшить?».
- «Что мы попробуем в следующий раз?».
- «Какие вопросы у нас остались?».
Ретроспектива поможет команде извлечь уроки из ошибок и определить, какие идеи стоит внедрить, чтобы повысить качество поддержки.

Используйте планерки для обмена опытом: делитесь успешными кейсами и озвучивайте процессы, которые нуждаются в доработке. Постепенные, но постоянные улучшения позволяют всей команде двигаться вперед значительно быстрее. Ценный вклад может внести каждый – и новый сотрудник, и опытный специалист. Именно их комментарии и наблюдения помогут отладить рабочие механизмы и улучшить клиентский сервис.

Что в итоге

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

Главное – понимать суть Agile и адаптировать его принципы под специфику вашей службы поддержки.

О тонкостях внедрения Agile в техподдержке читайте в наших следующих статьях. И не забудьте подписаться на наш телеграм-канал, чтобы быть в курсе анонсов.

А вы автоматизировали свой сервис?
Протестируйте Admin24 – Service Desk
15 дней бесплатно

Попробовать

Поделиться статьёй