Всем привет! Меня зовут Алексей Цыбульник, я помогаю внедрять Kanban в командах ПСБ. В банке я работаю с 2019 года, а вообще в IT больше 15 лет. Почти все это время всеми силами я продвигаю Kanban — учу методологии, веду подкаст, делаю конференцию о нем. Если вы интересуетесь этим миром, то можете меня знать :-)

В этой статье расскажу про системный подход, с которым будет проще самостоятельно внедрять Kanban в команде. Имя ему STATIK — System Thinking Approach To Introducing Kanban. Разберемся, чем он полезен и как ложится на принципы канбана. 

Что такое Kanban?

В этой статье мы говорим о методе Дэвида Андерсона, появившемся около 10 лет назад. Он взял принципы системы Kanban — той, что возникла в 1950-е годы на заводе Toyota, где рабочие прикрепляли карточки к пустой таре с деталями (это служило сигналом для пополнения запасов). Переложил идею на нематериальную сферу, в частности, на IT, и теперь мы управляем задачами на цифровых досках.

У каждого сервиса есть заказчик — это клиент, которого команда не видит, сотрудник соседнего подразделения или представитель бизнеса. Его потребности четко определены и он принимает выполненную работу. Зачастую в бэклоге лежат вещи, которые ему уже пообещали (и он ждет их в ближайшее время). Kanban позволяет визуализировать умственный труд, а это дает возможность менеджерам настраивать баланс между запросами заказчика и возможностями команды сервиса.

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

S.T.A.T.I.K.

Знакомимся со STATIK (System Thinking Approach to Introducing Kanban). Это структурированный метод внедрения Канбана «снизу вверх», который помогает командам самостоятельно спроектировать свою систему управления работой.

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

Вот эти шаги:

• Ищем ответ на вопрос: «Чего от нас ждут и хотят заказчики?»

• Ищем источники неудовлетворенности 

• Анализируем запросы

• Моделируем систему накопления знаний

• Выявляем классы обслуживания

• Проектируем визуализацию

• Начинаем использовать (PROFIT!)

Далее по каждому из этих шагов пройдусь подробнее.

Ищем ответ на вопрос: «Чего от нас хочет и ждет заказчик?»

Какому назначению должен соответствовать сервис? Чего заказчик хочет от команды и от продукта? Вопрос выглядит совсем уж простым, однако это лишь на первый взгляд. На деле же, когда мы проходим этот шаг на практике, для многих становится откровением, что от команды заказчику нужно именно это. 

Мы приходим в команду и спрашиваем напрямую:

• Кто наш потребитель?

• Что мы ему предоставляем?

• Зачем наша команда или сервис?

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

Или можно перефразировать:

• Кто ваш заказчик или клиент?

• Цели ваших заказчиков или клиентов?

• Задачи или назначение вашей команды или сервиса?

Когда команда на воркшопе совместными усилиями находит ответы на эти вопросы, появляется понимание, как мы соответствуем назначению для нашего заказчика.

Ищем источники неудовлетворенности

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

На этом шаге мы задаем такие вопросы. 

Внутренние:

• Чем мы, как команда, недовольны?

• Что мешает работе быть сделанной?

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

Внешние:

• Причины, по которым заказчик недоволен?

• Какие ожидания заказчика не выполняются?

• Где точки конфликта с заказчиками?

К примеру, очень частая и знакомая многим ситуация — заказчик постоянно меняет требования. Часто команды жалуются на это в первую очередь. Если у вас так, то в идеале стоит на этом шаге собрать заказчиков и команду на одной встрече. Это поможет выявить реальные причины постоянных изменений, понять скрытые проблемы с обеих сторон и создать общую картину для дальнейших улучшений. Такой диалог становится точкой отсчета для внедрения Kanban и улучшения сервисов.

Анализируем запросы

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

Фактически, мы работаем запросами и у них могут быть разные типы. Чтобы понять типы запросов, можно задавать вопросы:

• Источники запроса. Откуда к нам приходит? Кто ожидает итоговый результат?

• Обработка запросов. Куда результат идет после нас?

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

• Паттерн появления. С чем связано появление запроса?

• Природа запроса. Цикличность / сезонность / планируемо / пакетно / невозможно отказать.

• Частота появления. Как часто приходят заявки?

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

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

Если в команде есть таск-трекер, можно вытащить гистограмму распределения. 

На диаграмме можно вывести 85% процентиль. Так уже можно будет отвечать на вопросы вроде «Точно ли мы можем поставить решение за 14 дней?»

Моделируем систему накопления знаний

Для примера, вот кусочек нашей рабочей таблички на внутреннем портале:

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

Поэтому мы создаем чек-лист для каждого перехода между этапами. Например, что должно произойти, чтобы запрос переместился из активной стадии в буфер: нужно ли согласовать ТЗ, уточнить детали у заказчика или дождаться результатов смежной задачи? Иногда в процессе такого анализа команда находит неочевидные операции, которые раньше игнорировались — например, «Оказывается, мы должны проводить ревью архитектуры, но избегаем этого, что создает проблемы на поздних этапах».

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

Выявляем классы обслуживания

В канбане мы делим их на архетипы по типу стоимости задержки. Их четыре.

• «Пожар». Ускоренный архетип. Тут у нас что-то горит. Цена задержки начинает расти сразу с момента появления задачи или даже еще раньше. Задача такая срочная, что приходится откладывать выполнение других и немедленно переключаться на нее. Новые задачи брать в работу не можем. 

• «Новый год». Фиксированная дата. Как подготовка к празднику: до 31 декабря цена опоздания равна нулю, но сразу после полуночи она резко взлетает. Задачу нельзя сдать раньше (праздник же не перенесешь), но и опаздывать нельзя. Главное — успеть к дедлайну.

• «Таящийся долг». Стандартный архетип — это большинство наших задач. Их цена задержки начинает медленно, но верно ползти вверх с момента появления. Чем раньше мы их сделаем, тем дешевле это обойдется компании. Выполняем их в порядке согласованной приоритизации, не доводя до состояния «пожара».

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

Главные цели достигаются за счет задач с фиксированной датой и стандартных. 

Проектируем визуализацию

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

Вот пример визуализации. От красного разделителя направо — время производства (lead time). Налево — время ожидания заказчика (customer lead time). 

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

Переходим к использованию

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

Когда вам нужен STATIK?

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

Есть так называемая формула эволюционных изменений:

STRESSOR > REFLECTION MECHANISM > LEADERSHIP

То есть для изменений нужны источник стресса, механизм рефлексии и лидеры. 

Алгоритм STATIK позволит разобрать все составляющие этой формулы:

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

• Идем дальше. Включается механизм рефлексии: какие запросы к нам приходят, какие есть возможности. Моделируем систему накопления знаний, вспоминаем, какие должны быть правила для того, чтобы перемещаться из активного этапа в буфер и так далее (чтобы работа двигалась с тем качеством и результатом, которых мы ожидаем). Выясняем классы обслуживания.

• И ключевой момент: если в конце у нас нет лидерства или кто-то боится изменений, никто не спроектирует визуализацию и не внедрит все в практику.

Про лидерство. Я рекомендую почитать Дэвида Марке «Разверните ваш корабль». Менеджмент от капитана лучшей подводной лодки США. Главные тезисы книги: «отдавайте контроль», «создавайте лидеров». И это же основополагающие принципы канбана: поощряйте проявление лидерства на всех уровнях — от рядовых сотрудников до топ-менеджмента. Так формируется самоорганизация и много других крутых вещей. 

С удовольствием отвечу на вопросы про Kanban и STATIK в комментариях. Напишите, о чем еще хотели бы узнать по этому направлению? И подписывайтесь на блог ПСБ: буду время от времени возвращаться со статьями про Kanban и то, что вокруг него.