Повышение приоритета как (неработающий) способ ускорения работ

Мы это видим довольно регулярно. Не только видим, но и принимаем участие в обсуждении или принятии решения: «смотрите, задача АВС уже очень долго находится в работе, давайте повысим её приоритет, чтобы, наконец-то, устранить проблему». Согласитесь, это вполне привычный способ управления. Беда в том, что он очень деструктивен и зачастую приносит больше вреда, чем пользы.

Для дальнейших рассуждений необходимо сделать два предположения:

  1. Задача, приоритет которой повышается, не единственная в очереди.
  2. Работы много; точно больше, чем ресурсов в данный момент.

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

Задумаемся, что происходит, когда приоритет какой-либо задачи повышается? Повышая приоритет задачи мы тем самым выделяем на неё больше ресурса, чем на другие задачи, либо ресурс выделяется скорее, чем на другие. Она поднимается выше по очереди, к ней приступят раньше всего. Тут-то и кроется уловка.

Дело в том, что в тот же момент, когда одна задача получила приоритет повыше, все остальные автоматически получили приоритет пониже. К ним теперь приступят позже; на них будет выделено ресурса меньше. Первая часть, приятная, всем видна — приоритетная задача пошла вперёд! О второй части (всё остальное подвинулось вниз) мы предпочитаем не задумываться.

«Не задумываться» имеет довольно печальные последствия, связанные, к примеру с заинтересованными лицами по остальным задачам. В курсе ли они, что было принято решение понизить их приоритет? Согласны ли они с таким решением? Можно ли ими пожертвовать в угоду другим заинтересованным лицам, которые в данную минуту по каким-то причинам вдруг расцениваются как более важные?

Следующий блок неприятных вопросов связан с регулярностью и частотой операции по смене приоритета. Если такая активность происходит часто, то в систему выполнения работы постоянно вносятся турбулентность, завихрения, что совершенно однозначно создаёт потери. Потери, которых могло бы не быть, если бы работа выполнялась ритмично, методично, чётко. Фактически, чем чаще мы меняем приоритеты, тем медленнее выполняются все наши задачи: и те, которые теперь стали менее приоритетны, и те, приоритет которых мы повысили. Регулярная смена приоритета — не бесплатное действие. У каждого управленческого решения есть цена. Принимается ли она во внимание?

Если культура организации подразумевает работу с большими задачами (занимающими, скажем, месяцы), то смена приоритета чаще всего происходит тогда, когда почти все задачи находятся в состоянии «приступили, но пока не завершили». В этом случае внезапная смена приоритета означает, что сделанная ранее, но не завершённая работа становится потерями, ведь ценности она никакой пока не принесла. То есть снова: решение вроде привычное, а последствия — неприятные. Зачем было тратить ресурс, брать работу и делать её наполовину?

Отдельного рассмотрения требует вопрос смены приоритета как способа антикризисного управления. Ситуации могут, к примеру, быть такими:

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

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

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

Есть ещё и глобальная беда. Откуда ресурсы будут отвлечены в первую очередь, чем можно пожертвовать? Правильно, любыми «второстепенными» активностями по организации работы. То есть неработающее проектное управление и попытка управлять по крайним срокам отнимает ценный ресурс от развития, улучшения, системного и структурного решения проблем организации труда. Нам пока не до этого, у нас «кризис». Потом разберёмся. Но «потом» не наступит ведь.

Было бы здорово закончить заметку списком рецептов: что теперь делать, как действовать? К сожалению, простого универсального решения здесь нет, так как конкретные ситуации могут быть совершенно разными. Можно лишь попробовать привести некоторые примеры хороших практик:

  • Если ваш проект загибается, то, вполне возможно, нужно дать ему умереть, а не отнимать ресурсы у других проектов. Столкнуться лицом с последствиями, но заодно понять как так получилось и как построить работу, чтобы больше проекты не загибались.
  • Не нужно работать большими порциями: проекты на месяцы, кварталы и годы. В этом случае вероятность попасть в ситуацию смены приоритетов стремится к 100%. Напротив, чем меньше средний размер задачи, тем лучше.
  • Работу можно организовать чётко, ритмично, предсказуемо. Если понятна средняя скорость работы потока, то планировать время получения результата можно совершенно иначе.
  • Менять приоритеты задач и проектов, к которым уже приступили, категорически нельзя. Нет больше такого инструмента управления.
  • Наконец, выстраивать работу радикально иначе, устраивать революции и цифровые трансформации в областях, где творится полный хаос и управление отсутствует даже на базовом уровне, наверное, не стоит.

Главный вывод всей заметки можно просуммировать одной фразой, которую легко запомнить:

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

DevOps Основы DevOps

Популярный трёхдневный учебный курс
 

Проект Феникс — DevOps на практике

Полезная деловая игра для вашей команды
 

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

Комментарии и мнения

  1. Владимир Невский

    Поддерживаю и плюсую. В компании должны быть четкие правила установки и изменения приоритетов. Чем больше денег компания теряет из-за конкретного инцидента, тем больше ресурсов должны быть брошены на его устранение и никак иначе, остальное — пустое. Управляющие воздействия для изменения приоритета с применением должностного положения или харизмы просителя — только вносят диссонанс в работу и вредят процессу!

    1. Андрей другой

      Очень важная и очень правильная, на мой взгляд, мысль о том, что в основе системы изменения приоритетов должны быть деньги. В данном случае размер финансового ущерба от инцидента. Решение обозначенной проблемы вполне можно достичь за счет использования системы управления рисками (Risk Management) для изменения приоритетов. Более того — в этом случае вам будет легко объясняться с бизнесом, поскольку деньги — это единственный язык, который понятен бизнесу. Но на этом пути есть огромная трудность. Чтобы оценивать финансовый ущерб от недоступности ИТ сервиса необходимо знать финансовую ценность бизнес процесса, который этот сервис поддерживает. А оценкой бизнес процессов заниматься лень.

  2. Дмитрий Исайченко

    А для меня мысль осталась непонятной.

    В начале заметки четко сказано: «Работы ... больше, чем ресурсов в данный момент». Следовательно одновременное выполнение всей работы невозможно. Тогда принципиально есть только два варианта: FIFO или какое-то управление очередностью, то есть приоритизация задач. FIFO опирается на принцип равной значимости (срочности и важности) всех задач. К сожалению, в жизни так бывает крайне редко. Следовательно какой-то вариант приоритизации необходим.

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

    Тогда Олег, поясни, пжл, в чем смысл этого утверждения?

    1. Роман Журавлёв

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

      Мне лично идея нравится, но интересно, как она работает, когда речь и дет не о запущенном проекте или влиятельном заказчике, а о внезапных неприятностях (инцидентах и катастрофах). Есть ли такие задачи, которые врываются в ритмичную работу без всякой очереди и ради которых другие (уже начатые) задачи действительно нужно отложить, или у правила «никакой переприоритизации» нет исключений?

      1. Дмитрий Исайченко

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

        За исключением отложенных задач и особых ситуаций типа major-инцидентов. А еще в предположении коротких задач, ведь чем длиннее задача, тем сложнее будет выдержать такой режим, ибо жизнь меняется. А еще в предположении, что каждую задачу решает один человек, потому что если это не так, то перераспределение ресурсов возможно и по ходу выполнения задачи. ИМХО.

      2. Олег Скрынник Автор

        Ром, спасибо, что понятно объяснил то, что я попытался сформулировать в заголовке заметки 🙂 Всё так и есть, только у тебя получилось лучше и лаконичнее.

        Про внезапные неприятности можно рассуждать, например, так.

        В ответ на очень большую внезапную неприятность можно доделать то, что уже взяли, и затем приступить к устранению неприятности. Потому что бросать работу — потери, переприоритизация — потери, переключение контекста — потери, многозадачность — потери, ну и так далее. Тут же возникает вопрос: как же так, мы будем игнорировать, к примеру, major incident и спокойно доделывать наряд на выдачу прав доступа операционисту? Такой вопрос заставляет задуматься о том, как сделать так, чтобы ожидание было не таким уж большим; нормально ли это, что у нас major incident; когда был последний major и что мы предприняли, чтобы больше с ним не встречаться, ну и ещё такие же неудобные вопросы.

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

    2. Олег Скрынник Автор

      Э-э-э-э-э...

      Вроде в заметке не предлагается отказаться от приоритета как понятия. Предлагается разумнее относиться к *изменению* приоритета.

      Хотя, конечно, тут есть доля лукавства. Например, можно вспомнить концепцию «у дефектов нет и быть не может приоритета, и нечего дефекты по порядку выстраивать», которая очень хорошо подводит к Zero Known Defects.

  3. Роман Журавлёв

    «За исключением отложенных задач и особых ситуаций типа major-инцидентов.»

    — Если я верно понимаю, Олег предлагает искоренить саму возможность отложенных задач. Взяли в работу — доделываем несмотря ни на что. А про ситуации типа major incidents и мне интересно, ждем ОС с ответом 🙂

    «А еще в предположении коротких задач, ведь чем длиннее задача, тем сложнее будет выдержать такой режим, ибо жизнь меняется.»

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

    "А еще в предположении, что каждую задачу решает один человек, потому что если это не так, то перераспределение ресурсов возможно и по ходу выполнения задачи. "

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

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

    Такое видение — прямо тема для отдельного поста; не столько потому, что в нем много нового (не много), а потому, что это драматически отличается от традиционного для ITIL понимания приоритета и поэтому драматично воспринимается привыкшими к ITIL менеджерами.

    1. Олег Скрынник Автор

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

      Было бы здорово, но не очень реалистично, к сожалению. Опыт показывает, что блокеры будут всё равно, потому что уж больно связана наша ИТ-инфарструктура внутри себя. Поэтому да, минимизировать число отложенных задач насколько возможно. То есть — целенаправленно бороться, а не наблюдать и не принимать как данность. Например, три работающих инструмента из практики разработки ПО:

      1. Попытаться предугадать блокер на этапе первичного формулирования задачи. Оказывается (к удивлению многих) это вполне возможно в большинстве случаев.

      2. Архитектурно развязывать модули и команды, чтобы уменьшить число сильных связей между ними (как избитый вариант — через feature teams).

      3. «Заворачивать» функциональность в активируемые блоки, а активацию производить тогда, когда блокер исчез. Тогда и задача не зависла, и другие не ждут, и блокер не мешает.

    2. Олег Скрынник Автор

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

      Так точно.

      Пока не встречал ни одного убедительного аргумента зачем делать задачи большими.

    3. Дмитрий Исайченко

      Вот. С этими комментариями и обсуждениями заметка стала и понятней, и интереснее. Потому что у этих идей хороший практический фундамент (по крайней мере в изложении Олега — 100%), но далеко не всегда понятные границы применимости. Ситуации разные, а утверждения типа «Управление через смену приоритетов не может приводить к созданию устойчивой системы» легко вырываются из контекста.

      Всем спасибо.

  4. ALEKSANDR ZHILINSKII

    Не успел отписать, когда обсуждение только начиналось. Хорошо, что оживилась дискуссия 🙂 От нас — все описанные Олегом принципы мы активно применяем при внедрении планов и очередей changes \ tasks, хотя мидл-менеджмент заказчика поглядывая сверху почти всегда считает, что живет в идеальном мире и никакой переприоритезации вообще не будет (а она наоборот есть вообще всегда). Очень тяжело осознать принцип, что бэклог съедает весь доступный ресурс.

    ps. сильносвязные задачи — зло

    pps. и вообще, последние лет шесть активно снимаем заказчика с иглы приоритезации в чистом (ITILовском виде) в том числе и с инцидентов\запросов, пока никто не умер

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

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

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

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

ОКТ
16
Учебный курс:
Основы ITIL® 4 (очно) 
ОКТ
16
Учебный курс:
Основы ITIL® 4 (очно)