Как я провел STATIK. Часть II. Семь шагов к Канбан-системе

В прошлом посте мы начали рассматривать контекст рассказа. Ищите там подробности о предпосылках, команде и кратко о STATIK.

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

Первый шаг. Fit for Purpose

Способность сервиса адекватно реагировать на запросы клиентов — главный критерий соответствия команд предназначению. Если у вас просят написать веб-сервис на Perl, а вы выдаете нативное mac-приложение на Swift — вероятно вы не Fit for Purpose.

Термин невероятно глубокий и скрывает в себе не только понятие “соответствия”, но и фреймворк развития бизнеса. Рекомендую изучить подробнее:

• https://www.youtube.com/watch?v=vRtcr9wzfZg
• https://www.amazon.com/Fit-Purpose-Businesses-Satisfy-Customers/dp/0985305118

На стартовом этапе команда обсуждает и стремится понять свое предназначение. Если понять удалось — рассмотрите, соответствуете ли вы этому предназначению.

У нас молодая команда и такая тема была не по силам. Мы использовали первый этап как “разогрев” и “ice-breaker”. Обсуждая Fit for Purpose мы поняли, что участники команды смотрят на предназначение по разному. Это дало стимул продолжить общение. “Раньше мы думали, что мыслим одинаково — давайте продолжим копать и искать новые открытия”.

Формат работы на первом этапе:

• Подготовленная поверхность доски
• Стикеры
• Обсуждение
• Кластеризация схожих идей

Заполненная доска первого шага

Второй шаг. Источники неудовлетворенности.

Неудовлетворенность работой сервиса — топливо для обсуждения и изменений. Простое правило: если все довольны — перемен не будет.

STATIK предлагает рассматривать неудовлетворенность с двух сторон:

• Внешняя неудовлетворенность — что в работе сервиса не устраивает заказчиков? Как другие сервисы отзываются о вашей работе? Доверяют ли вам партнеры, находящиеся перед вами в цепочке ценностей? А те, что работают с ценностью после вас?
• Внутренняя неудовлетворенность — что в работе сервиса не устраивает вас самих? Понимают ли участники команды природу сервиса? Понимают ли все свои цели? Нравится ли всем формат и режим работы?

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

Чтобы обсуждение не сводилось к “Что тебе не нравится?”, мы применили часть классической ретроспективной механики “Моторная лодка”. В этой ретроспективе команда рассматривается как корабль. Кораблю грозят рифы, мешают якоря, а помогает попутный ветер. Это, соответственно, метафоры рисков, проблем и позитивных факторов. Для нашей задачи мы использовали только метафору якорей — так было проще выгрузить больше скрытых источников недовольства.

• Подробнее о ретроспективе “Моторная лодка”

Формат работы на втором этапе:

• Подготовленная поверхность доски
• Изображение корабля и якорей
• Стикеры
• Обсуждение
• Кластеризация

Наш поиск источников неудовлетворенности

Третий и четвертый шаги. Анализ спроса и возможностей системы.

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

Наша команда была не готова в подробностях рассматривать оба направления — еще нет такого уровня зрелости. Поэтому мы совместили два шага в один и обсудили всё сразу.

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

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

После полного рассмотрения архива мы снова встретились и начали кластеризацию типов работ. Здесь было много дискуссий, какой тип работ объединять с другим, а какой сильно отличается. В итоге выявили 10 типов работы, которые стали входными данными для следующего этапа.

Формат работы на третьем и четвертом этапах:

• Архив таск-трекинг системы
• Работа в парах с синхронизациями
• Стикеры
• Обсуждение
• Кластеризация

Слева короткие наименования задач. Справа названия кластеров

Пятый шаг. Поток накопления знаний.

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

Тема накопления знаний — объемный пласт Канбана. Предлагаю заглянуть в него подробней в цикле постов Алексея Жеглова.

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

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

Расчерченная доска с типами работ справа

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

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

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

Формат работы на пятом этапе:

• Расчерченная поверхность доски
• Виды работ с предыдущего шага
• Стикеры
• Обсуждение
• Кластеризация
• Работа офлайн

Шестой шаг. Классы обслуживания.

Канбан-система по-разному относится к задачам. Это отражено в концепте классов обслуживания. Пример — люди, которые платят больше за авиабилет, садятся в самолет быстрее. Бизнес-класс в самолете — это особый класс обслуживания. Схожий формат работы наблюдается в большинстве Канбан-систем.

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

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

Подробнее о классах сервиса и стоимости задержки:

• https://www.youtube.com/watch?v=Vd_8XMAeL0w
• https://kanbanzone.com/kanban-resources/kanban-classes-of-service/
• https://vimeo.com/101506552

Формат работы на шестом этапе:

• Расчерченная доска
• Подготовленные стикеры
• Обсуждение

Седьмой шаг. Дизайн Канбан-системы.

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

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

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

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

На этом сегодняшняя часть подходит к концу. Буду рад вопросам в комментариях. В заключительной части расскажу про то, что было после STATIK и какие выводы я сделал.
Предыдущий пост < > Следующий пост