Опыт гибкого управления проблемами

bickering2-300x266Своим практическим опытом о том, как сочетать в одной организации методы гибкой разработки и классического процесса эксплуатации услуг, с нами делится Ян Джонс (Ian Jones), консультант KPMG Australia.

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

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

  Kanban Scrum
Планирование работ В объеме обрабатываемых запросов Фиксируется объем работ для временной рамки спринта
Оценка трудоемкости задач Не проводится Проводится
Отслеживание прогресса Фокус на потоке обрабатываемых запросов Фокус на скорости выполнения работ
Ограничения на пул задач в работе в момент времени Есть Нет
Владелец процесса Команда Scrum master
Непрерывное совершенствование По требованию, при возникновении дефектов По итогам временной рамки, при ретроспективе спринта

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

  1. Проводить оценку задач и планирование работ для предстоящего спринта было затруднительно;
  2. Сам факт группировки проблем в спринты не нес практической пользы и негативно воздействовал на группу аналитиков проблем из-за непрекращающегося давления темпа спринта.

Команда предложила использовать указанную ниже структуру доски Kanban:

  • Беклог
  • Запланирован анализ инцидентов
  • Анализ инцидентов проведен
  • Публикация и корректировка 
  • Завершенные

При работе с этой доской использовались следующие правила:

  • Члены команды убирали/откладывали работы в т.ч. из раздела "Публикация и корректировка", но не из "Завершенные", т.к.после публикации аналитиками результатов диагностики и описания мер по устранению, работы по непосредственному устранению проблемы выполняются другими ИТ-подразделениями, и сроки их работ могут сильно варьироваться.
  • Аналитики стремятся не передавать проблему своим коллегам и другим сотрудникам, а вести её от начала до конца, т.к. из-за необходимости значительного погружения в предмет каждой проблемы, переключение между задачами становится неэффективным по временным затратам.
  • Ограничения на количество задач в работе отслеживалось, но не были блокирующим работу фактором. Вместо этого, факт превышения порогового значения являлся поводом для эскалации и проведения переговоров с заинтересованными лицами по приоритезации выполняемых работ.

Применение принципа №5 из "Toyota Way", состоящего в построении культуры в которой нет места устранению проблем, а есть стремление получить качественный результат с первой попытки, сильно помогло команде. Визуализация потока обрабатываемых проблем и ежедневные короткие групповые совещания в форме стенд-апа позволили аналитикам выявлять сложности и недостатки в их исследованиях и совместной работе и устранять их, не откладывая на потом.

 

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ИЮН
26