Определение стартовой и финишной контрольных точек
Необходимо определиться со стартовой и финишной точками визуализации процесса, а также с точками взаимодействия с вышестоящими и нижестоящими соседями по цепочке создания ценности. Важно ответственно отнестись к этой начальной стадии внедрения Канбана, поскольку неверный выбор может привести вас к провалу. Успешные команды обычно начинают с перехода на визуализацию при помощи карточек и ограничения числа незавершенных задач в пределах своей сферы контроля и переговоров по поводу новых способов взаимодействия с непосредственными партнерами по цепочке создания ценности. Например, если вы контролируете отдел проектирования или разработки и обладаете контролем (влиянием) над анализом, дизайном, тестированием и написанием кода, то составьте схему этой цепочки создания ценности и начните переговоры по поводу нового стиля взаимодействия с вышестоящими деловыми партнерами, от которых зависят требования, расстановка приоритетов и управление портфелем, а также нижестоящими, занимающимися системными операциями и поддержкой продукта. Очертив тем самым границы, вы предлагаете перейти на ограничение числа незавершенных задач только своей команде. Другие не обязаны менять методы работы, ограничивать число незавершенных задач и внедрять вытягивающую систему. Однако вы просите их по-иному взаимодействовать с вами, чтобы это было совместимо с вытягивающей системой, которую вы внедряете у себя.
Выбрав стартовую точку для рабочего процесса или цепочки создания ценности, определите, какие типы работы относятся к этой точке, а какие существуют в рабочем процессе и должны подвергнуться ограничениям. Например, исправление ошибок, скорее всего, относится к типам работ, существующим в рабочем процессе. Возможно, вы выявите и иные типы деятельности, связанные с разработкой: рефакторинг, поддержку систем, обновление инфраструктуры и другие переделки. Для входящей работы это такие типы, как пользовательские истории, прецеденты, функциональные требования или функции. В некоторых случаях входящие типы работы могут быть иерархическими – например, эпики[6] (собрания пользовательских историй).
Вот основные типы работы в командах, использующих Канбан (это неполный список):
• требование;
• функция;
• пользовательская история;
• пользовательский сценарий;
• запрос изменений;
• дефект продукта;
• поддержка;
• рефакторинг из-за ошибки;
• предложение улучшения;
• блокирующая проблема.
Полезно именовать типы работы по источнику, например: регуляторное требование, запрос продаж на местах, требование стратегического планирования и т. д. Если по оглавлению задачи сразу понятен источник, это создает дополнительный контекст и позволяет системе развиваться в сторону обслуживания нескольких клиентов сразу.
Типы работы обычно определяются их источником, рабочим потоком или размером работы. Например, у производственных текстовых изменений (РТС) в примере с Microsoft из главы 4 рабочий поток иной, хотя источник тот же, что и у запроса изменений. Иметь отдельные канбан-системы для обоих типов бессмысленно: работу выполняет одна и та же команда и несложно визуализировать типы, используя различные цвета карточек или разные ряды («плавательные дорожки») на стене карточек. Порядок величины карточек обычно таков: маленькие (несколько дней), средние (от недели до двух) и большие (месяц и более). Каждый порядок должен соответствовать своему типу.
Стена карточек обычно создается скорее для иллюстрации видов действий, чем для отражения конкретных функций или описаний работы. Часто функция и действие существенно перекрываются: например, аналитики проводят анализы. Однако в программных проектах, выполняемых при помощи Канбана, в последние несколько лет принято моделировать работу, а не работников, функции или передачи функций.
Перед созданием стены карточек для визуализации рабочего потока иногда полезно схематично набросать или смоделировать ее. Рис. 4.4 демонстрирует очень формальную модель желаемого рабочего потока, представленную при помощи диаграммы состояний. В ней добавляются очереди на запросы изменений и производственные текстовые изменения, обрабатываемые командой технической поддержки XIT в Microsoft. Вполне вероятен и менее формальный подход. Рисунка с человечками вроде тех, что фигурировали в главе 4, или схемы-алгоритма либо ее аналога может оказаться достаточно.
Когда вы лучше поняли рабочий поток, схематично набросав или смоделировав его, начните работу над стеной карточек, разграфив ее на столбцы, которые соответствуют выполняемым действиям в порядке их реализации, как показано на рис. 6.1.
Рис. 6.1. Черновик рабочего потока на стене карточек (поток движется справа налево)
Рисовать столбцы лучше маркером. Однако в процессе использования линии все равно сотрутся. За первые несколько недель вы, скорее всего, захотите внести в рабочий поток ряд изменений, так что продолжайте пользоваться маркером. Но со временем понадобится что-то более стойкое, например очень узкие рулоны виниловой самоклеящейся пленки, которые продаются в магазинах канцтоваров и специально разработаны для магнитных досок (рис. 6.2). В Corbis мы обычно разлиновывали столбцы и строки на стене карточек, используя именно такую пленку. Сейчас это обычная практика, и команды применяют для разметки пленку различного вида и ширины.
Рис. 6.2. Специальная пленка для магнитной доски (rolls = рулоны)
Заметьте, что для этапов деятельности необходимо моделировать как незавершенную, так и оконченную работу; обычно для этого столбец просто делят пополам.
После этого добавьте входящую очередь и любые действия нижестоящих партнеров, которые вы хотите визуализировать, как показано на рис. 6.3.
Рис. 6.3. Рабочий поток с буферами и очередями
Наконец, добавьте буферы или очереди, которые считаете необходимыми. По этому поводу мнения расходятся, и тема действительно сложная. Все пункты дискуссии о том, куда ставить буферы и как их масштабировать, лежат за пределами этой книги, так что достаточно описать два наиболее популярных подхода.
• Первая концепция состоит в том, чтобы не пытаться предугадывать место возникновения узкого места или источника вариативности, которым потребуется буфер. Просто внедрите систему и ждите, пока бутылочное горлышко не проявится само, а затем внесите изменения, введя буфер. Вариант того же подхода предлагает изначально произвольно установить ограничения числа незавершенных задач, чтобы вариативность, расход времени и узкое место не оказывали существенного влияния на вытягивающую систему при ее первом внедрении. Подробнее это будет описано в главе 10, а также в главе 17 и главе 19.
• Другая концепция предполагает иной подход: считается, что вместо внедрения свободных ограничений числа незавершенных задач для упрощения введения системы каждая стадия работы должна подвергнуться буферизации, а у этапов деятельной работы рамки должны быть довольно узкими. Узкие места и вариативность проявят себя в том, насколько сильно наполнятся буферы. После этого можно внести небольшие изменения в сторону уменьшения размеров буфера, а со временем ненужные буферы исключить.
На момент написания этой книги нет достаточного объема данных, чтобы решить, какой подход лучше.
Рис. 6.4. Стена карточек, иллюстрирующая использование ромбовидных карточек в верхней части очереди и буферных столбцов (публикуется с разрешения Liquidnet Holdings)
Некоторые команды договорились показывать буферные и очередные столбцы при помощи карточки, повернутой на 45 градусов. Это действительно сильный визуальный индикатор того, сколько рабочих элементов выполняется, а не находится в очереди в каждый заданный момент времени. Таким образом, команда и другие заинтересованные лица в буквальном смысле «видят» размер оптимальных (или не очень) издержек системы.
Анализ нагрузки необходимо проводить для каждого определенного типа работы. Если у вас накопились данные, проведите на их основе количественный анализ. Если их нет, то подойдет и анализ на основе личного опыта. Например, в примере с Microsoft XIT из главы 4 существовало два типа работы – запросы изменений и производственные текстовые изменения (PTC). Возможно, запросы изменений следовало тоже разбить на два типа – дефекты производства и собственно запросы изменений (для новой функциональности). Будь я сейчас наставником этой команды, я бы рекомендовал им различать четыре типа работ: запросы изменений, производственные дефекты, производственные текстовые изменения и ошибки (или неэкранированные дефекты).
