Мы используем файлы cookie. Продолжив работу с сайтом, вы соглашаетесь с Политикой обработки персональных данных.
OK

Визуализация работы. Часть 2. Делаем рабочий процесс видимым

Перевод статьи Fernando Cuenca, размещённой на squirrelnorth.com.
Оригинал можно прочитать здесь.
Что представляет собой ваш процесс?
Когда команды сталкиваются с этим вопросом, то часто ответом является описание ролей исполнителей, и то, как работа передаётся от одного человека к другому:
Процесс, состоящий из ролей
Естественно, появляется дизайн доски, который следует этим этапам. Однако быстро кто-то замечает, что это описание хоть и выглядит разумным, но очень часто кажется, что работа движется по странной схеме: двигается туда-сюда, а временами даже пропускаются столбцы. Что ещё более тревожно, в конце концов кто-то вспомнит те «особые случаи», когда вдруг работа требует совершенно другого процесса.
Доска с ролевыми шагами
Возможно, нам нужен другой взгляд на этот вопрос.

Совместный поиск знаний, вместо передачи
Проблемы, возникающие при попытке смоделировать передачу данных, могут быть решены с помощью другого подхода и понимания того, что разработку ПО можно рассматривать как упражнение в поиске знаний. Алексей Жеглов много писал об этом процессе; вот ещё один способ подумать об этом:
Представьте, что вы разговариваете с группой друзей, когда поднимаетесь по этой лестнице с целью полюбоваться видом с вершины. Разговор прыгает с темы на тему в случайном порядке. Возможно, вы говорите о том, по какой лестнице идти дальше, или комментируете вид. С каждым шагом вы лучше видите окружающий ландшафт, но вы продолжаете идти, ваша цель — добраться до вершины, поэтому вы не идёте обратно.

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

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

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

В части 1 я указывал, что микс работы в команде, скорее всего, будет неоднородным.

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

Теперь, когда колонки на месте, мы можем наблюдать за движением тикетов по всем направлениям.
Допустим, вы решили запустить какой-то элемент, и первый шаг — это сделать над ним что-то вроде «груминга».
Команда смотрит на это и решает, что элемент нужно разделить на более мелкие части.
Затем происходит нечто интересное: отдельные части начинают двигаться по доске в своем собственном темпе:
Однако часто бывает так, что всем им нужно в какой-то момент «накопиться» в какой-то точке, прежде чем они смогут продолжить.
Здесь вы можете понять, что у вас есть ряд важных моментов в рабочем процессе: точка, в которой работа разделяется и генерирует более мелкие элементы, далее точка повторной сборки и раздел «коммутация пакетов» между ними, где более мелкие элементы перемещаются в своём собственном темпе, следуя, возможно, даже разным маршрутам, как в сети коммутации пакетов связи.
Вы обнаружили, что имеете дело с иерархией рабочих элементов. Некоторые люди используют для этого термин «эпики», но я думаю, что важно выйти за рамки использования эпиков в качестве механизма «группировки» и признать, что это самостоятельный рабочий элемент (возможно, тот, который распознается клиентом), со своим собственным рабочим процессом.
Где находятся все составные части конечного продукта? Какова доля завершённой работы? Какие результаты достигаются совместно/независимо? Что ждёт чего?
Разные уровни абстракции соответствуют разным рабочим процессам, и это можно визуализировать с помощью отдельных досок. Сделав это, вы, скорее всего, обнаружите, что на более высоком уровне абстракции, рабочий процесс выходит далеко за рамки отдельной команды. И вы начнёте видеть более крупные сквозные сервисы, возможно, с участием нескольких команд, открывающие возможности для моделирования внешних зависимостей и общих сервисов. Связывая эти доски, у вас появляется больше шансов действительно начать управлять потоком от начала до конца, а также управлять зависимостями и решать проблемы координации.
Иерархические Доски
Как взаимосвязаны различные сервисы?

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

Это может свидетельствовать о том, что группа мелких элементов, по сути, стала новым типом работы, и что вы нашли «точку трансформации» в рабочем процессе.

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

Обычно, вы можете представить каждую колонку на вашей доске из двух подколонок: «Выполнение» (что означает «мы активно работаем над элементом») и «Готово» (что означает «мы выполнили достаточно и готовы перейти дальше»).
Столбцы "В работе/ "Сделано"
Разъяснение этих двух этапов может быть полезным, как способ показать, где работа ждёт и «накапливается».

В некоторых других случаях рабочий процесс может состоять из этапов, представляющих очереди. Разъяснение этого также может помочь понять, где работа застревает и перестаёт течь.
Явные очереди процессов
Насколько мы близки к завершению? Где прекращается поток работы? Где застрял?
Переосмысление колонок Сделать/В Процессе/Сделаноё

Итак, как насчёт типичного дизайна доски с тремя колонками «Сделать/В процессе / Сделано»?
Типичная доска с 3 столбцами
Это доска, которая скрывает больше, чем визуализирует. Колонка «В процессе» создаёт, возможно, ложное впечатление о движении работы и скрывает все сложности и состояния ожидания. Тем не менее, этот дизайн может быть неплох в самом начале, или быть «переходным» состоянием.

Простой способ начать разговор для более детализированного понимания рабочего процесса — попросить людей перемещать и размещать тикеты горизонтально в соответствии с приблизительным представлением о «завершении», а затем начать задавать вопросы, чтобы уточнить, каковы различные этапы и состояния ожидания.
Что мне нужно, чтобы моя команда увидела прямо сейчас?
Эту тему мы разбираем на тренинге:
Четырехдневный онлайн-курс
Kanban Systems Improvement (KMP 2)
Этот сертификационный тренинг предназначен для тех руководителей, которые уже используют Канбан метод и хотят масштабировать его, ищут точки роста и стремятся к эволюции в компании.
Шестидневный онлайн-курс
Extended Kanban Systems Improvement
Расширенный оnline-курс, покрывающий все цели тренинга Kanban Systems Improvement (он же KMP2) от Kanban University, с соответствующей сертификацией, учебной степенью и дающий намного больше знаний по теории и практическому применению Канбан Метода.