Как Канбан-метод повлиял на команды банка
Всем привет! Меня зовут Дмитрий. Я работаю senior Agile-коучем в ОТП Банке. Использую практики Канбан-метода в своей работе с 2019 года и хочу поделиться с вами своим опытом. В статье используются данные, собранные при работе с сервисной IT-платформой, состоящей из 8 команд (общая численностью около 70 человек).
Сервисная платформа не занимается исследованиями рынка и продуктов, а выполняет поставленные задачи от внутренних заказчиков, т.е. оказывает внутренний сервис.
Важным дополнением является то, что у большинства команд платформы задачи на своем пути реализации проходят несколько обязательных этапов и на каждом этапе работают разные специалисты.
В самом начале работы с командами выявили общие проблемы, которые требовали решения:
1. Много задач и все важные или непонятно, какие из них наиболее ценные для команды и организации.
2. Нет договоренностей по сдаче и приемке задачи (возвраты, доработки и отмены — частое явление).
3. Большая временная вилка, сроки исполнения не всегда предсказуемы.
4. Нет комплексной статистики по задачам (количество выполняемых задач за единицу времени, количество задач на руках, время выполнения задач, количество ресурсов в команде).
5. Отсутствует единая площадка для работы с заказчиками.
6. Много скрытой работы и этапов работ.
7. Задачи зависают на разных этапах, причины зависания не систематизировались и не проанализированы.
Для решения выявленных проблем мы предложили использовать практики Канбан-метода. Это позволяет точечно решить проблемы команд эволюционным путем без изменения сложившегося организационного уклада.
Основные практики Канбан-метода
Визуализируйте работу
Как мы визуализируем свою работу?
С помощью трекера задач. В нашем случае это JIRA от Atlassian.
Инструмент помогает нам видеть актуальное состояние задач со всех ракурсов. Все участники команд видят единую картину.
Команды могут визуально оценить загрузку этапов работ. Доска в JIRA отражает реальный путь реализации задач, представлены все этапы.
Мы договорились с командами о том, что все задачи будут заводиться в JIRA. Разработали совместно иерархию задач, определили типы поступающих запросов, определили точки принятия и возврата обязательств, провели трассировку рабочих элементов, что позволило создать единый жизненный цикл задач (workflow) для всех команд платформы.
Делайте правила работы явными
Для чего нам нужны правила и договоренности? Для того, чтобы все участники рабочего процесса понимали «правила игры».
Представьте, что к вам в команду вышел новый коллега. Если в команде много условностей и словесных договоренностей, новому коллеге потребуется значительное количество времени, чтобы разобраться в происходящем. Придется постоянно отвлекать коллег для ответов на вопросы, а они могли бы потратить это время на реализацию важных задач. Зафиксированные договоренности помогут вам сделать процесс более прозрачным и сократить время на понимание «как это работает».
Мы выделили правила работы следующего масштаба:
· Командные (Правила ведения задач, Правила работы команды и прочее, например, DoD — Defenition of Done).
· Межкомандные (Квотирование, Правила передачи задач между командами, например, DoR — Defenition of Ready).
· Уровня организации (Например, Playbook).
· Командные правила самостоятельно разрабатываются и фиксируются внутри команд. Это позволяет всем участникам команды работать в едином стиле. Задачи заводятся по определенным правилам, фиксируются все необходимые этапы на пути реализации задач, исходя из контекста команды и т.д.
· Межкомандные правила — это соглашения двух и более команд о правилах совместного взаимодействия. По каким правилам мы отдаем и принимаем задачи, какой минимальный набор информации мы должны передавать друг другу, чтобы понимать «что необходимо сделать» и «кто будет принимать задачу на выходе» и многое другое, что поможет лучше понимать друг друга.
· Правила уровня организации помогают выстраивать операционный ритм и аналитику в компании в едином стиле. Например, единый подход к оценке доступных ресурсов команд, набор применяемых скоринговых моделей, для оценки важности и срочности задач.
Нет требований описать каждое телодвижение коллег, но стоит зафиксировать минимально необходимый набор договоренностей, особенно в местах сосредоточения болей команд. Там, где раз за разом они испытывают сложности.
Ограничивайте работу «в процессе»
Очень часто складывается ситуация, при которой отдельные функции или команды перегружены работой. Когда ожидания и входящий объем работы превышают физические возможности команды, на помощь могут прийти различные подходы по искусственному ограничению количества задач, взятых в работу (WIP limit).
В качестве обоснования для применения ограничений мы используем закон Литтла:
Из данной формулы видно, что через изменение количества работы «в процессе» мы можем влиять на среднее время реализации задач. Чем меньше задач на руках, тем меньше времени мы тратим на переключение и погружение в контекст, что положительным образом влияет на скорость реализации.
При работе с командами мы используем следующие инструменты:
1. Персональные WIP-limit для разгрузки отдельного человека. То есть количество задач на отдельно взятого человека в момент времени. Исходя из нашего контекста, уровня подготовки коллег, типов и размеров задач, мы можем выбрать оптимальные значения для каждого из участников команды.
2. WIP-limit на этап работы, для разгрузки «узких горлышек» (узкие места) на пути реализации задач. Чтобы построить «вытягивающую систему», а также снять перегруз с отдельных этапов работ, мы можем использовать лимиты на этап работы и переходные этапы ожидания, когда работа выполнена на предыдущем этапе и ожидает, когда её возьмут на следующий по мере высвобождения ресурсов команды.
3. Ограничение на входящую очередь или квотирование на каждый вид активностей команды. Позволяет выстроить равномерный и предсказуемый поток поступающих задач по их типам. Данный инструмент используется в связке с оценкой «ёмкости» команды и размеров поступающих задач.
Ретроспективно оценив процентное соотношение поступающих задач по их типам и бизнес-направлениям, а также уточнив полученную информацию актуальным направлением стратегии, мы можем договориться о квотах на каждый вид деятельности. В этом случае внутренние заказчики понимают на какое количество ресурсов они могут рассчитывать, а команды-исполнители знают свои возможности на ближайший период и могут аргументированно влиять на количество задач в собственном бэклоге.
У нас нет правильных значений лимитов для всех команд или для всех коллег. Эти значения уникальны для каждого, т.к. у разных команд свой контекст, свой уровень экспертизы и различные объемы и сложность поступающих задач. Мы можем вывести их эмпирическим путем, и они могут меняться время от времени, исходя из сезонности, изменения стратегии и прочих внутренних и внешних факторов.
Вводите петли обратной связи
Канбан-метод предлагает набор встреч как тактического, так и стратегического уровня управления. Первым шагом для нас стала инвентаризация существующего операционного ритма платформы и команд. Часть необходимых встреч по синхронизации работы команд, долгосрочному планированию и планированию поставок уже существовали в жизни команд. Для выстраивания прозрачной цепочки поставки ценности, нам не хватало:
· Встречи по пополнению очереди задач, где мы могли бы обсуждать с внутренними заказчиками, что делать дальше.
· Обзор (ревью) потока задач, где можно оценить, как команды работают с операционными метриками.
На встречах по пополнению с заказчиками команды обсуждают статус и ход выполнения уже обещанных ранее задач, по запросу могут показать актуальные метрики, информируют заказчиков об объеме доступных ресурсов на ближайшую перспективу, заказчики обсуждают список актуальных приоритетов. На выходе со встречи рождается артефакт — утвержденный список задач для команды, которые необходимо взять в работу следующими.
В рамках обзора потока задач команды анализируют собственные метрики продуктивности. С помощью метрик и графиков в JIRA мы оцениваем актуальную скорость и пропускную способность команды, детально прорабатываем задачи из «хвоста» графика распределения выполненных задач, ищем негативные тренды и планируем мероприятия по улучшению.
Управляйте потоком работы
Для управления потоком работы команд мы используем инструменты, часть из которых представлена в базовом наборе Atlassian JIRA, возможно реализовать через дополнительную надстройку через апи или применить 3rdparty плагины. Накопительная диаграмма потока (Cumulative flow diagram) позволяет нам смотреть за динамикой поступления задач и загрузкой этапов работы. Здесь мы можем посмотреть нет ли у нас скопления задач на каком-то из этапов, правильно ли распределена нагрузка, равномерно ли мы поставляем задачи или есть простои. График отражает усредненное состояние нашего процесса на каждый момент времени, без привязки к конкретным задачам.
Диаграмма распределения (Lead Time distribution) показывает нам ретроспективную картину: сколько задач мы закрыли на выбранный период времени, за сколько дней/ недель мы закрыли ту или иную задачу. Можно проанализировать график с командой, найти среднее, медианное время выполнения задач, оценить вероятность, с которой мы можем поставлять тот или иной объем задач. В своей практике мы используем значение 85 перцентиля, чтобы синхронизировать ожидания команды и заказчиков. То есть мы даем обещание, что мы закроем 85 задач из 100 или 6 задач из 7 за определенный период времени (Lead Time).
Далее совместно с командой выявляем все задачи не попавшие в заявленные сроки, компенсируем негативные тренды и тем самым боремся с «хвостом» графика, чтобы наш процесс поставки ценности был максимально равномерен, прозрачен и предсказуем.
Структура (Structure) — отдельный настраиваемый вид отображения задач. С помощью этого инструмента мы помогаем командам превентивно сфокусироваться на подвисающих задачах, которые приближаются к заявленным срокам реализации, но по тем или иным причинам еще не завершены полностью. Регулярный мониторинг и анализ трендов помогают сократить количество забытых и неправильно оформленных задач, также выявить задачи, которые долго ожидают согласования или перехода на следующий этап работы.
Развивайтесь экспериментально, совершенствуйтесь совместно
· Не бойтесь ошибаться! Экспериментируйте.
· Договаривайтесь об изменениях внутри команды и с коллегами. Синхронизация намерений необходима, чтобы участники понимали, что вы хотите изменить, какими инструментами и что это может дать на выходе.
· Один и тот же инструмент может дать разный эффект в командах, исходя из их контекста. Размер наносимой пользы может отличаться.
· Каждая команда уникальна. Лечите то, что болит! Не копируйте слепо.
«Хороша ложка к обеду»
Покажу пример неудачного слепого копирования инструмента:
В самом начале работы с командами, было непреодолимое желание использовать очень полезный инструмент мониторинга целей и задач через структуру Atlassian. Я рассказал командам о том, что это за инструмент, как применялся раньше и для чего. Команды не были против инноваций и даже предварительно согласились, что это может быть полезно и для них. После выжигания некоего объема ресурсов, выполнения подготовительных работ и калибровки инструмента, оказалось, что он никому не нужен в настоящий момент и команды им не пользуются, хотя в другой организации инструмент был очень полезный и использовался еженедельно.
Причина была проста — инструмент не решал никакую из актуальных проблем команды, не являлся решением существующих болей.
Спустя почти год, когда у команд появился соответствующий запрос, мы вернулись к этому инструменту, видоизменили его под запрос и он обрёл новую жизнь.
Что получили?
После реализации первичных договоренностей о том, что все задачи будут заводиться в JIRA, мы сделали нулевой замер скорости реализации задач (Lead Time) и пропускной способности (Throughput).
Пошаговое применение практик в командах принесло существенные улучшения. Сравнивая показатели через год, мы видим, что скорость поставки ценности от команд улучшилась почти в 2 раза — Lead Time со 175 дней сократился до 93. Пропускная способность выросла почти в 5 раз и составила 321 вместо 65 задач.
Здесь стоит сделать ремарку и уточнить, что кроме существенного улучшения скорости, также повысилось качество декомпозиции задач. Мы договорились об иерархии и о количественном и качественном описании базовой единицы (задаче), с которой мы работаем, чтобы одновременно мы не сравнивали отдельные запросы клиентов и крупные годовые проекты.
Далее были проведены еще два замера с разницей в 1 квартал. Мы видим, что в обоих случаях сохраняется уровень пропускной способности команд в размере 300+ задач. Временное ухудшение показателя Lead Time связано с закрытием очень старых, крупных, но уже заявленных в реализацию проектов. Спустя квартал показатель вернулся к ожидаемым значениям в 80–90 дней.
В дополнение мы можем обратиться к накопительной диаграмме и оценить количество задач, которые находятся в бэклоге команды, также сколько работы у команд в работе (WorkInProcess). Улучшение скорости работы команд также неотъемлемо связано с применением ограничений на количество одновременно выполняемой работы.
Еще одна интересная метрика Discard rate — процентное соотношение отмененных задач к общему объему проделанной работы (выполненных задач). На основе этой метрики мы можем посмотреть какой объем задач не дождался наш внутренний клиент и отменил самостоятельно из-за потери актуальности, а может уже и сменился заказчик, пока мы делали работу для старого.
Какие мы сделали выводы:
Практики вкупе дают больший результат.
Лечим то, что болит!
Меньше изменений за 1 раз — меньше стресс.
Разговаривайте с командой, обсуждайте, выясняйте, какие сложности стоят перед командой, что они хотели бы улучшить. Это поможет заручиться поддержкой команды в последующих изменениях и снизить сопротивление.
