Портал №1 по управлению цифровыми
и информационными технологиями

Как “продать” место в очереди

Очередь — одна из раздражающих вещей и пережиток советской эпохи. Она повсюду: в магазине на кассу, у лифта в офисном здании, пробка на дороге – это ведь тоже очередь. Список задач – это тоже очередь. Осознавая, что мы находимся всегда под воздействием ряда ограничений (нехватка времени, ресурсов) приходится признать, что нам не разорваться, а значит, приходится что-то откладывать на потом, а от чего-то и вовсе отказаться.

А что делать, если задача ставится из расчета: “Всю ночь кормить, к утру зарезать!?” Работы должны быть выполнены, и вы не можете разобраться с чего все же начать? Наверняка окажется, что не все задачи одинаково важны и критичны, а значит, работы надо будет приоритизировать.

Какие есть подходы к приоритизации?

Наверняка вы помните из Управления инцидентами (ITIL v3), что приоритет определялся на основе уровня влияния и срочности. Причем, уровень влияния, как правило, определял бизнес, а срочность – это уже вопрос внутренней кухни IT.

В рекомендациях по расстановке приоритетов, описанных в руководстве по практике Управления инцидентами (ITIL4) читаем:

  • Оценка последствий и срочности инцидента (а также временных ограничений для его расследования и разрешения) не является приоритетной задачей. При этом эта оценка полезна для определения приоритетов и других важных соображений, таких как оценка количества времени, необходимого для выполнения работы.
  • Расстановка приоритетов необходима только в случае конфликта ресурсов. Там, где имеется достаточно ресурсов для обработки каждой задачи в рамках временных ограничений, расстановка приоритетов не требуется.
  • Инциденты должны обрабатываться в едином бэклоге вместе с другими задачами (запланированными и незапланированными).
  • Приоритизация — это инструмент для назначения людей на задачи в контексте команды. Если инцидент обрабатывается несколькими группами, он будет иметь приоритет в каждой группе в зависимости от доступности ресурсов, целевого времени разрешения и предполагаемого времени обработки.
  • Доступность ресурса и расчетное время обработки определяются командой. Также время обработки может быть стандартизировано для повторяющихся операций. Целевое время разрешения может быть определено соглашениями об уровне услуг и / или внутренними спецификациями услуг поставщика. Время оценки влияния и завершения (разрешения) может измениться, поскольку группы поддержки обнаруживают новую информацию.

Как видим, взгляд на приоритизацию стал шире и с новыми допущениями.

Какие же есть еще факторы определения приоритетов в работе?

В рамках курса ITIL 4 «Create, Deliver and Support» мы разбираем эти факторы, влияющие на приоритет. Например:

  • Доступность или качество ресурсов. Приоритетность определяется наличием ресурсов для выполнения работы. Например, если в группе поддержки инфраструктуры есть один специалист по сетям, которому назначается каждый случай поддержки сети, то группа должна определять приоритеты, не связанные с сетью, всякий раз, когда специалист по сети занят.
  • Текущая загрузка. Приоритизация определяется текущей рабочей нагрузкой ресурса, при условии, что между ресурсами нет различий в качестве или различий в размерах рабочих элементов. Например, автоматизация центра поддержки может назначать входящие вызовы или чаты для поддержки на тех операторов, которые в данный момент не задействованы в контакте с пользователем или агентам с меньшими рабочими нагрузками.
  • Возраст. Приоритетность определяется возрастом единиц работ; например:
  • «Работа первой пришла — первой выполнена». Выполняется самая старая работа в очереди, т. е. в порядке живой очереди.
  • «Работа последний пришла — первой выполнена». Выполняется последняя поступившая работа, т. е. последняя в живой очереди.
  • Факторы времени. Приоритетность определяется временем, необходимым для выполнения рабочих заданий, например:
  • Самая короткая работа выполняется первой. Затем выполняется работа, которая может быть выполнена быстрее всего.
  • Самая долгая работа выполняется первой. Далее выполняется работа, для выполнения которой требуется больше всего времени.
  • Экономические или финансовые факторы. Приоритизация определяется денежными выгодами и затратами на выполнение работ.

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

  • Экономические штрафы. Приоритизация — это единицы работ, на которые наложен экономический штраф, например, функция соответствия, которая уменьшит регулятивный штраф.
  • Источник или тип спроса. Приоритетными являются рабочие вопросы, которые заслуживают более пристального внимания, например, запрос от ИТ-директора. Как правило, организации создают уровни прав (и соответственно устанавливают цены); например, может быть внедрена многоуровневая система, в которой заказчики серебряного уровня имеют приоритет перед клиентами бронзового уровня.
  • Сортировка. Приоритетность определяется срочностью, основанной на оценке последствий, которые может вызвать задержка.

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

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

Общепринятым методом приоритизации инцидентов является учет как уровня влияния (экономический фактор), так и срочности (фактор времени). Приоритетность работ должна периодически пересматриваться по мере поступления большего количества работ в систему. Это позволит динамически перераспределять ресурсы для управления очередями.

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

В качестве заключения.

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

А какие методы приоритизации в своей деятельности используете вы? Поделитесь своими мыслями и опытом в комментариях. Наверняка эта тема актуальна для многих.

ITIL 4 Foundation, MPT, DSV, DPI, CDS, HVIT, DITS
и другие интересные аббревиатуры от участников разработки

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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT