Всем привет! Я Евгений Степченко, деливери-менеджер в Тинькофф. Расскажу про подход к анализу и улучшению процессов, который называется STATIK, System Thinking Approach To Introducing Kanban — применение системного мышления при анализе и проектировании канбан-систем. Поговорим о том, как устроен этот подход и как он помогает запускать эволюционные изменения.
Статья будет полезна тем, кто вовлечен в управление процессами и изменениями на основе канбан-метода. Если вы плохо знакомы с методом, советую сначала изучить официальное руководство. В конце статьи я поделюсь другими полезными ссылками по теме.
Давайте договоримся о контексте
Алгоритм STATIK возник в результате осмысления и систематизации первых кейсов применения канбан-метода. Отсюда вытекают области применения:
Улучшение процессов с применением практик канбан-метода: ориентация на заказчика, визуализация, управление потоком и так далее.
Практически любая область интеллектуальной работы. Разработка программного обеспечения — самая популярная, но не единственная область, где STATIK может принести пользу.
Определение подхода как системного — тоже не пустые слова. В канбан-методе мы стараемся смотреть на рабочую систему в целом: не на отдельные элементы, а на то, как они взаимодействуют для достижения целей. И STATIK подчеркивает и поддерживает этот подход, помещая все элементы в общий контекст предназначения рабочей системы.
В каких случаях будет полезен STATIK
Примеры, когда можно использовать этот подход:
У нас совершенно новая команда, отдел или продукт, и хочется договориться о том, как организовать управление процессом работы.
Процесс уже работает, но хочется большего: прозрачности, скорости, результативности. Хочется его улучшить, но пока не понятно, как именно.
Что-то «болит». Например, руководитель или заказчик говорит, что получает отклик на свои запросы слишком медленно, а команда жалуется на перегруженность, часто меняющиеся приоритеты и усталость.
С помощью STATIK мы сначала изучаем и моделируем нашу рабочую систему, а затем запускаем эволюционные улучшения. Мы повышаем вероятность их успеха, а также получаем возможность состыковать нашу канбан-систему с нуждами бизнес-заказчиков и клиентов.
Мне нравится метафора, подсмотренная в англоязычном видео, которое так и называется: Service Archaeology using STATIK. Применяя метод, мы занимаемся «археологией»: смотрим, что происходило в прошлом, добываем исторические свидетельства и данные, изучаем и анализируем их. Я отобразил это на плакате и использую его, когда объясняю суть и шаги STATIK:
Здесь изображен алгоритм из семи шагов:
Отвечаем на вопрос «В чем наше предназначение?».
Понимаем источники неудовлетворенности.
Изучаем спрос и возможности.
Моделируем рабочие процессы.
Выявляем классы обслуживания.
Проектируем канбан-систему.
Договариваемся о запуске.
«Шагать» можно не по порядку. Практически всегда на определенном этапе мы понимаем, что нужно вернуться на какой-то из предыдущих шагов и что-то дополнить или поменять. А если мы используем STATIK повторно, спустя время после первого, можно выполнить какой-то один шаг — все зависит от того, чего мы хотим сейчас достичь.
Ниже мы подробно разберем каждый из этих шагов.
Примечание: картинки, которые я использую в статье, — скриншоты с реальных STATIK-сессий. На них могут быть плохо видны детали, но наша цель — показать, как это выглядит в целом.
Шаг 1. Отвечаем на вопрос «В чем наше предназначение?»
На первом шаге мы отвечаем на вопросы:
Что мы делаем? Какой сервис оказываем?
Для кого мы работаем? Кто наши заказчики? Важно понимать, кто приносит запросы и кому мы отдаем результат. Не всегда это одни и те же люди.
Зачем мы это делаем? Какие запросы закрывает наша работа, кому станет лучше от того результата, который мы производим?
Почему этот шаг важен? Канбан-метод работает в сервисной парадигме. Поэтому нам важно договориться, что такое наш сервис, а также где он начинается и где заканчивается. Мы не всегда работаем в формате End-to-End, обрабатываем запрос от возникновения идеи до передачи результата конечному потребителю. Поэтому прежде чем двигаться дальше, важно договориться о целях и границах нашей ответственности.
На этом этапе часто становится понятно, что далеко не все участники команды одинаково понимают цель работы. При низкой зрелости команда иногда говорит: «Ну, нам приносят задачу, а мы ее делаем, вот наше предназначение». Но предназначение на самом деле наверняка в другом, и об этом важно рассказать. Кто-то «кладет кирпичи», а кто-то «строит храм». Хорошо, если на встрече присутствуют заказчики, представители бизнеса — они могут помочь смотреть на контекст сервиса шире.
Но не стоит каждый раз ожидать здесь глубины: команды не всегда к этому готовы. Используйте этот шаг как разогрев к дальнейшим обсуждениям. Иногда стоит вернуться к нему в самом конце и посмотреть на ваше предназначение свежим взглядом.
В конце обсуждений на этом этапе я обычно прошу участников сформулировать что-то вроде лозунга: «Мы такие-то, оказываем такой-то сервис для таких-то людей, хотим достичь таких-то целей».
На иллюстрации — пример результата такого обсуждения.
Подробнее о концепции соответствия предназначению и одноименном фреймворке можно узнать из рассказа его автора, Алексея Жеглова.
Шаг 2. Понимаем источники неудовлетворенности
Неудовлетворенности — это причины, по которым мы хотим изменить что-то в нашем сервисе. В дальнейшем при дизайне системы мы можем анализировать, как наши изменения помогут уменьшить хотя бы часть из них.
Мы делим источники неудовлетворенности на две группы:
Внешние. Неудовлетворенность со стороны заказчиков или потребителей.
Внутренние. Неудовлетворенность со стороны тех, кто обеспечивает сервис.
Здесь можно применять разные подходы для сбора информации — начиная с анонимных опросов до, например, тех, которые применяем на обычных ретроспективах. Я часто использую следующие фокусирующие формулировки и вопросы.
Для внешних причин:
Как <заказчик, потребитель>
Я не доволен <оказанным сервисом>
Потому что я получил <список проблем>
Тогда как ожидал получить <список ожиданий>
Для внутренних причин:
Какие источники вариабельности и непредсказуемости вы можете указать?
Что вас раздражает, когда пытаетесь доставить результат вовремя и с нужным качеством?
Типичный пример внешнего недовольства: «Я ждал эту фичу „вчера“ и без багов, а получил только через полгода. А потом долго ждал, чтобы исправили все дефекты». Примеры внутреннего недовольства: «Постоянно меняются приоритеты», «Плохо сформулированные запросы», «Не получаем обратной связи вовремя». Думаю, у каждого из вас таких примеров множество.
Когда мы разбираем внутренние источники неудовлетворенности, важно честно признать, что «бесит» именно нас. Откуда берется непредсказуемость, что нам мешает, когда мы пытаемся сделать все вовремя и качественно?
Шаг 3. Изучаем спрос и возможности
Для качественного дизайна канбан-системы важно понимать, кто наши заказчики, что они у нас просят, какова частота появления этих запросов, есть ли какие-то паттерны и особенности появления таких запросов и какие ожидания заказчиков связаны с ними.
Для этого мы анализируем спрос. Во-первых, качественно: изучаем, с какими запросами к нам приходят, что именно просят сделать и почему. Разбираемся, адекватны ли эти запросы и почему они попадают к нам. Во-вторых, количественно: сколько запросов приходит за период, есть ли какие-то пики спроса, связанные с внешними событиями.
В правой части на картинке ниже — то, что участники накидывали в индивидуальном порядке. Каждый участник записывает и потом рассказывает, что именно просят от него, кто это делает и зачем. Я обычно специально прошу забыть, какие типы задач сейчас используются в системе учета (у нас это обычно Jira) и вспомнить, что именно просят сделать. Некоторые запросы могут приходить в обход учетной системы: в личном общении, чатах и других системах. Затем мы обсуждаем это, собираем в кластеры похожих и для каждого кластера придумываем название.
Затем переходим к количественному анализу. Если у нас есть рабочая система — хорошо, можно просто собрать данные по тому, сколько приходит запросов, сколько времени мы тратим на обработку, сколько запросов в работе сейчас, есть ли очередь. Если на прошлом этапе мы выявили новые типы запросов, может понадобиться вручную разметить запросы, чтобы мы смогли их посчитать. Или удовлетвориться примерными числами, спросив участников.
Если готовых данных нет, придется довольствоваться примерными числами. Редко, но бывает так, что учет в системе управления работой не вели или данные оттуда трудно добыть. Часто учет ведут неаккуратно, и тогда данным доверять нельзя. В таком случае можно вспомнить последний десяток запросов и разобрать, когда и откуда они пришли, когда мы сделали и отдали заказчику эту задачу и что происходило в промежутке. Это лучше, чем ничего.
Нередко на этом этапе мы выявляем дисбаланс между спросом и возможностями нашего сервиса. Обычно мы можем связать его с выявленными ранее неудовлетворенностями. Это важная информация для формирования новых договоренностей между сервисом и заказчиками.
Шаг 4. Моделируем рабочие процессы
Возможно, вместо слова «моделируем» здесь должно быть «исследуем». Для каждого выявленного типа рабочего элемента мы рисуем процесс: что мы делаем, чтобы довести его от запроса до поставки. Используем стикеры, доску, маркеры, схемы со стрелочками — что угодно. Часто для этого применяем подход Value Stream Mapping.
Здесь можно использовать комбинацию двух подходов.
Сверху вниз:
определяем точки принятия и отдачи обязательств и выясняем, что происходит между ними;
даем названия категорий этапам до, между и после;
разбираем категории до нужной детализации, чтобы всем было понятно, что конкретно там происходит;
выявляем очереди между этапами.
Снизу вверх:
изучаем текущие элементы работы;
размещаем их по степени готовности;
ищем отличия;
группируем, даем группам названия.
Важный момент: выявлять нужно не только активные статусы, но и буферы между ними. Например, часто отсутствует колонка между разработкой и тестированием. И мы не знаем, какой реальный статус у задачи: ее передали в тестирование, но тестировать еще не начинали, уже начали тестировать или просто закончили разработку и никуда не передавали?
Ниже — несколько примеров того, как это выглядит. Буферы и активные статусы мы отмечаем разными цветами. В колонке слева — рабочие элементы, которые мы выявили на предыдущем шаге. Справа — соответствующие рабочие процессы. На этом этапе рабочий процесс допустимо рисовать как есть — с циклами, разветвлениями, возвратами. Но уже тут полезно рассказать концепцию последовательного накопления ценности/знаний.
Единого для всех подхода здесь нет, мы экспериментируем. В одном из вариантов, в правом верхнем углу, можно заметить параллельные ветки — это отдельные команды. Там же появились розовые стикеры — это выявленные проблемы, присущие разным этапам. Голубые стикеры — это ответственные за этапы. В данном случае в качестве сервиса мы рассматривали не одну команду, а продуктовый процесс от появления идеи до сбора данных и анализа.
Шаг 5. Выявляем классы обслуживания
Чтобы выявить наши классы обслуживания, мы рассматриваем рабочие элементы, изучаем, каковы ожидания заказчиков, какие риски с ними связаны и какова стоимость задержки.
Здесь я обычно объясняю разницу между приоритетами и классами обслуживания. Приоритет определяет, в каком порядке запросы одного класса поступают в нашу систему, а классы обслуживания отображают, как по-разному мы относимся к различным запросам, когда работаем над ними внутри системы:
Например, одни запросы на исправление дефектов, не критичные для большинства клиентов, мы будем планировать в работу так же, как и новую функциональность. А другие, серьезно нарушающие работоспособность продукта и приносящие заметные финансовые потери, мы обработаем без очереди и бросим на них все силы.
Вот вопросы, которые помогут проанализировать классы обслуживания:
Разбираемся, как к нам поступает работа:
У всех элементов одинаковая срочность?
Если нет, как отличать более срочные?
Какой выбор есть у заказчиков?
Есть ли соглашения об уровне обслуживания?
Разбираемся, как мы ее различаем:
Можем ли мы легко и однозначно различать разные запросы на входе?
Требуют ли они разного отношения, планирования, обработки, управления рисками?
Влияют ли на нас разумные внешние ожидания по обслуживанию?
Проверяем, что получилось:
Как будет отличаться поведение сервиса для разных классов?
Как изменится поведение заказчика, если у него будет выбор?
Какие из существующих задач получают особенное отношение и почему?
На следующих шагах мы должны будем сформулировать правила, по которым мы присваиваем классы обслуживания запросами, и правила того, как по-разному мы с ними обращаемся в процессе обработки.
Шаг 6. Проектируем канбан-систему
Основа канбан-системы — визуализация всего процесса работы. Вот информация, которую мы хотим видеть в визуализации:
Канбан-доска.
Содержание карточек.
Правила.
Лимиты.
Каденции.
Итеративные процессы.
Параллельные процессы.
Блокировки.
Дефекты.
Внутренние и внешние зависимости.
Классы сервиса.
Как это будет выглядеть? На картинке ниже — не конечный результат, но пример того, как из разрозненных процессов с четвертого шага мы получаем линейную визуализацию и проверяем, как она работает для разных типов запросов:
На этом же этапе, следуя практике Канбана «делаем правила явными», нам нужно описать базовые правила работы системы. Такие как критерии готовности рабочего элемента к взятию в работу, критерии готовности к поставке, ограничения на количество одновременной работы и так далее.
Здесь же мы описываем, как мы будем проводить базовые каденции:
ретроспектива/обзор потока.
Шаг 7. Договариваемся о запуске и взлетаем
Итак, мы получили проект нашей канбан-системы. Настало время превратить его в план изменений и обеспечить их успех. Если не все будущие заказчики и исполнители принимали участие в STATIK, решите, как вы донесете до них результаты и получите одобрение вашего плана. Договоритесь, кто за какую его часть будет отвечать. Обсудите, как вы поймете, что изменения работают. Выясните, что нужно будет настроить в системах управления работой, чтобы реализовать визуализацию. Запланируйте нужные встречи, убедитесь, что все понимают их повестку и регламент.
Итак, мы провели STATIK
Что он нам дал?
Общий контекст. К сожалению, нередко заказчик почти не общается с командой. А если сервис требует слаженной работы нескольких команд, проблемы с коммуникацией встречаются еще чаще. Фреймворк помогает наладить взаимодействие и увидеть, что стыкуется, а что — нет.
Мотивация к изменениям. Теперь, когда мы нашли проблемы, есть общая мотивация начать что-то менять.
Усилитель общих ценностей. Теперь мы видим, чего именно хочет заказчик, какие цели есть у команды и, главное, зачем нам достигать эти цели.
План действий. Разложив все по полочкам, проще понять, что мы теперь собираемся делать.
Непрошенные советы
Серебряной пули не существует. STATIK не решит всех проблем. Пробуйте и ищите подходящие для вас инструменты.
Не торопитесь. Работа со STATIK — трудозатратная штука. В формате воркшопа с командой у нас на это уходит не меньше восьми часов. Но вам потом с результатом работать, так что лучше сделать все как следует.
Не стремитесь к совершенству c первого раза. Важно начать с небольших изменений и улучшать канбан-систему постепенно. Не можете выбрать наилучший вариант сейчас — попробуйте какой-то из них, поживите с ним, посмотрите, что работает, а что нет. Не пытайтесь поменять все и сразу. Начните с того, что есть сейчас, сделайте ранее скрытое явным, запланируйте одно-два изменения и развивайтесь эволюционно.
Планируя STATIK, проверьте, все ли важные участники вовлечены в процесс. Если кто-то отсутствует, может потеряться важная информация. Или вы столкнетесь с неожиданным сопротивлением на последнем этапе. Я предпочитаю проводить STATIK в формате воркшопа, но иногда сложно собрать всех вместе. Подумайте, как учесть мнение отсутствующих, как информировать их о принятых решениях и получить своевременную обратную связь.
Повторяйте STATIK: все семь шагов вместе или какие-то в отдельности. Отталкивайтесь от потребностей команды.
Экспериментируйте. Что сработало — берите на вооружение, а остальное отбрасывайте.
Что почитать и посмотреть
В заключение посоветую материалы, которые помогут лучше разобраться как в STATIK, так и в канбан-методе в целом:
-
STATIK — Systems Thinking Approach to Implementing Kanban. (англ.) David J. Anderson. Очень короткая статья.
Канбан — улучшение системы управления. Книга Майка Барроуза. Здесь можно найти наиболее полное описание методики и ее нюансов, а также самого канбан-метода и его применения. Во многом мой практический опыт и доклад опираются на эту книгу.
The STATIK A3 — инструмент дизайна канбан-системы с нуля. Игорь Филипьев.
Как я провел STATIK. Максим Фролов.
Секреты S.T.A.T.I.K. Советы бывалого. Денис Бартоломе.
Что такое STATIK? Советы о том, как применить канбан-метод! Николай Смирнов.
Сайт Kanbanguide.ru
И маленький бонус: мой шаблон в Miro для проведения STATIK в онлайн-формате. Пользуйтесь, давайте обратную связь. Если у вас есть вопросы по проведению или вы хотите поделиться опытом — пишите комментарии.
Мой доклад на конференции Flowdays’22, по мотивам которого написана статья.