Всем привет! Меня зовут Дмитрий. Я работаю senior Agile‑коучем в ОТП Банке. Использую практики Канбан‑метода в своей работе с 2019 года и хочу поделиться с вами своим опытом. В статье используются данные, собранные при работе с сервисной IT‑платформой, состоящей из 8 команд (общая численностью около 70 человек).
Сервисная платформа не занимается исследованиями рынка и продуктов, а выполняет поставленные задачи от внутренних заказчиков, т. е. оказывает внутренний сервис.
Важным дополнением является то, что у большинства команд платформы задачи на своем пути реализации проходят несколько обязательных этапов и на каждом этапе работают разные специалисты.
В самом начале работы с командами выявили общие проблемы, которые требовали решения:
Много задач и все важные или непонятно, какие из них наиболее ценные для команды и организации.
Нет договоренностей по сдаче и приемке задачи (возвраты, доработки и отмены — частое явление).
Большая временная вилка, сроки исполнения не всегда предсказуемы.
Нет комплексной статистики по задачам (количество выполняемых задач за единицу времени, количество задач на руках, время выполнения задач, количество ресурсов в команде).
Отсутствует единая площадка для работы с заказчиками.
Много скрытой работы и этапов работ.
Задачи зависают на разных этапах, причины зависания не систематизировались и не проанализированы.
Для решения выявленных проблем мы предложили использовать практики Канбан‑метода. Это позволяет точечно решить проблемы команд эволюционным путем без изменения сложившегося организационного уклада.
Основные практики Канбан-метода
Визуализируйте работу
Как мы визуализируем свою работу?
С помощью трекера задач. В нашем случае это 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 раз — меньше стресс.
Разговаривайте с командой, обсуждайте, выясняйте, какие сложности стоят перед командой, что они хотели бы улучшить. Это поможет заручиться поддержкой команды в последующих изменениях и снизить сопротивление.
Комментарии (5)
reinmaker1990
26.03.2024 06:54+1Сразу скажу, что некоторые инструменты и практики канбан метода мне импонируют, но статьи о нем прям как под копирку, не интересно скажем так.
Далее вопросы :
У вас было упоминание что команда смотрит метрики своей производительности, как вы к этому пришли ну и каково было объяснение этого команде, например если я инженер моя метрика это контрибюты в гитлаб и качественный код, у инженера качества это актуальные АТ и сведение к нулю багов в проде. Какую проблему для себя я решу этой метрик ой производительности, ведь код написан, задеплоен, это пахнет больше KPI
Были ли у вас в практике при построении досок с кучей статусов, а если в неё включать буферные статусы, то их действительно будет куча, отторжения на стороне команд, типа jira development, нафиг все это надо, как объясняли ценность именно для команды этих статусов, тут добавим условие что поинт о том что это визуализация полезна для наших заказчиков их не волнует, вот ты коач, ты иди и визуализируй, отчитывайся как хочешь им
Вот вы улучшили цифры, а ценности это точно больше принесло или вы работаете на уровне команды и её производственные показатели главное, даже если бизнес приносит абсурдные идеи?
next_data Автор
26.03.2024 06:54Спасибо большое за ваш комментарий и вопросы. Действительно, может сложится впечатление, что некоторые статьи похожи друг на друга. В рамках Канбан-метода есть 6 основных групп практик, которые можно использовать для улучшения текущего процесса поставки ценности для клиента и/или для решения отдельных проблем. Предположу, что подход к реализации практик может быть похож, но может меняться контекст команд/организаций, последовательность действий при применении и масштаб эффекта.
В Канбан-методе применяется эволюционных подход. Практики направлены не только на получение определенных выгод, но и на повышение зрелости команд (Модель КММ). Обычно, в самом начале пути, команды находятся на "рассеянном" уровне зрелости, когда каждый сам за себя. Группа отдельных экспертов в своей области. Далее команда эволюционирует на "командоцентричный" уровень, когда приходит понимание, что нет "моих задач", а есть задачи команды. Все работают над тем, чтобы завершить задачи совместными усилиями с максимально возможной скоростью. Здесь появляются общие метрики потока: Какие задачи мы делаем? Как быстро? Сколько в штуках и какого типа задач мы делаем за промежуток времени?
Сам подход не направлен на измерение отдельных людей и их производительности. Он направлен не на людей, а на процесс. Мы оцениваем возможности "сервиса", ищем узкие места в процессе, повышаем предсказуемость и равномерность поставки ценности.
Конкретно для вас, как части команды, появится понимание как быстро и много делает вся команда, куда нужно приложить командные усилия, чтобы стало лучше.
Из опыта: как только метрики в виде скорости или количества задач появляются в KPI - команды интуитивно начинают их читерить.В моей практике был опыт построения рабочего процесса с буферными этапами в виде "Анализ" и "Анализ готов", "Разработка" и "Разработка завершена" и т.д. Команде интересно было показывать, на каком этапе скапливается работа и есть ли простои, особенно на этапах взаимодействия с другими командами и заказчиками. В последующем, мы использовали статистику "простоев" между этапами, чтобы аргументировано разрабатывать правила для приемки задач и общения с приемщиками, для разработки правил перехода задач из одного этапа в другой (DoD и DoR). Кроме того, можно получить дополнительную статистику по реальному времени выполнения задачи (touch time) и сравнить с общим временем выполнения задачи в вашем сервисе (lead time), а на выходе получить метрику эффективности потока (Flow efficiency).
Про "нафиг всё это надо" мы объясняли через ценность, что мы можем получить на выходе, если начнем собирать эти цифры. Конкретный пример: У команды зависали задачи на приемке и было непонятно то ли команда долго копается, то ли заказчики долго реагируют. Когда собрали фактуру в виде метрик по буфферному этапу, то смогли договориться о новых правилах с заказчиками за сколько они должны принимать задачу, когда мы их уведомляем и т.д.Чтобы бизнес не приносил "абсурдные идеи" мы стали применять по всей организации скоринговые модели, которые позволяют оценить реальную ценность от задачи. Стратегия организации даёт понимание основных метрик, на которые мы должны повлиять. Эти метрики мы заложили в параметры скоринга задач. После этого, все задачи выстроились в прозрачный список, где сверху - самое актуальное и ценное, а снизу - менее важное и недостаточно ценное для компании.
Т.е. тут двухсторонние отношения по повышению прозрачности: заказчики показывают, что действительно важно, а исполнители - сколько они обычно делают и в какие сроки.
sshmakov
Ваша пропускная способность и скорость поставки выросли от правильной декомпозиции задач и от того, что в эту выборку попали "легкие" задачи, а остальное лишь рюшечки.
Мне вот интересно, а вы лично, как agile-коуч, участвовали в декомпозиции?
next_data Автор
Спасибо за вопрос. Улучшение метрик связано не только с декомпозицией задач. Если обратить внимание на первый график, то видно, что половина ранее существующих задач была адекватного размера и не нуждалась в дополнительном редуцировании. Вторая же половина представляла из себя смесь задач непредсказуемого размера, различные иерархические сущности для хранения более мелких подзадач, забытые задачи без должного фокуса внимания на них. Именно на вторую группу и был направлен комплекс мер, включая декомпозицию.
Как Agile-коучи мы не только принимаем непосредственное участие в декомпозиции задач, но и централизованно определяем правила иерархии проектов в командах, а также мониторим корректность применения этих правил.
В нашей практике мы стараемся принимать решения и делать выводы исходя из накопленной информации и собранной фактуры. Мы работаем с потоком задач и его состав далеко не всегда однороден. Могут встречаться "легкие задачи", а могут быть и "тяжеловесные". Основная задача команды взять в работу самое ценное для организации независимо от размера.
sshmakov
Вот это "централизованно определяем правила" как раз понятно и мне не интересно. Но я не видел еще коуча, непосредственно участвующего в декомпозиции. А ваше использование "мы" вместо "я" оставляет место для сомнений.