Клиенты и стейкхолдеры всегда задают один и тот же вопрос: «Когда это будет готово?». Традиционно команды разработчиков отвечают на него с помощью экспертных оценок, пытаясь угадать время в часах или абстрактных стори-поинтах. Проблема в том, что в интеллектуальном труде угадать точный срок практически невозможно из-за высокой неопределенности.
В Канбан-методе для ответа на этот вопрос используется Service Level Expectation (SLE), или Ожидаемый уровень сервиса. Это не жесткий дедлайн и не клятва на крови. Это математически обоснованный вероятностный прогноз, который показывает, за какое время команда способна пропустить одну задачу через весь свой рабочий процесс.
Из чего состоит SLE и как его рассчитать
Согласно официальному Kanban Guide, Ожидаемый уровень сервиса всегда состоит из двух неразрывных элементов: периода прошедшего времени и вероятности (уровня уверенности).
Правильно сформулированный SLE звучит так: «85 процентов наших задач завершаются за 8 дней или меньше». Вы не говорите, что сделаете конкретную задачу ровно за 8 дней. Вы говорите, что, опираясь на вашу историю, у вас есть 85-процентная уверенность в этом сроке.
Чтобы рассчитать этот показатель, вам не нужно проводить долгие сессии планирования. Вы просто берете исторические данные вашей команды о времени выполнения задач (Cycle Time) за последние несколько недель. Построив диаграмму рассеяния (Scatterplot), вы находите отметку, ниже которой находится 85% всех успешно завершенных карточек. Это число и становится вашим внутренним стандартом.
Сравнение ожиданий и обязательств
Многие путают SLE с классическими SLA, которые часто используются в ИТ-поддержке. Разница между ними фундаментальна.
| Характеристика | Service Level Expectation (SLE) | Service Level Agreement (SLA) |
|---|---|---|
| Природа метрики | Внутренний вероятностный прогноз команды | Внешний юридический или бизнес-контракт |
| На чем основан | На реальных исторических данных (Cycle Time) | На желаниях клиента или требованиях бизнеса |
| Цель использования | Улучшение потока, поиск заторов и управление рисками | Фиксация обязательств и расчет штрафов за их нарушение |
| Отношение к просрочкам | Превышение SLE — это повод для анализа и помощи задаче | Превышение SLA — это провал и нарушение договора |
Глубокое погружение: SLE как инструмент управления потоком
Ожидаемый уровень сервиса — это не просто цифра для отчета перед руководством. Это ежедневный рабочий инструмент, который радикально меняет поведение команды на стендапах (Daily Scrum или Kanban Meeting).
Вся магия SLE раскрывается, когда вы начинаете сравнивать его с метрикой Work Item Age (Возраст элемента работы). Допустим, ваш SLE составляет 10 дней с вероятностью 85%. На утренней встрече команда смотрит на доску и видит задачу, которая находится в работе уже 8 дней. Это сигнал тревоги. Задача стремительно приближается к границе вашего прогноза. Вместо того чтобы брать новые тикеты, разработчики применяют практику роения (Swarming) — объединяют усилия, чтобы протолкнуть эту стареющую задачу к финишу и уложиться в свой SLE.
Второе важное применение SLE — это фильтр на входе. Ожидаемый уровень сервиса помогает команде правильно нарезать задачи (декомпозировать их). Если на этапе уточнения бэклога разработчики смотрят на новую задачу и понимают, что она явно не влезет в их стандартный SLE (например, в те самые 10 дней), значит, задача слишком велика. Ее нельзя брать в работу в таком виде, ее необходимо разбить на более мелкие и независимые части.
Резюме: Уверенность вместо надежды
Service Level Expectation переводит разговор о сроках с языка интуиции на язык статистики и управления рисками.
Ключевой вывод состоит в том, что SLE защищает команду от нереалистичных ожиданий и дает ей четкий внутренний ориентир. Когда у вас есть прозрачный, основанный на данных прогноз, вы перестаете тушить пожары и начинаете системно управлять потоком создания ценности.
Часто задаваемые вопросы (FAQ)
В этом случае Kanban Guide рекомендует сделать экспертное предположение (best guess). Договоритесь о разумном сроке, который кажется команде реалистичным. Как только вы закроете первые 10-20 задач, у вас появится реальная статистика Cycle Time, и вы сможете заменить первоначальную догадку на математически точный SLE.
Стопроцентную гарантию в разработке дать невозможно из-за форс-мажоров и внешних зависимостей. Использование медианы (50%) слишком рискованно, так как половина задач будет просрочена. 85-й процентиль признан индустриальным стандартом, так как он обеспечивает надежный баланс между предсказуемостью для бизнеса и учетом естественной вариативности сложной работы.
Да. Часто команды устанавливают отдельные ожидания для разных классов обслуживания. Например, для стандартных продуктовых задач SLE может составлять 14 дней, а для критических багов (Expedite) — 2 дня с вероятностью 95%. Главное, чтобы эти правила были явно визуализированы на доске.
Нет. SLE — это отражение реальной пропускной способности системы. Его не устанавливают волевым решением, его вычисляют из исторических данных Команды разработчиков. Скрам-мастер лишь помогает команде собрать эти данные и научиться использовать их на ежедневных встречах.
Если исторические данные показывают, что ваш 85-й процентиль вырос с 8 до 15 дней, вам нужно обновить SLE, чтобы он отражал реальность. Параллельно команда должна вынести этот вопрос на Ретроспективу. Рост времени выполнения обычно означает, что у вас переполнены лимиты WIP, появились скрытые очереди или задачи стали слишком крупными.