Классы обслуживания в Канбан: ставим класс задачам

2024-10-24 09:15

Любая производственная система, будь то продуктовая команда или штат сотрудников, имеет свои ограничения в производительности. И хорошо, если это ограничение известно: скажем, измеряется пропускная способность системы, за счет чего понятно, сколько запросов система может выполнять в определенный период времени. С этими данными заказчик и команда понимают, что они вынуждены выбирать, над чем работать сейчас, а что – отложить на потом. Чтобы планировать очередность выполнения работ, в Канбан методе используют классы обслуживания.

Класс обслуживания (Сlass of Service) – это категория, которую можно назначить входящему запросу, чтобы определить очередность его выполнения для достижения максимальной выгоды бизнесом.

Внедрив классы обслуживания, можно игнорировать сиюминутные хотелки и не только

Далее в статье:

зачем нужны классы обслуживания, если есть старая добрая приоритизация;
что такое стоимость задержки и какие у нее есть паттерны;
какие бывают классы обслуживания: рассказываем на примерах;
как внедрить классы обслуживания в свою систему.

Если вам необходимо внедрение современных управленческих практик – обратитесь в Neogenda. За нами более 100 успешных управленческих кейсов и более 5 000 обученных сотрудников в таких компаниях, как Tinkoff, Яндекс, Авито, Сбер, Билайн, Skyeng и так далее. Оставьте заявку на бесплатную консультацию – мы предложим индивидуальное решение, с которым ваша команда достигнет лучших результатов.

Зачем нужны классы обслуживания, если есть старая добрая приоритизация

Кто-то из читателей может про себя, или даже вслух, воскликнуть: «Да зачем мне эти ваши классы обслуживания, если есть приоритизация задач? Неужели я сам не пойму, что важно, а что – нет?»

А мы хотим спросить: от чего вы отталкиваетесь, приоритизируя задачи?

Чтобы вам было проще, приведем несколько критериев, которые часто используют для той самой приоритизации:

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

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

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

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

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

Если менеджер приоритизирует запросы, он оценивает их важность на текущий момент, отчего приоритизация теряет смысл. Со временем одни запросы становятся более важные, чем другие, а еще прилетают новые запросы, которые конкурируют в важности со старыми. А еще может случиться какой-нибудь форс-мажор, из-за которого придется делать что-то еще. Например, из РФ начнет уходить какой-нибудь сервис: в один момент придется отложить все задачи и заняться переездом с одного сервиса на другой.

Поэтому в Канбане считается, что упорядочивание беклога – бесполезная трата времени. Нужно брать самый важный запрос в работу здесь и сейчас, когда на это появился свободный ресурс.

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

Не так быстро, Райан

Альтернативное мнение от Neogenda. Приоритизация нужна, если ее выполнять правильно и к месту. Скажем, в том же Scrum спринты планируют заранее, чтобы команда настроилась на работу и быстрее доносила ценность продукта на рынок. Некоторые функции продукта могут быть слишком комплексными – если менять очередность выполнения задач на ходу, велика вероятность, что какое-то крупное обновление продукта выйдет очень нескоро. Как правило, спринты длятся от двух недель до месяца – такого горизонта планирования достаточно, чтобы сосредоточиться на чем-то одном, оставив при этом возможность своевременно реагировать на внешние изменения.

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

Что такое стоимость задержки и какие у нее есть паттерны

Стоимость задержки (Cost of Delay) – это метрика, которая выражается в денежном эквиваленте и указывает, сколько компания потеряет денег, если не выполнит тот или иной запрос вовремя.

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

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

Скриншот взят из книги «Канбан метод. Базовая практика» эксперта Neogenda – Алексея Пименова

По горизонтали на графике отражено время, а по вертикали – прибыль, которую можно было бы заработать, если б мы выполнили запрос вовремя.

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

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

Ускоренный.

Паттерн «Ускоренный». Этот и последующие скриншоты с паттернами тоже взяты из книги Алексея Пименова

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

Фиксированная дата.

Паттерн «Фиксированная дата»

Здесь прибыль тоже растет буквально в момент, но не сразу после внедрения, а в определенную дату. Скажем, это может быть внедрение акции, приуроченной к Черной Пятнице.

Регулярный.

Паттерн «Регулярный»

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

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

Нематериальный.

Паттерн «Нематериальный»

Запросы, относящиеся к этому виду, принесут прибыль только через определенное время, и то, с определенной вероятностью.

Эти паттерны мы разобрали неспроста – они напрямую влияют на скорость выполнения запросов. По сути, по ним и определяют, к какому классу обслуживания отнести тот или иной запрос.

Расскажем о последних подробнее.

Какие бывают классы обслуживания: рассказываем на примерах

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

Разные типы работ могут относиться к разным классам обслуживания: в этом плане каких-то закономерностей нет.

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

Типы работ и классы обслуживания, к которым они могут относиться

Ускоренный.

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

Кстати, это единственный класс обслуживания, который позволяет пренебречь WIP-лимитами при выполнении задачи.

Фиксированная дата.

Запросы такого типа лучше выполнять в тот момент, когда времени осталось ровно столько, чтобы успеть к дедлайну. Такую дату начала работ называют последним ответственным моментом (Last Responsible Moment). Не стоит брать запросы этого класса в работу заранее – компания упустит прибыль, которую могла бы получить в это же время, выполнив какой-нибудь другой запрос.

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

Чтобы узнать реальное время от взятия задачи в работу до сдачи ее заказчику, в Канбан методе используют метрику Lead Time. Подробнее о этой метрике мы рассказали в статье «Lead Time и Cycle Time» – рекомендуем к прочтению. Если коротко, то мы не можем быть на 100 % уверены в том, что выполним запрос к определенному времени – мы можем лишь построить прогноз с определенной долей вероятности. Знание своего Lead Time позволяет строить эти прогнозы, чтобы вычислить последний ответственный момент, в который нужно брать запрос в работу.

Регулярный.

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

Нематериальный.

Запросы этого класса выполняются тогда, когда у исполнителя появляется свободное время – промедление с их выполнением не приносит вреда бизнесу. Но за такими запросами нужно следить, потому что со временем они могут переквалифицироваться в «Ускоренные».

Например, у CMS интернет-магазина заказчика вышло новое обновление, которое нужно установить, но на качество работы сайта это никак не влияет – обновление отложили. После заказчику понадобилось внедрить на сайт определенную функцию, которая реализована в виде готового модуля, доступного на маркетплейсе CMS. Но чтобы установить этот модуль, нужно обновить магазин до последней версии, а уже сам модуль способен обеспечить заказчика прибылью в короткий срок. Следовательно, из паттерна «Нематериальный» задача переквалифицировалась в паттерн «Ускоренный».

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

А теперь к самой интересной, прикладной части – расскажем, как подружить вашу организацию со всем этим.

Как внедрить классы обслуживания в свою производственную систему: пошаговая инструкция

1. Познакомьте заказчика с паттернами задержки.

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

2. Определите типы рабочих элементов.

Классифицируйте задачи по какому-либо признаку. Пример был на скриншоте выше.

3. Задайте подходящие классы обслуживания.

Скорее всего, у вас будут стандартные классы обслуживания из списка выше.

4. Пропишите к каждому классу соглашение об уровне обслуживания (SLA).

Соглашение об уровне обслуживания – это правила выполнения запросов такого или иного класса, которые могут быть документально зафиксированы. SLA положительно влияет на доверие со стороны заказчика. Там указывают время реагирования на запрос того или иного класса и время на его выполнение.

5. Работайте, анализируйте ход работ и при необходимости корректируйте ваши действия.

Главная цель Kanban – постоянное улучшение рабочих процессов. Изменения поощряются, если они приводят к росту.

Если вам нужно внедрить Канбан метод в компанию – обратитесь в Neogenda. Мы являемся экспертами по современным подходам и методам менеджмента. За нами более 100 успешных управленческих кейсов и 5 000 обученных сотрудников в таких компаниях, как Tinkoff, Яндекс, Авито, Сбер, Билайн, Skyeng и так далее. Оставьте заявку на бесплатную консультацию в Zoom – мы предложим лучшее решение для вашей задачи.

Мария Савельева