Автор статьи: Дмитрий Курдюмов

Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом

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

Проблемы традиционного ITSM и необходимость изменений

Традиционные подходы в ITSM ориентированы на процессы, строгие регламенты и соблюдение SLA (соглашений об уровне обслуживания). Основные проблемы таких подходов:

  • Долгие циклы реагирования на запросы и изменения. Регламентированные процессы, как правило, требуют много времени на согласования и прохождение всех этапов.

  • Низкая адаптивность к изменениям. Структурированные процессы сложно адаптировать под новые требования или внезапные изменения.

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

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

Формирование Agile-команд в ITSM

Адаптация Agile в ITSM требует создания кросс-функциональных команд, которые будут самостоятельно решать инциденты и управлять изменениями. Такие команды должны быть автономными, чтобы минимизировать зависимость от других отделов и повысить скорость реагирования. Вот ключевые специалисты, которые должны войти в команду:

  1. Инженер по поддержке (Support Engineer): Основной специалист, отвечающий за первичную обработку инцидентов и взаимодействие с пользователями.

  2. DevOps-инженер: Участвует в автоматизации процессов, CI/CD и быстром реагировании на проблемы, помогает оперативно внедрять исправления.

  3. Специалист по управлению изменениями (Change Manager): Координирует изменения, оценивает риски и управляет релизами, обеспечивая стабильность.

  4. Технический аналитик (Technical Analyst): Анализирует причины инцидентов, помогает команде находить эффективные решения, собирает данные.

  5. Скрам-мастер или Канбан-мастер (Scrum Master/Kanban Master): Помогает команде оптимизировать процесс, устранять блокеры и фокусироваться на непрерывных улучшениях.

  6. Менеджер по релизам (Release Manager): Организует и координирует релизы, планирует и тестирует изменения перед их внедрением.

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

Настройка Kanban-доски для управления инцидентами и изменениями

Kanban‑доска — основной инструмент для визуализации работы команды и управления задачами. Правильная настройка доски помогает команде работать слаженно и предсказуемо, исключая задержки. Пример Канбан доски, которую мы настраивали в одной компании:

  1. Backlog (Беклог): Все инциденты и запросы на изменения, которые еще не начали обрабатывать. Это источник задач для команды, который помогает планировать загрузку.

  2. To Do (К выполнению): Задачи, готовые к началу работы. Сюда попадают инциденты, прошедшие предварительный анализ и имеющие все необходимые данные для решения.

  3. In Progress (В работе): Активные задачи, над которыми сейчас работает команда. Это основной рабочий поток, где видно текущее состояние инцидентов и изменений.

  4. Review (На проверке): Задачи, которые выполнены, но требуют проверки, тестирования или подтверждения перед завершением.

  5. Done (Готово): Завершенные задачи, отражающие результаты работы команды.

  6. Blocked (Заблокировано): Задачи, которые не могут быть завершены из‑за зависимостей, отсутствия данных или других проблем. Это критически важный столб для устранения блокеров.

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

Лимиты WIP (Work in Progress)

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

Как установить лимиты WIP?

Начните с анализа среднего количества задач в работе и постепенно уменьшайте это число, пока не достигнете оптимального уровня, при котором команда работает максимально эффективно.

Польза от WIP‑лимитов?

Сокращение времени выполнения задач, уменьшение многозадачности, повышение качества работы за счет фокуса на текущих приоритетах.

Встречи в рамках Kanban и их цели

Встречи — важная часть управления потоком в Kanban, позволяющая поддерживать ритм работы и решать проблемы по мере их возникновения. В Kanban необходимо включать регулярные встречи:

  1. Kanban meeting (Ежедневная встреча):

    • Проводится ежедневно, длится не более 15 минут.

    • Цель: Обсудить текущий статус задач, выявить блокеры и спланировать работу на день. Участники делятся информацией о том, что сделано, что будет сделано сегодня и какие проблемы мешают работе.

  2. Replenishment Meeting (Встреча по пополнению из беклога):

    • Проводится еженедельно или по мере необходимости.

    • Цель: Анализ новых задач и инцидентов, которые поступили в бэклог, расстановка приоритетов и добавление задач в столб «To Do» на Kanban‑доске.

  3. Service Delivery Review (Обзор доставки услуг):

    • Проводится раз в месяц или по мере необходимости.

    • Цель: Оценить эффективность работы команды, проанализировать метрики (время реакции, количество решенных инцидентов и т. д.) и определить действия для улучшения процессов.

  4. Operations Review (Обзор операций):

    • Проводится ежемесячно.

    • Цель: Анализ общих результатов работы, обсуждение операционных метрик, выявление тенденций и проблем, которые требуют вмешательства.

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

Теперь рассмотрим, как использование Scrum помогает управлять проектами по изменениям в ITSM.

Применение Scrum для управления изменениями и проектами

В отличие от Kanban, который идеально подходит для управления потоком задач и инцидентов в повседневной работе (run), Scrum используется для управления изменениями и проектами (change). Scrum позволяет структурировать и ускорить реализацию изменений, улучшений и новых инициатив через короткие итерации (спринты), обеспечивая гибкость и возможность быстрого реагирования на обрxатную связь.

Где и для каких проектов  можно использовать Scrum в ITSM

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

Проекты по внедрению новых функций и сервисов:

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

Оптимизация процессов и улучшение качества обслуживания:

  • Пример: Команда решает улучшить процессы обработки инцидентов, внедрив автоматизацию ответов на типовые запросы. Используя Scrum, команда на каждом спринте разрабатывает и тестирует новые функции автоматизации, проверяя их эффективность в реальных условиях.

Эксперименты с новыми технологиями и гипотезами:

  • Пример: Команда ITSM хочет проверить, как внедрение ИИ может сократить время решения инцидентов. В каждом спринте тестируется новый подход или модель ИИ, результаты анализируются, и вносятся корректировки на основе данных.

Применение Scrum для управления изменениями и проектами в ITSM

  1. Спринты: Изменения и новые инициативы планируются в рамках коротких итераций (обычно 2–4 недели), в которых команда работает над конкретными задачами и проверяет гипотезы. Спринты помогают управлять рисками, так как изменения внедряются постепенно, а не сразу.

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

  3. Ежедневные встречи (Daily Standups): Команда ежедневно обсуждает прогресс, выявляет препятствия и координирует работу, чтобы убедиться, что все задачи выполняются по плану.

  4. Ретроспективы: После каждого спринта команда анализирует, что прошло хорошо, а что можно улучшить. Это помогает команде адаптироваться и наращивать свою эффективность в последующих спринтах.

Заключение

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

Совместное использование этих подходов делает управление ИТ‑услугами действительно гибким, эффективным и ориентированным на непрерывное улучшение.

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

Если понравилась статья, переходите в мой телеграм‑канал и забирайте еще пользы пользы про построение гибких процессов.


Освоить современную систему управления IT-услугами, основанную на лучших практиках ITIL, можно под руководством экспертов на онлайн-курсе «Специалист ITSM».

Комментарии (4)


  1. Advisers
    21.09.2024 11:02

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


  1. nick_oldman
    21.09.2024 11:02

    Мне нравится ваша идея внедрения гибких подходов в ITSM, прежде всего потому, что нужно сокращать/автоматизировать бюрократические операции.

    Как вы ранжируете и обозначаете приоритеты задач в канбан-доске (особенно, если это инциденты)?

    И ещё мнение - я бы в этом подходе выделял отдельно run-команду и change-команду, если позволяет бюджет. Если нет, то можно брать в спринты run/change задачи в определенном фиксированном соотношении.


  1. Debrainer
    21.09.2024 11:02

    Делать разработку по скраму эффективно можно только если нет зависимостей от внешних команд. Как только сроки вашей реализации зависят от чего-то внешнего (вендор, другая команда), то скрам превращается в профанацию и постоянные переносы, так как вы не можете обеспечить выход запланированного бизнесом в спринт, а команда и все планы бизнеса были сфокусированы на конкретной цели в спринте, и тогда существенно эффективнее канбан, где каждый ресурс команды постоянно нагружается потоком работы вне зависимости от планов на спринт и бизнес фичи сразу выпускаются по мере готовности. TTM проектов/фич для бизнеса в целом по году получается значительно лучше. Да, больше переключений контекста и релизов не всем по душе, да и следить одновременно нужно за большим количеством фич. Но с точки зрения именно бизнес результата ИТ тогда выглядит как неостанавливающаяся фабрика постоянно дающая результат. По крайней мере мой опыт именно такой.


  1. Grikhan
    21.09.2024 11:02

    Статья о том, что когда у вас команда из шести человек, без заказчика, с которым по манифесту сотрудничество важнее требований (SLA же - "бюрократия"), да еще и без разработчиков (devops без dev - отличный подход) - вам ничего не остается, как только "митапить" друг-дружку канбан-доской. Один управляет релизами, другой координирует релизы, а того, кто их, собственно, создает и того, для кого он это создает - никто не спрашивает. Хороший "Agile подход". Главное, чтобы в спринте первая линия поддержки участвовала (ваш "Support Engineer"), да?