Разработайте канбан-системы

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

Сфера охвата, детализация рабочих задач, состояния рабочих задач

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

Ваш выбор должен соответствовать главной задаче данной доски, а также той аудитории, на которую доска рассчитана. Доска, приспособленная для того, чтобы помогать в управлении загрузкой отдельных разработчиков, вряд ли подойдет для кабинета IT-директора — там к месту доска, работающая на уровне проектов. Кроме того, не забудем и такой прозаический аспект, как физические ограничения размера и месторасположения доски (в каком-то смысле такие ограничения действуют и в отношении электронных систем).

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

Последовательные состояния

На рис. 22.1 я взял пример из главы 20 и перевел список в формат простенькой доски. Тут все очень очевидно: рабочие задачи поступают в столбец «Получено» и движутся слева направо, пока не достигнут графы «Сделано». Позже, в любое удобное время, соответствующие листки можно убрать с доски и отправить в архив.

У этих состояний есть организация высокого уровня («Портфель заказов», «Создание», «Внедрение»), но это не должно оказывать существенного влияния на то, как действует система.

Параллельные состояния

Не всегда возможно расположить состояния в строгой последовательности слева направо. Особенно когда изменения некоторых состояний происходят параллельно основному процессу получения знаний. Например:

• Работа может вестись в «оптимистическом» режиме: допускается, чтобы какие-то задачи получали одобрение уже после того, как работа над ними началась.
• Работа может застопориться на любой стадии по техническим причинам, из-за качества или соображений стратегии и тактики бизнеса. Может понадобиться что-то переделать.

Наиболее удобные методики визуализации параллельных состояний часто связаны с использованием карточек:

• Регистрируйте утверждение тех или иных стадий работы с помощью карточек, возможно, используя в качестве напоминания чекбоксы, куда можно проставлять галочки:

• Ставьте метки на карточках, чтобы показать необходимость дополнительных действий, и потом отмечайте, когда эти действия выполнены:

На рис. 22.2 показано, как наглядно обозначаются блокировщики с помощью размещенной поверх еще одной карточки яркого цвета (обычно выбирают ярко-розовый).

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

Дефекты

Прием с «блокирующими стикерами» очень часто используется, чтобы наглядно указать на наличие дефектов. Честно говоря, у меня на сей счет очень четкие личные предпочтения:

• Мне очень не нравится, когда рабочие задачи продвигаются по доске вперед, хотя мы знаем, что есть дефекты. Это приводит к простому накоплению проблем, которыми все равно придется заниматься!
• Мне также неуютно, когда я вижу, как задачи, требующие переделки, отодвигают назад вместо блокировки на том же месте. Зачастую это приводит к неверному отражению подлинного состояния работы. Иногда это очень опасно.

Впрочем, я готов смириться с исключениями:

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

Могут оказаться полезными и гибридные решения. Например, если дефект обнаружен в продукте, который уже выпущен, но пока находится на стадии одобрения клиентом или в пределах гарантийного периода, его карточку (пока еще видимую на доске) можно зафиксировать на одном месте, пометить и создать новую рабочую задачу по переделке. Это четко покажет два важных факта: 1) у нас в производстве дефектный продукт; 2) процесс устранения дефекта продвигается в системе.

Зависимости

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

1. Представьте зависимую рабочую задачу как заблокированную (см. рис. 22.3). Когда (так часто бывает) ситуация предсказуема, а не является исключением из устоявшегося порядка, используйте соответствующие цветовые обозначения, например, чтобы один цвет соответствовал одной сторонней службе. Если рабочий элемент зависит от другой задачи, установите название последней (и ее номер, если он есть).
2. Передвиньте рабочую задачу в зону временной задержки, названную по наименованию службы, от которой она зависит («Инфраструктура» и т.п.).

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

Другие параметры

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

• тип рабочей задачи и/или класс обслуживания;
• источник;
• какая-то менее постоянная категория — бизнес-инициатива, проект, эпопея, спринт и т.п.;
• «владелец» рабочей задачи.

Есть два основных варианта визуализации параметров:

1. На уровне карточек — использование комбинации цвета, надписей, графических обозначений. Например:
   • желтые карточки для «стандартных» рабочих задач (для которых фактор времени важен, но не критически);
   • оранжевые карточки для рабочих задач, привязанных к дате (которая указывается здесь же);
   • красные карточки для срочных рабочих задач (если срок совсем мал, можно и вовсе обойтись без карточки);
   • запись, указывающая спринт, к которому относится данный рабочий элемент (я предпочитаю указывать номер спринта на маленьком цветном ярлычке, используя свой цвет для каждого спринта, чтобы ситуацию было видно и на расстоянии);
   • помечайте карточки инициалами их владельцев или помещайте на карточку съемный аватар.
2. Добавление линий для разграничения горизонтальных плавательных дорожек, идущих по всей доске или по какой-то ее части. Например, можно выделить:
   • постоянную дорожку для срочных рабочих задач;
   • отдельные дорожки для команд или конкретных сотрудников (обычно я не одобряю такого подхода, поскольку это мешает самоорганизации);
   • дорожки, организующие рабочие задачи по их принадлежности к проекту, бизнес-инициативе и т.п. (см. рис. 22.4). Названия этих дорожек — временные.

Многоуровневые доски и вариант с расширением/сжатием

На рис. 22.5 представлена доска, которая организована посложнее.

Разберем ее по частям. Начальная часть — левая сторона (рис. 22.6). Она занята крупными эпопеями.

Далее, ближе к середине (рис. 22.7), три эпопеи проходят расширение, разбиваясь на более мелкие рабочие задачи (сюжеты или пользовательские истории).

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

Отправить