Канбан Метод. T memarketologmanager
 Скачать 4.05 Mb.
|
|
Выполняем ли мы достаточно нематериальной работы? Какое пространство мы предоставляем сотрудникам для поисков более эффективных способов выполнения работы? Какая доля производственных возможностей выделяется для стандартной работы? Можно ли полагаться на то, что наши системы всегда будут ставить в начало очереди нужные рабочие задачи? Вам стало неуютно от таких вопросов? Что ж, наверное, в этом и состоит одна из их целей. Может, сотрудники у вас чересчур заорганизованы, слишком жестко разбиты на проекты и категории? Если ваша компания не умеет самоорганизовываться там и тогда, когда больше всего необходимо, она платит за это немалую цену. Когда-то я говорил, что способность канбана справляться с разнообразием — одно из его «уникальных преимуществ». Можно утверждать, что STATIK еще эффективнее побуждает организации к разнообразию. Жаль, что о нем пока еще не так широко известно! Глава 22 Разработайте канбан-системы Теперь у вас под рукой все детали, и пора перейти к самому приятному — разработке доски, установлению ограничений объема незавершенной работы и прочему. Сфера охвата, детализация рабочих задач, состояния рабочих задач Эти три параметра лучше задать совместно. Если вы сделаете сферу охвата своей первой доски слишком широкой, детализацию рабочих задач слишком мелкой, а состояние рабочих задач слишком короткоживущим, доска вполне может оказаться чересчур загроможденной, а значит, бесполезной с практической точки зрения. Мало поможет и доска, сфера охвата которой слишком узка и на которой отражаются лишь крупные задачи, чье состояние меняется очень медленно. Ваш выбор должен соответствовать главной задаче данной доски, а также той аудитории, на которую доска рассчитана. Доска, приспособленная для того, чтобы помогать в управлении загрузкой отдельных разработчиков, вряд ли подойдет для кабинета IT-директора — там к месту доска, работающая на уровне проектов. Кроме того, не забудем и такой прозаический аспект, как физические ограничения размера и месторасположения доски (в каком-то смысле такие ограничения действуют и в отношении электронных систем). В идеале нужно, чтобы каждый член целевой аудитории мог в любой момент, взглянув на доску, видеть, что он имеет прямое отношение по меньшей мере к нескольким рабочим задачам, сама же доска в целом должна отражать значимое продвижение от одной летучки к другой. Если кажется, что эти цели несовместимы, возможно, вам нужно или несколько досок, или многоуровневая доска. Последовательные состояния На рис. 22.1 я взял пример из главы 20 и перевел список в формат простенькой доски. Тут все очень очевидно: рабочие задачи поступают в столбец «Получено» и движутся слева направо, пока не достигнут графы «Сделано». Позже, в любое удобное время, соответствующие листки можно убрать с доски и отправить в архив. У этих состояний есть организация высокого уровня («Портфель заказов», «Создание», «Внедрение»), но это не должно оказывать существенного влияния на то, как действует система. Параллельные состояния Не всегда возможно расположить состояния в строгой последовательности слева направо. Особенно когда изменения некоторых состояний происходят параллельно основному процессу получения знаний. Например: Работа может вестись в «оптимистическом» режиме: допускается, чтобы какие-то задачи получали одобрение уже после того, как работа над ними началась. Работа может застопориться на любой стадии по техническим причинам, из-за качества или соображений стратегии и тактики бизнеса. Может понадобиться что-то переделать. Наиболее удобные методики визуализации параллельных состояний часто связаны с использованием карточек: Регистрируйте утверждение тех или иных стадий работы с помощью карточек, возможно, используя в качестве напоминания чекбоксы, куда можно проставлять галочки: Ставьте метки на карточках, чтобы показать необходимость дополнительных действий, и потом отмечайте, когда эти действия выполнены: На рис. 22.2 показано, как наглядно обозначаются блокировщики с помощью размещенной поверх еще одной карточки яркого цвета (обычно выбирают ярко-розовый). Вместо того, чтобы визуализировать эти изменения состояний на доске, можно работать с ними вне доски, скажем, при помощи таблиц, где столбцы определяют готовность и выполнение. При этом следует убедиться, что все сотрудники понимают, как это работает. Дефекты Прием с «блокирующими стикерами» очень часто используется, чтобы наглядно указать на наличие дефектов. Честно говоря, у меня на сей счет очень четкие личные предпочтения: Мне очень не нравится, когда рабочие задачи продвигаются по доске вперед, хотя мы знаем, что есть дефекты. Это приводит к простому накоплению проблем, которыми все равно придется заниматься! Мне также неуютно, когда я вижу, как задачи, требующие переделки, отодвигают назад вместо блокировки на том же месте. Зачастую это приводит к неверному отражению подлинного состояния работы. Иногда это очень опасно. Впрочем, я готов смириться с исключениями: Дефекты, имеющие больше отношения к уже существующему продукту, чем к рабочей задаче, вполне могут считаться новыми рабочими задачами, позволяющими текущей работе продолжаться без помех. Иногда с чисто экономической точки зрения имеет смысл позволить рабочим задачам двигаться дальше, даже если известно, что с ними связаны проблемы. Но будьте осторожны: если делать это слишком часто, быстро начнет падать общее качество продукта или сервиса. Если очевидно, что рабочую задачу вообще не надо было продвигать вперед, вполне может оказаться, что разумнее всего сдвинуть ее назад. Но такие события должны быть исключениями из правил, и их надо всегда расследовать. Что пошло не так? Почему наш производственный процесс допустил такое? Оставили ли мы после себя «обломки», которые надо убрать? Чего мы не понимали? Могут оказаться полезными и гибридные решения. Например, если дефект обнаружен в продукте, который уже выпущен, но пока находится на стадии одобрения клиентом или в пределах гарантийного периода, его карточку (пока еще видимую на доске) можно зафиксировать на одном месте, пометить и создать новую рабочую задачу по переделке. Это четко покажет два важных факта: 1) у нас в производстве дефектный продукт; 2) процесс устранения дефекта продвигается в системе. Зависимости Сюда входят два момента: зависимости между рабочими задачами и рабочие задачи, которые требуют внимания других служб. Тут применяются две основные методики. 1. Представьте зависимую рабочую задачу как заблокированную (см. рис. 22.3). Когда (так часто бывает) ситуация предсказуема, а не является исключением из устоявшегося порядка, используйте соответствующие цветовые обозначения, например, чтобы один цвет соответствовал одной сторонней службе. Если рабочий элемент зависит от другой задачи, установите название последней (и ее номер, если он есть). 2. Передвиньте рабочую задачу в зону временной задержки, названную по наименованию службы, от которой она зависит («Инфраструктура» и т.п.). Первая методика обычно больше подходит для зависимостей между рабочими задачами. Для зависимостей от сторонних служб годятся обе методики. Вторая делает доску более сложно организованной и не всегда может быть легко применена, зато она очень наглядно показывает, сколько рабочих задач находится в данном состоянии, а иногда даже позволяет отследить (в какой- то степени) поток работы на низовом уровне. Другие параметры Чем больше число рабочих задач, которые надо визуализировать, тем полезнее организовывать их по дополнительным параметрам, таким как: тип рабочей задачи и/или класс обслуживания; источник; какая-то менее постоянная категория — бизнес- инициатива, проект, эпопея, спринт и т.п.; «владелец» рабочей задачи. Есть два основных варианта визуализации параметров: 1. На уровне карточек — использование комбинации цвета, надписей, графических обозначений. Например: желтые карточки для «стандартных» рабочих задач (для которых фактор времени важен, но не критически); оранжевые карточки для рабочих задач, привязанных к дате (которая указывается здесь же); красные карточки для срочных рабочих задач (если срок совсем мал, можно и вовсе обойтись без карточки); запись, указывающая спринт, к которому относится данный рабочий элемент (я предпочитаю указывать номер спринта на маленьком цветном ярлычке, используя свой цвет для каждого спринта, чтобы ситуацию было видно и на расстоянии); помечайте карточки инициалами их владельцев или помещайте на карточку съемный аватар. 2. Добавление линий для разграничения горизонтальных плавательных дорожек, идущих по всей доске или по какой-то ее части. Например, можно выделить: постоянную дорожку для срочных рабочих задач; отдельные дорожки для команд или конкретных сотрудников (обычно я не одобряю такого подхода, поскольку это мешает самоорганизации); дорожки, организующие рабочие задачи по их принадлежности к проекту, бизнес-инициативе и т.п. (см. рис. 22.4). Названия этих дорожек — временные. Многоуровневые доски и вариант с расширением/сжатием На рис. 22.5 представлена доска, которая организована посложнее. Разберем ее по частям. Начальная часть — левая сторона (рис. 22.6). Она занята крупными эпопеями. Далее, ближе к середине (рис. 22.7), три эпопеи проходят расширение, разбиваясь на более мелкие рабочие задачи (сюжеты или пользовательские истории). Такая организация доски предполагает, что сюжеты можно выпускать и подтверждать независимо друг от друга. Когда это не так, мы проводим сжатие, вновь представляя их как эпопеи, которые можно поставлять целиком. Пример доски, позволяющей проводить такое расширение/сжатие, показан на рис. 22.8. Ограничение объема незавершенной работы Настоящая канбан-система включает в себя механизм ограничения объема незавершенной работы. Для этого, опять же, существует несколько способов: Количественные ограничения WIP, каждое из которых касается объема WIP в отдельном столбце, размера столбца или длины горизонтальной дорожки. Физические ограничения, скажем, число существующих дорожек. Ограниченное количество фишек (скажем, личных аватаров), находящихся в обращении. Эти фишки прикрепляются к карточкам. Контроль, обеспечиваемый таким механизмом, может быть неполным, если карточкам позволяют продвигаться без фишек. В таком случае фишки ограничивают не всю WIP, а только ту ее часть, которая считается «активной». Различные меры контроля, скажем, максимальный объем WIP в расчете на одного сотрудника или класс обслуживания. Внешний механизм, который вводит новую работу в систему лишь в тех случаях, когда для этого имеются необходимые возможности. В скрам этого достигают, ограничивая объем работы в рамках каждого спринта (который, в свою очередь, жестко ограничен во времени). Весьма полезно использовать комбинации этих методик. Например, можно сочетать: горизонтальные (скажем, для классов обслуживания) и вертикальные (скажем, для состояний) ограничения; физические ограничения (скажем, для эпопей) и вертикальные ограничения (скажем, для сюжетов, находящихся в активной разработке); спринты и ограничения на уровне столбцов, чтобы сдерживать развитие чрезмерной многозадачности и побудить сдвинуться от состояний частичного завершения (скажем, «код написан») к выпуску продукта. Когда несколько ограничительных механизмов должным образом откалиброваны, никакие отдельные ограничения не кажутся слишком сдерживающими сами по себе, однако в целом они снижают WIP до уровней, которые прежде могли казаться немыслимыми. Каждое ограничение обращено на определенный симптом или поведение. Ограничение вступает в действие, когда это необходимо, и помогает сглаживать производственный поток в целом. Чтобы увидеть, как это может работать в нашем примере с расширением/сжатием, обратимся к рис. 22.9. Здесь у нас поставлен численный предел в 5 эпопей для столбца «Одобрено», физическое ограничение в 3 эпопеи для всего раздела «Создание» и численный максимум в 4 эпопеи для всего раздела «Поставка». Получается максимум 3 + 4 = 7 эпопей, которые находятся в активной разработке, и максимум 5 + 3 + 4 = 12 эпопей, которые ваша команда согласилась выполнять, но еще не доделала. Предел в 6 сюжетов в колонке «Разработка» охватывает три активные эпопеи, однако не предписывает конкретное распределение трудовых усилий по сюжетам. Каждое из этих ограничений имеет свой эффект: Ограничение на количество эпопей в столбце «Одобрено» требует приоритизации. Если прибывающие новые рабочие задачи имеют достаточно высокую приоритетность, то задачи, которые уже ожидают в этом столбце, возможно, придется отодвинуть (в подобных обстоятельствах это не так уж плохо). Ограничение на количество эпопей в разделе «Создание» приводит к потоку типа «один вышел — один вошел» даже на этом сравнительно высоком уровне организационной структуры. Ограничение в столбце «Разработка» должно поощрять быструю разработку сюжетов и соответствующих эпопей. Ограничения на количество эпопей в разделе «Поставка» должны предотвращать их пребывание в системе дольше необходимого. Однако может возникнуть необходимость увеличить эти показатели и/или ввести ограничение для столбца «Выпуск», если высока вероятность, что весь процесс затормозится из-за проблем с наличием клиентов. Общий анализ Диапазон вариантов организации доски широк, и имеет смысл провести общий анализ этой структуры, прежде чем счесть ее своей «первоначальной» (даже не думайте считать ее «окончательной»!). Начните со следующих базовых технических проверок: Как выглядит доска, заполненная рабочими задачами? Организует ли она их с достаточной эффективностью? Хватает ли на ней места? Насколько продвигаются рабочие задачи в интервале от одной летучки до другой? Недостаточно сильно? Слишком сильно? Понятна ли доска для тех, кому предстоит ею пользоваться? Может быть, она слишком сложна? Может быть, слишком упрощена? Спросите у пользователей. А лучше вовлеките их в процесс конструирования доски. Возникнут ли в результате применения такой доски какие- то неразумные требования? Может быть, нужно внести изменения в производственный процесс, структуру организации, функциональные роли, в отношении которых пока нет единого мнения? (Я не говорю, что на данном этапе никогда не надо заявлять о радикальных изменениях, но обычно я такого не рекомендую). Затем углубитесь в тонкости. Хорошо организованная доска соответствует более широким и масштабным потребностям: Она обеспечивает прозрачность того, что происходит и каким образом. Она помогает принимать более удачные решения, поощряет самоорганизацию и сотрудничество. Может ли ваш коллектив наглядно представлять это на такой доске? Она повышает баланс спроса и предложения, различных категорий спроса и т.п. Способна ли на это ваша доска, хотя бы в какой-то степени? Она поощряет мысли и действия, направленные на повышение клиентоориентированности и на улучшение потока. Вновь обратитесь к главам 4 и 5 и попытайтесь использовать свою доску как инструмент мышления. И наконец (это чрезвычайно важно): Каким образом такая организация доски начинает работать с конкретными факторами неудовлетворенности и разочарования, которые вы сумели выявить в самом начале процесса (см. главу 18)? Не ждите, что сможете сразу же расправиться с этими факторами (пожалуй, лучше даже не пытаться сделать это с наскока). Но поможет ли доска вывести их симптомы или причины ближе к поверхности? Эти соображения, особенно последнее, действуют не только при создании доски впервые, но и в процессе ее эволюции. Лучше иметь уродливую доску, к изменению которой вы подходите целенаправленно, чем очень красивую доску, где улучшения существуют лишь ради самих улучшений. Научитесь видеть за доской ту систему, которую она представляет. Изменяйте доску так, чтобы в результате менялась система. Глава 23 Внедрение На мой взгляд, внедрение канбан-систем можно рассматривать как трехстадийный процесс: 1. Планирование мероприятия: подготовка, касающаяся подбора участников, мест проведения занятий, инструментов, подсобных материалов и т.п. 2. Формирование повестки: применение STATIK с открыто объявленной целью выработки комплекса приоритетов, задач и действий, ставшего результатом консенсуса. 3. Проведение изменения через систему: поддержание темпов, обеспечение видимого и значимого прогресса. Такую структуру можно применять независимо от того, какова ваша цель — выстроить отдельную канбан-систему, впервые внедрить в организации Канбан Метод или влить свежую энергию в новые циклы изменений. Ее можно даже использовать задним числом: она помогает конструктивно осмысливать уже внесенные изменения, которые нужно прочнее увязать с организацией, где они появились. Я надеюсь показать, что между воздействием канбан-системы на производство и сохранением приверженности гуманистической этике нет никаких противоречий. Ближе к концу главы мы обсудим ту роль, которую ценности могут играть в усилении мотивации, касающейся внедрения изменений. Планирование мероприятия Затевая процесс совершенствования производства, имеет смысл как следует подготовиться к этому заранее. Взяв на себя роль фасилитатора и планируя использовать STATIK, вы должны предварительно задать себе такие вопросы: 1. О понимании источников неудовлетворенности (глава 18). Есть ли у вас хотя бы приблизительное представление о содержании мероприятия? Есть ли у него спонсоры, нужны ли они? Кто должен принимать участие в обсуждении? Кто будет представлять людей, работающих внутри предполагаемой границы системы? Кто будет представлять клиентов системы? Должны ли быть представлены другие слои организации? Какие инструменты вы будете использовать для получения и организации достаточно широкого диапазона откликов (см. главу 17)? 2. Об анализе спроса и возможностей (глава 19). Готовы ли вы помочь определить «что», «кому» и |