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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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