Все задачи срочные и важные: как навести порядок в системе, если приоритеты не работают
«Эта задача очень срочная, и не забывайте про вчерашние запросы — они мне нужны в первую очередь». Как часто вы слышали такое от заказчика? К сожалению, в условиях отсутствия WIP-лимитов подобные ситуации не редкость. И спустя какое-то время рабочая система будет просто переполнена различными запросами. Ведь мы не можем делать всё и сразу. В итоге — сроки не будут соблюдаться, задачи выполняться, а система работать всё медленнее и медленнее. Можно ли это исправить? В статье обсудим, почему не работают приоритеты и как использовать Cost of Delay, чтобы определить очередность задач
Как WIP-лимиты меняют отношение заказчика к выполнению задач
В прошлом материале цикла статей «Канбан просто» мы подробно разбирали, что такое WIP-лимиты. Напомню, что на Kanban-доске они обозначаются в виде специальных слотов и используются для ограничения количества задач, которые одновременно можно взять в работу.
А теперь давайте представим, что в нашей системе нет WIP-лимитов. Уже догадались, как она выглядит с точки зрения заказчика?
![](https://i0.wp.com/scrumtrek.ru/blog/wp-content/uploads/2024/08/image-1-jpg.webp?resize=640%2C295&ssl=1)
Конечно же, как и любой человек, которому попадается безлимитный тариф, наш заказчик «включает вентилятор» и начинает накидывать к вам в очередь работ столько задач, сколько может, ведь его ничто не ограничивает. И если в начале менеджер очень счастлив, ведь он загрузил вас работой и ожидает, что производительность вырастет, то спустя какое-то время он же замечает обратный эффект. Дело в том, что рабочая система окажется полностью забита запросами заказчика, она начнет работать все медленнее и медленнее, а время выполнения отдельной задачи будет только расти. В какой-то момент это станет настолько очевидным, что заказчик обязательно скажет: «Вы что-то очень медленно работаете. В чем дело?».
А ответ здесь может быть только один: «Вы превысили возможности нашей системы, и каждый следующий запрос будет выполняться еще дольше».
![](https://i0.wp.com/scrumtrek.ru/blog/wp-content/uploads/2024/08/image-2-jpg.webp?resize=640%2C295&ssl=1)
В свою очередь, если рабочий процесс выстраивается с учетом WIP-лимитов, он становится предсказуемым, устраняются потери от перегрузки, а еще WIP-лимиты меняют поведение людей. Давайте посмотрим, как это происходит.
Систему, в которой используются WIP-лимиты, можно сравнить с пунктами оплаты проезда на дороге, подъезд к которым разделен на полосы. У каждой полосы есть своя пропускная способность, и даже если мы захотим протолкнуть больше машин, а в нашем случае задач, мы не сможем этого сделать.
![](https://i0.wp.com/scrumtrek.ru/blog/wp-content/uploads/2024/08/image-3-jpg.webp?resize=640%2C295&ssl=1)
Заказчик, глядя на эти явные, обозначенные правила работы с системой начинает задумываться о том, что если невозможно одновременно выполнить все запросы, значит, их нужно как-то дифференцировать. Например:
- обозначить задачи, которые нужно выполнить в первую очередь,
- далее выделить запросы второй очереди, которые можно взять в работу позднее,
- а еще определить вопросы, решение которых можно отложить.
Таким образом, само наличие ограничения явным образом побуждает заказчика изменить свое поведение. Ведь ресурсы ограничены, и нужно решать, какие задачи действительно нужно и важно взять в работу.
Приоритеты не работают. Что использовать вместо них?
Итак, чтобы определить очередность выполнения задач, их нужно приоритизировать! Давайте определим приоритет каждой задачи, и вопрос решен. К сожалению, практика показывает, что определить приоритет для всех задач довольно сложно.
Давайте рассмотрим на конкретных примерах, чем может определяться приоритет задачи?
![](https://i0.wp.com/scrumtrek.ru/blog/wp-content/uploads/2024/08/priority1-jpg.webp?resize=640%2C295&ssl=1)
Кейс #1 Поздравляем, вы первый в очереди. Представьте начало рабочего дня. На часах 8.56, когда внезапно вбегает менеджер со словами: «Ура! Я первый, держите задачу в работу». Вы её берете и ставите первой в очередь работ на день. Значит ли это, что приоритет задачи определяется простой очередностью их поступления? Допустим, мы решили, что это так. Давайте рассмотрим следующий пример.
![](https://i0.wp.com/scrumtrek.ru/blog/wp-content/uploads/2024/08/priority2-jpg.webp?resize=640%2C295&ssl=1)
Кейс #2 Шеф, всё пропало. Следом приходит второй менеджер с криками: «Караул! У нас авария, нужно это срочно пофиксить». Очевидно, это так, и вы ставите новую задачу выше предыдущей в очереди приоритетов. Получается, что эта новая задача становится самой приоритетной. В таком случае, значит ли это, что приоритет определяется срочностью? Пожалуй, это тоже справедливо. Смотрим дальше.
![](https://i0.wp.com/scrumtrek.ru/blog/wp-content/uploads/2024/08/priority3-jpg.webp?resize=640%2C295&ssl=1)
Кейс #3 Вопрос на миллион. И вот в самый разгар рабочего дня в дверях появляется тот самый первый менеджер со словами: «У меня задача с потрясающим финансовым эффектом. Мы миллионы на ней заработаем! Делайте ее в первую очередь». Что мы теперь должны делать с очередью задач? У нас там уже срочная задача и задача, которая пришла первой утром. Но финансовый эффект тоже очень важен! Стоит ли нам поставить задачу на миллионы в самое начало очереди? Или нет? Решение не так уж очевидно. Но и это еще не все.
![](https://i0.wp.com/scrumtrek.ru/blog/wp-content/uploads/2024/08/priority4-jpg.webp?resize=640%2C295&ssl=1)
Кейс #4 Кто здесь самый главный анархист менеджер? А что если к нам заглянет Самый Главный Босс (СГБ) и принесет свою приоритетную задачу? Он Самый Главный! Главнее него никого нет! Значит ли это, что мы должны его задачу поставить по приоритету выше, чем срочную задачу, и выше задачи на миллионы? Как принять решение? От чего отталкиваться? Непонятно…
Как вы могли заметить, в каждом из примеров приоритет определяется разными параметрами, которые лежат в разной плоскости, и сравнивать их между собой напрямую — почти невыполнимая задача. Получается, что само понятие «приоритет задачи» довольно неоднозначное. В зависимости от текущей точки зрения и выбранного параметра приоритет задач в очереди может мгновенно меняться с точностью до наоборот.
Именно поэтому Канбан-метод предлагает использовать другую метрику — Cost of Delay (CoD) или Стоимость задержки.
Cost of Delay: как стоимость задержки влияет на очередность задач
Понять, как работает Cost of Delay, можно на простом примере из жизни.
![](https://i0.wp.com/scrumtrek.ru/blog/wp-content/uploads/2024/08/cod-0-jpg.webp?resize=640%2C295&ssl=1)
Давайте представим, что ваш рабочий день начинается в 10 часов утра, а путь до работы занимает 1 час.
Допустим, в понедельник вы решили проснуться пораньше и вышли из дома с большим запасом — за 2 часа. В данному случае CoD равен нулю, ведь у вас масса времени, чтобы добраться до работы.
![](https://i0.wp.com/scrumtrek.ru/blog/wp-content/uploads/2024/08/cod_1-jpg.webp?resize=640%2C295&ssl=1)
Но во вторник вы проспали и выбегаете из дома только в 9.30. До работы добираться целый час, начинаются ужасные пробки, и с каждой минутой стоимость задержки выхода из дома для вас стоит всё дороже и дороже — как с точки зрения времени, потому что пробки всё растут, а значит, увеличивается и время опоздания, так и с точки зрения последствий: задержаться на 10 минут = опоздать на целый час, разница очень существенная. Каждая следующая минута будет дороже предыдущей, то есть Cost of Delay резко возрастает в момент, когда вы вышли из дома.
Этот класс обслуживания Expedite — срочный. К нему мы относим задачи, где каждая минута промедления стоит нам больших финансовых или временных издержек.
![](https://i0.wp.com/scrumtrek.ru/blog/wp-content/uploads/2024/08/cod-2-jpg.webp?resize=640%2C295&ssl=1)
В среду вы проснулись вовремя. Сейчас на часах уже 8.20, и у вас еще есть время до момента икс — когда на маршруте начнёт возникать серьезный транспортный коллапс. Но если вы выйдете позже 9:00, то снова попадете в ситуацию Expedite, когда каждая следующая минуту дороже предыдущей.
Этот класс обслуживания называется Fixed date или в нашем случае Fixed time. Это ситуация, когда точно известен момент времени, после которого наступают негативные последствия, и каждая минута этих последствий стоит нам всё дороже и дороже.
![](https://i0.wp.com/scrumtrek.ru/blog/wp-content/uploads/2024/08/cod-3-jpg.webp?resize=640%2C295&ssl=1)
Наступил четверг, и вы договорились встретиться с другом. Если вы будете опаздывать, он, конечно, подождет вас, но вряд ли это будет длиться бесконечно. С каждой минутой вашего опоздания его нетерпение будет нарастать, и спустя какое-то время он просто уйдет. В данном случае CoD нарастает постепенно и плавно до какого-то определенного значения — это задача с классом обслуживания Regular.
![](https://i0.wp.com/scrumtrek.ru/blog/wp-content/uploads/2024/08/cod-4-jpg.webp?resize=640%2C295&ssl=1)
И давайте рассмотрим еще один вариант. Предположим, вы регулярно опаздываете на работу, вам это пока сходит с рук, но только до какого-то определенного момента, пока вашему руководителю это не надоест, и тогда он вас уволит. Обычно в реальном проекте это может касаться задач развития, когда вы что-то очень долго откладываете. Например, не делаете автотестирования, забиваете на инженерные практики или отсутствие достаточного места на сервере. Это класс обслуживания Intangible, негативные последствия наступают резко и обрушиваются со всей разрушительной силой, если долгое время не обращать внимание на проблему.
Четыре класса обслуживания позволяют универсальным образом сравнивать разные задачи между собой и прозрачно выстраивать очередность загрузки рабочей системы. Кстати, данные шаблоны не единственно возможные, довольно часто добавляют промежуточные варианты, подходящие под конкретную ситуацию.
На Канбан-доске классы визуализируются в виде горизонтальных беговых дорожек, а их количество ограничивается определенным лимитом. В противном случае у менеджера может возникнуть большой соблазн присвоить всем задачам класс обслуживания Expedite, и тогда мы вернемся к той ситуации, с которой начали: все задачи срочные и важные, мы ничего не успеваем, а система снова перегружена запросами. Поэтому на основании имеющейся статистики за прошлые периоды мы смотрим на распределение задач (каких запросов было меньше, а каких — больше) и выделяем определенные квоты на разные классы обслуживания.
![](https://i0.wp.com/scrumtrek.ru/blog/wp-content/uploads/2024/08/image-4-jpg.webp?resize=640%2C295&ssl=1)
Теперь перед тем, как взять в работу задачу, заказчик должен ответить на вопрос: к какому классу обслуживания она относится? И в зависимости от типа задачи и ее класса обслуживания мы сможем дать менеджеру объективный и понятный прогноз по времени выполнения. Как считаете, в вашей компании использование классов обслуживания поможет эффективнее договариваться менеджерам и разработчикам?
Если у вас остались вопросы, буду рад ответить в комментариях после статьи или в моем Телеграм-канале «Данные в дейSTвии».
![](https://i0.wp.com/scrumtrek.ru/blog/wp-content/uploads/2024/03/image-19-jpg.webp?resize=302%2C172&ssl=1)
Сроки сдвигаются, система ломается, предсказуемость стремится к нулю — так влияют аномалии на бизнес-процессы. Как обнаружить аномалии и какие контрмеры помогут их устранить? Разберем на реальных примерах, а также обсудим, что такое и для чего нужны диаграмма рассеяния Lead Time и Накопительная диаграмма потока (CFD)
![](https://i0.wp.com/scrumtrek.ru/blog/wp-content/uploads/2024/02/image-5-jpg.webp?resize=302%2C172&ssl=1)
В новом материале цикла статей «Канбан просто» я расскажу, почему «сгорают» незавершенные задачи, как визуализировать ограничения, чтобы наладить диалог с бизнесом и повысить предсказуемость процесса и, конечно, как в этом нам помогут Канбан-доска и WIP-лимит.
![](https://i0.wp.com/scrumtrek.ru/blog/wp-content/uploads/2024/01/main-pic2-jpg.webp?resize=302%2C172&ssl=1)
У меня для вас 2 новости. Хорошая: вы уже знаете, что отвечать на вопрос менеджера: «Когда будет готова задача?». Плохая: это еще не всё, он обязательно спросит: «А почему так долго?». В статье расскажу, почему появляются заторы в задачах, как их обнаружить и эффективно устранить, и чем здесь будет полезен Канбан и, в частности, Канбан-доска.