Всем привет! Я Айыына Егорова, Agile Coach в inDrive. Хочу поделиться небольшим опытом работы с командами без спринтов с применением Kanban-метода. Cтатья будет полезна руководителям команд, скрам-мастерам и любым агентам изменений.

Вы узнаете, как быстро запустить работу в команде без спринтов: с чего начать, какими инструментами мы пользуемся в компании и какие ошибки нельзя допускать. Отдельно разберем пример проведения воркшопа STATIK в команде Localization.

Введение

Если у вас есть команда, которая устала от спринтов и хочет применять Kanban-метод, первое, в чем нужно разобраться — понять, подходит ли команде этот стиль работы.

В своей работе мы используем итеративно-инкрементальный процесс — подход к организации, в котором сочетается поэтапность и работа по инкрементам продукта (созданию его ценности). Один из примеров такого фреймворка — Scrum.

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

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

Что еще можно использовать?

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

Перейду к тому, как мы применяем практики Kanban в продуктовых и сервисных командах.

Kanban можно применять при следующих кейсах и потребностях:

• Потребность в выявлении скрытой работы.

• Потребность в выравнивании потока.

• Потребность в разгрузке потока и сотрудников.

• Потребность в предсказуемости поставки ценности.

• Сложные организационные условия и необходимость начать с чего-то уже сейчас.

• Четкие стрессоры и мотиваторы к изменениям — например, недовольство руководства, заказчика или команды.

Если организация не готова к резкому переходу на гибкие практики (например, на фреймворки масштабирования) или ей не подходят широко распространенные гибкие подходы, Kanban предлагает альтернативный подход к гибкости организации.

Что важно для начала использования Kanban?

Kanban-метод значительно повышает результативность команд, в которых постоянно возникает поток новых задач. Он применяется в разных сферах: от строительства до IT. Рекомендуется использовать все шесть практик Kanban, но самыми ценными для начала я посчитала две — визуализация и явные правила. Сначала расскажу про первую практику.

Визуализация работы

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

Зачем нужна визуализация:

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

• Отобразить блокирующие задачи, над которыми невозможно вести работу.

• Понять, какие виды работ выполняются. Например, карточки разного цвета для доработок и техдолга.

• Определить объем работы на каждом этапе и визуальное отображение исполнителей.

Хочу отменить, что в современном мире физические доски — большая редкость. Ниже поделюсь, какие инструменты для визуализации мы используем в inDrive.

1. Wrike

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

2. Jira

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

Явные правила

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

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

• Договоренности о времени выполнения.

• Критерии готовности (Когда можно считать задачу завершенной?).

• Критерии перемещения по статусам (Когда элемент может перемещаться из одного статуса в другой?).

• Критерии приоритизации (Какие задачи являются приоритетными?).

• Когда необходимо пополнять бэклог?

• Как долго элементы могут задерживаться в колонке?

• Пополнение при выборе новых задач.

Формирование правил и следование им необходимо, чтобы команда работала самостоятельно. Обсуждение и формирование договоренностей входит в подход STATIK. Он применяется, чтобы запустить Kanban-систему или найти точки роста текущей. Далее поэтапно разберу воркшоп STATIK на примере проведения в нашей команде Localization.

Описание системы через STATIK

Что это? System Thinking Approach to Introducing Kanban (STATIK) — подход, который упрощает запуск Kanban-системы. Это воркшоп, в котором нужно пройти определенные шаги: оценить задачи, проблемы и ожидания, приоритеты задач.

Для чего? STATIK проводят разные люди: менеджеры процессов, проектов и команд, которые хотят изменить процесс или запустить Kanban-систему. Обычно команды хотят понять, как Kanban может повлиять на процесс и как можно задизайнить первую Kanban-систему.

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

STATIK включает в себя восемь ключевых шагов, но некоторые мы пропустили и немного переделали воркшоп под себя. Далее я подробно расскажу, как проводила воркшоп в команде Localization. Перед нами стояла цель — добиться прозрачности процессов и найти точки улучшения.

Воркшоп для команды Localization

Команда Localization занимается переводами и локализацией приложения inDrive на разные языки. Мы разделили воркшоп с ними на две сессии по 120 минут, которые проводили с интервалом в одну неделю, чтобы ничего не забывать. Ниже пошагово расскажу о каждом этапе. Первая сессия включала в себя шаги 1-4, вторая — шаги 5-7.

Первый шаг. Что такое STATIK?

Время: 10-15 минут.

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

• Что такое STATIK? Зачем нужен и что даст?

• Когда и зачем применять подход?

• Какие будут шаги? Что будем делать на воркшопе?

• Сформировала правила встречи: участвовать, не отмалчиваться, присутствовать здесь и сейчас. Сделала упор на то, что нам даст встреча и зачем тратить на нее время.

Второй шаг. Ice-Breaker

Время: 10-15 минут.

Задание: закинуть мемасик или картинку, который отвечает на вопрос: «На что похож наш процесс?».

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

Третий шаг. Источники неудовлетворенности

Цель: определить точки роста и осознать, зачем команде меняться.

Время: 20-25 минут.

Формат: команда рассматривается как корабль, которому мешают якоря. Так проще выгрузить больше скрытых источников недовольства. Делим доску на две стороны: слева — внутренние источники, справа — внешние источники.

Задание:

1. Опишите внутренние источники неудовлетворенности вашей команды.

2. Опишите внешние источники неудовлетворенности заказчика.

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

Четвертый шаг. Анализ спроса и возможностей системы

Время: 40 минут.

Цель: посмотреть, насколько сервис востребован и какого типа задачи в него поступают.

Формат: распределяем тип работ.

Задание:

1. Написать на стикерах, над какими задачами сейчас работает команда.

2. Откуда приходит нагрузка? Что просит заказчик?

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

Примечание: задание делали с командой совместно, не разделяясь на подгруппы.

Пятый шаг. Жизненные циклы типов работ

Время: 35 минут.

Цель: понять, какие этапы проходит задача, как мы накапливаем знания о ней и поставляем ценность

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

Задание:

1. 5 минут — выбрать самый длинный и самый часто встречающийся тип работ.

2. 15 минут — объединить и разбить этапы, как происходит сейчас. Можно открыть нынешние статусы.

3. 10 минут — как понять, по какому принципу задачи переходят в следующий этап? Definition of Done, тригеры для каждого статуса.

Здесь важно смотреть не только на свою команду, но и рассматривать моменты до и после. Например, в каком статусе работа, когда попадает к нам?

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

Шестой шаг. Классы обслуживания

Время: 20 минут.

Цель: понять, как мы работаем с задачами

Формат: совместная командная работа, распределение типов задач по классам обслуживания.

Задание:

1. 10 минут — попросить команду привести примеры запросов всех типов в их конкретных ситуациях:

• Ускоренный. Рабочие задачи настолько срочные, что приходится откладывать выполнение других работ и немедленно переключиться на них.

• Фиксированная дата поставки. Рабочие задачи, невыполнение которых к конкретной дате приводит к наложению существенного штрафа, несопоставимого с любой выгодой от ранней поставки.

• Стандартный. Задачи, выполняемые в соответствии с порядком, согласованным с заказчиком.

2. 15 минут — распределение типов задач, к какому классу обслуживания относится.

Примечание: какие риски у вас связаны с различными типами запросов? Какова стоимость задержки?

Седьмой шаг. Дизайн Kanban-системы

Цель: зафиксировать дальнейшие шаги, что и когда мы будем вносить в систему.

Формат: понять, чего мы добились?

Вопросы для обсуждения:

• Как выглядит доска, заполненная рабочими задачами? Хватает ли на ней места?

• Насколько продвигаются рабочие задачи в интервале от одной летучки до другой?

• Понятна ли доска для тех, кому предстоит ей пользоваться?

Хорошая доска обеспечивает прозрачность. Необходимо улучшать поток и изменять доску так, чтобы в результате менялась сама система.

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

Итоги

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

2. Метод Kanban ориентирован на непрерывную поставку ценности. Вы можете использовать все практики метода, часть или применять только одну — нет строгого понятия, что работа идет по Kanban.

3. Визуализация как основа Kanban помогает видеть полную картину и отдельные части.

4. STATIK — классный воркшоп с последовательными действиями, который необходим для запуска новой Kanban-системы или улучшения текущей.

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