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

Как WIP-лимиты меняют отношение заказчика к выполнению задач

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

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

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

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

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

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

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

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

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

Приоритеты не работают. Что использовать вместо них?

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

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

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

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

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

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

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

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

Cost of Delay: как стоимость задержки влияет на очередность задач

Понять, как работает 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, и тогда мы вернемся к той ситуации, с которой начали: все задачи срочные и важные, мы ничего не успеваем, а система снова перегружена запросами. Поэтому на основании имеющейся статистики за прошлые периоды мы смотрим на распределение задач (каких запросов было меньше, а каких — больше) и выделяем определенные квоты на разные классы обслуживания.

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

Если у вас остались вопросы, буду рад ответить в комментариях после статьи или в моем Телеграм-канале «Данные в дейSTвии».