Привет всем, кто интересуется Канбан‑методом, и кто хочет познакомиться поближе с одним из его инструментов — S.T.A.T.I.K.

Задумка этой статьи появилась тогда, когда в очередной раз ко мне кто‑то подошел с вопросом: «Мы собираемся делать СТАТИК, где про это можно почитать?»

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

System Thinking Approach To Introducing Kanban

Именно так расшифровывается эта аббревиатура — системный подход применения Канбана, и уже из названия можно понять, что инструмент надо применять к какой‑то «системе». Что ж это за система такая? Кто‑то скажет «сервис», кто‑то «поток работ», а я скажу — это «система управления».

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

У системы управления есть несколько обязательных вещей:

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

И когда все эти три компоненты у нас в наличии — мы можем управлять поведением того, для чего построили нашу систему управления.

Возвращаясь к теме статьи, скажу, что СТАТИК (для простоты буду его дальше писать кириллицей) это алгоритм действий, который помогает спроектировать наиболее подходящую систему управления для того, что канбан‑практики называют «сервис».

И если у вас есть работа, процесс, деятельность или что‑то другое, что подходит под определение ниже, то можно использовать СТАТИК, чтобы спроектировать для этого удобную систему управления.

Я очень люблю инструменты‑алгоритмы — просто следуя последовательности шагов можно прийти к прогнозируемому результату с минимально необходимым качеством.

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

СТАТИК — инструмент универсальный, который можно применять для дизайна совершенно разных уровней управления — для управления работой команды; для управления процессом поставки ценности; для управления клиентскими путями; для управления портфелем проектов; и так далее.

Отдельно стоит упомянуть гибрид «S.T.A.T.I.K — Kick Off», который практикуют некоторые agile‑коучи.
При проведении крупных agile‑трансформаций есть этап, когда для выполнения работ формируются кросс‑функциональные команды, и для запуска команды используется командообразующее мероприятие (Kick Off), которое предваряет совместную работу людей, объединенных общими целями и задачами.
Иногда в команду «упаковывают» какую‑либо централизованную функцию или сервис, и для простоты подхода, ей тоже проводят формальный запуск. В этом случае дизайн системы управления является тем фундаментом, на котором потом строится вся командная работа.

Но вернемся к самому инструменту. СТАТИК позволяет:

Собрать необходимую и достаточную информацию для дизайна системы управления сервисом.
Спроектировать дизайн основных элементов управления (или пересмотреть существующие).

Работает и как разовый инструмент, и как периодический.

Перейдем к алгоритму.

Шаг 1. Определение предназначение сервиса

Важнее всего — первый шаг. Так поется во многих песнях, так начинается много рассказов, так я начну описание этапов СТАТИКа.

Я много слышал интерпретаций, зачем нужен этот шаг, и все они начинались со слова «надо»:

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

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

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

Шаг 2. Определите источники неудовлетворенности текущим сервисом поставки

Когда человек начинается знакомиться с Канбан‑методом, одна из самых ярких фраз, которая ему запоминается это «Начни с того, что есть сейчас.» Она означает, что то, что мы имеем на текущий момент, это не чей‑то злой умысел, а результат уже свершившейся эволюции. Уважайте то, что было создано до вас!

Однако, то, как эта фраза звучит по‑русски, влияет на дизайн системы управления. Начинающим практикам хочется нарисовать текущую ситуацию, а только потом думать, что с этим делать. В таком подходе есть нюанс — собранные на втором шаге СТАТИКа неудовлетворенности остаются невостребованными. Так что, если хочется просто «опрозрачить» ситуацию, уделять время этому шагу необязательно.

Я же трактую фразу, которая в оригинале звучит как «Start with what you do now» несколько по‑другому, внося в нее не статичную коннотацию, но динамику: «Оттолкнитесь от того, что есть сейчас». То есть, всё, что у вас есть, нужно обязательно учесть, а раз у вас есть источники неудовлетворенности, то почему бы в дизайн не заложить решение парочки?

Эту мысль я всегда держу в голове, проводя СТАТИК — используйте информацию предыдущих шагов при выполнении последующих.

Как это работает: например, если у вас есть «неудовлетворенность», что исполнители и менеджер не понимают друг друга (менеджер говорит про цели, а исполнители думают персональными задачами), то предложите им на текущем уровне зрелости гибридную визуализацию, совмещающую оба типа взглядов, а не рисуйте сразу сервисно‑ориентированную доску.

Гибридная визуализация. Часто используется scrum-командами.

Собирая источники неудовлетворенности, разделите их на две группы:

Внутренние — проблемы внутри системы;
Внешние — недовольство заказчиков и внешних стейкхолдеров.

Это позволит удобнее использовать эту информацию в будущих шагах. А какие именно инструменты Канбан‑метода подобрать для снижения неудовлетворенностей — зависит уже от того, кто проводит СТАТИК, от его знаний и опыта.

Поэтому всем, а особенно новичкам, рекомендую обратить внимание на Канбан Модель Зрелости (Kanban Maturity Model) где для разных типовых проблем и контекстов можно выбрать практики, которые, как правило, в этих контекстах хорошо работают и не встречают сильного сопротивления при внедрении.

Шаг 3. Проанализируйте источники и природу запросов

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

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

Туманно, конечно, объясняю, но, когда на этом шаге задаешь вопрос: «С какими запросами приходят заказчики?», участники обычно достаточно ясно представляют себе, с какими заказами им предстоит работать. А если нет, то это как раз время и место для определения.

На этом же шаге можно проанализировать текущую статистику, существующую или прогнозную, а также ожидания клиентов по срокам и качеству исполнения.

Некоторые практики, после того как запрос/заказ входит в систему поставки, начинают называть его «рабочим элементом» системы. Иногда удобно использовать этот термин.

Шаг 4. Проанализируйте текущие возможности поставки

Многие канбан‑практики объединяют этот шаг с предыдущим, сразу анализируя всю статистику и по запросам, и по поставкам. На этом этапе нужно обратить внимание на соотношение входящих запросов и количества поставок: если в систему входит больше, чем выходит, то это повод поисследовать причины и, возможно, заложить в систему ограничения одновременных задач в работе (WiP‑лимитов).

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

Шаг 5. Смоделируйте рабочий поток сервиса поставки

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

Следующий шаг — смоделировать рабочий поток для каждого из запросов из шага 3. Я обычно начинаю эту работу с вопроса: «Что нужно сделать, чтобы выполнить этот заказ?», и записываю ответы. Так появляются шаги, которые ложатся в основу системы контроля.

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

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

Шаг 6. Идентифицируйте и определите классы обслуживания

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

Для пояснения термина я привожу примеры «бизнес‑класс в самолете» или «VIP‑билеты на аттракционы в парке развлечений». Какие ключевые вещи в этих примерах:

Каждый класс стоит по‑разному. За привилегии платят больше.
Для каждого класса в системе (самолете, аттракционе) резервируется определенное количество мест.
В каждый класс своя очередь.

Самый важный для понимания момент, это — НЕ (!) «сначала обслуживаем всех повышенного класса, а потом более низкого», А «сначала обслуживаем запросы повышенного класса в рамках квоты, отведенной в системе для этого класса, потом более низкий класс».

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

Места бизнес-класса и эконом-класса в самолете

Возвращаясь к нашей задаче, на этом шаге нужно определить — есть ли во входящем потоке заказы, за которые люди готовы «платить больше»?

Это совсем не простая задача — договориться о классах обслуживания и сознательно сделать дизайн с разделением потоков и квот для каждого класса, поэтому, новичкам я советую, для начала, просто задать вопрос: «Бывают ли у нас заказы, которые объективно должны обгонять основной поток?».

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

Обычный — основной, на который тратится большая емкости системы.
Повышенный — с минимальной емкостью для заказов‑исключений.

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

Шаг 7. Спроектируйте канбан-систему

Этот шаг алгоритма сформулирован наиболее обще, потому что здесь уже требуется опыт и знания того, кто проектирует систему. Инструментарий Канбан‑метода богат, и пора вспоминать всё, что знаешь и умеешь. Что надо не забыть:

Дизайн доски (или системы досок) — как мы представляем себе поток работ на основе той информации, что собрали;
Элементы визуализации — как улучшить читаемость информации на доске;
Правила пополнения с учетом классов обслуживания, наличия буфера, квот для заказчиков;
Дизайн сигналов — например, на пополнение системы/этапа, на появление проблемы;
Дизайн каденций — когда, какую информацию получать, какие решения принимать;
Требования к системе и систему сбора статистики — как мы поймем, что система работает штатно? Как нам понять, что нужно что‑то менять?

Как использовать инструменты Канбан‑метода для конструирования системы управления можно узнать на тренинге базового уровня, который называется «Kanban System Design» (или аналогично по‑русски).

Шаг 8. Найдите инструмент для реализации дизайна системы и примените ее

Последний шаг S.T.A.T.I.K. это технический шаг, который рекомендует вам не оставлять ваш дизайн на бумаге, а оформить его в том виде, в котором с ним будут работать. Наиболее популярные формы, из моей практики, это:

На стене (вымирающий вид в постковидном мире);
В JIRA (там, где этот инструмент является стандартом; типично для корпораций);
В Trello (для простых систем и маленьких групп людей);
В Kaiten (облачный)‑ для тех, кому разрешено работать в облаке и кто ценит гибкость и удобство;
В Kaiten (локальный сервер) — как замену той же JIRA.

Есть еще варианты, но они менее распространены в русскоязычном сообществе.

STATIK A3 – шаблон для новичков

Хочу еще рассказать об одной популярной реализации алгоритма СТАТИК в виде канвы (canvas). Канадский канбан‑консультант питерского происхождения Алексей Жеглов спроектировал его на заре широкого применения Канбан‑метода, и этот формат заслуженно снискал любовь молодых практиков.

Как и все фреймворки типа «канва», это простой и наглядный инструмент для проведения воркшопа, где нужно последовательно пройти по шагам инструмента.

Сам я уже давно перестал пользоваться форматом STATIK A3, но в свое время этот шаблон помог мне не запутаться и набрать критическую массу опыта по дизайну канбан‑систем. Так что, пользуйтесь, вещь удобная.

Вместо заключения

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

Но если вдруг остались вопросы, обещаю в будущем вернуться к этой теме и раскрыть её еще больше.

Секреты S.T.A.T.I.K. Советы бывалого