Все задачи срочные и важные: как навести порядок в системе, если приоритеты не работают

«Эта задача очень срочная, и не забывайте про вчерашние запросы — они мне нужны в первую очередь». Как часто вы слышали такое от заказчика? В статье обсудим, почему не работают приоритеты и как использовать Cost of Delay, чтобы определить очередность задач.

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

А теперь давайте представим, что в нашей системе нет WIP-лимитов. Уже догадались, как она выглядит с точки зрения заказчика?

Конечно же, как и любой человек, которому попадается безлимитный тариф, наш заказчик «включает вентилятор» и начинает накидывать к вам в очередь работ столько задач, сколько может, ведь его ничто не ограничивает. И если в начале менеджер очень счастлив, ведь он загрузил вас работой и ожидает, что производительность вырастет, то спустя какое-то время он же замечает обратный эффект. Дело в том, что рабочая система окажется полностью забита запросами заказчика, она начнет работать все медленнее и медленнее, а время выполнения отдельной задачи будет только расти. В какой-то момент это станет настолько очевидным, что заказчик обязательно скажет: «Вы что-то очень медленно работаете. В чем дело?».

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

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

Систему, в которой используются WIP-лимиты, можно сравнить с пунктами оплаты проезда на дороге, подъезд к которым разделен на полосы. У каждой полосы есть своя пропускная способность, и даже если мы захотим протолкнуть больше машин, а в нашем случае задач, мы не сможем этого сделать.

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

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

Итак, чтобы определить очередность выполнения задач, их нужно приоритизировать! Давайте определим приоритет каждой задачи, и вопрос решен. К сожалению, практика показывает, что определить приоритет для всех задач довольно сложно.

Давайте рассмотрим на конкретных примерах, чем может определяться приоритет задачи?

Кейс 1. Поздравляем, вы первый в очереди. Представьте начало рабочего дня. На часах 8.56, когда внезапно вбегает менеджер со словами: «Ура! Я первый, держите задачу в работу». Вы её берете и ставите первой в очередь работ на день. Значит ли это, что приоритет задачи определяется простой очередностью их поступления? Допустим, мы решили, что это так. Давайте рассмотрим следующий пример.

Кейс 2. Шеф, всё пропало. Следом приходит второй менеджер с криками: «Караул! У нас авария, нужно это срочно пофиксить». Очевидно, это так, и вы ставите новую задачу выше предыдущей в очереди приоритетов. Получается, что эта новая задача становится самой приоритетной. В таком случае, значит ли это, что приоритет определяется срочностью? Пожалуй, это тоже справедливо. Смотрим дальше.

Кейс 3. Вопрос на миллион. И вот в самый разгар рабочего дня в дверях появляется тот самый первый менеджер со словами: «У меня задача с потрясающим финансовым эффектом. Мы миллионы на ней заработаем! Делайте ее в первую очередь». Что мы теперь должны делать с очередью задач? У нас там уже срочная задача и задача, которая пришла первой утром. Но финансовый эффект тоже очень важен! Стоит ли нам поставить задачу на миллионы в самое начало очереди? Или нет? Решение не так уж очевидно. Но и это еще не все.

Кейс 4. Кто здесь самый главный менеджер? А что если к нам заглянет Самый Главный Босс (СГБ) и принесет свою приоритетную задачу? Он Самый Главный! Главнее него никого нет! Значит ли это, что мы должны его задачу поставить по приоритету выше, чем срочную задачу, и выше задачи на миллионы? Как принять решение? От чего отталкиваться? Непонятно…

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

Именно поэтому Канбан-метод предлагает использовать другую метрику — Cost of Delay (CoD) или Стоимость задержки.

Понять, как работает Cost of Delay, можно на простом примере из жизни.

Давайте представим, что ваш рабочий день начинается в 10 часов утра, а путь до работы занимает 1 час.

Допустим, в понедельник вы решили проснуться пораньше и вышли из дома с большим запасом — за 2 часа. В данному случае CoD равен нулю, ведь у вас масса времени, чтобы добраться до работы.

Но во вторник вы проспали и выбегаете из дома только в 9.30. До работы добираться целый час, начинаются ужасные пробки, и с каждой минутой стоимость задержки выхода из дома для вас стоит всё дороже и дороже — как с точки зрения времени, потому что пробки всё растут, а значит, увеличивается и время опоздания, так и с точки зрения последствий: задержаться на 10 минут = опоздать на целый час, разница очень существенная. Каждая следующая минута будет дороже предыдущей, то есть Cost of Delay резко возрастает в момент, когда вы вышли из дома.

Этот класс обслуживания Expedite — срочный. К нему мы относим задачи, где каждая минута промедления стоит нам больших финансовых или временных издержек.

В среду вы проснулись вовремя. Сейчас на часах уже 8.20, и у вас еще есть время до момента икс — когда на маршруте начнёт возникать серьезный транспортный коллапс. Но если вы выйдете позже 9:00, то снова попадете в ситуацию Expedite, когда каждая следующая минуту дороже предыдущей.

Этот класс обслуживания называется Fixed date или в нашем случае Fixed time. Это ситуация, когда точно известен момент времени, после которого наступают негативные последствия, и каждая минута этих последствий стоит нам всё дороже и дороже.

Наступил четверг, и вы договорились встретиться с другом. Если вы будете опаздывать, он, конечно, подождет вас, но вряд ли это будет длиться бесконечно. С каждой минутой вашего опоздания его нетерпение будет нарастать, и спустя какое-то время он просто уйдет. В данном случае CoD нарастает постепенно и плавно до какого-то определенного значения — это задача с классом обслуживания Regular.

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

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

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

Теперь перед тем, как взять в работу задачу, заказчик должен ответить на вопрос: к какому классу обслуживания она относится? И в зависимости от типа задачи и ее класса обслуживания мы сможем дать менеджеру объективный и понятный прогноз по времени выполнения. Как считаете, в вашей компании использование классов обслуживания поможет эффективнее договариваться менеджерам и разработчикам?

Подписывайтесь на наш ТГ-канал, чтобы не пропустить интересные материалы из мира современного менеджмента.

Автор: Василий Савунов, Agile-коуч и эксперт ScrumTrek