Майк Барроуз - Канбан Метод. Улучшение системы управления

В канбане цель визуализации и других форм прозрачности двояка – показать необходимость действия и помочь сделать правильный выбор. Это работает на двух уровнях:

● действие в форме работы, которую необходимо выполнить; правильный выбор рабочего элемента, которому нужно внимание;

● действие в форме изменений в системе; правильный выбор при обосновании изменения, определении его масштабов и внедрении.

Как вы будете реагировать, когда доска показывает, что не все идет как надо? Ниже перечислены несколько вариантов ответов, типичных для руководителя или наставника:

1. Не стоит волноваться, все обойдется, как обычно.

2. Я, как руководитель, приму меры и буду следить за ситуацией, пока все не уладится.

3. Я внесу изменения в систему.

4. Они понимают, что привело к такому развитию ситуации? Они хотят внести изменения в систему? Как мне им помочь?

5. Я уважаю их способности вносить необходимые изменения в такой ситуации.

Каждый из этих ответов может быть верным в конкретной ситуации, но некоторые кажутся более зрелыми по сравнению с остальными. Подталкивая к действию и поддерживая правильный выбор, канбан побуждает к более зрелой реакции (ответы 4 и 5). Любая организация, сознательно следующая этим установкам и использующая стиль лидерства, стимулирующий их применение, уверенно движется к совершенству.

Ответ 5 (и, в меньшей степени, ответ 4) ориентирован на еще один очень интересный аспект – на самоорганизацию .

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

Изменения системы при визуальном управлении осуществляются быстро и недорого. Сотрите на доске одну-две линии, проведите другую и передвиньте несколько карточек (или несколько раз кликните мышкой). С учетом того, что влияние изменений может быть огромно по сравнению с затраченными усилиями, такая работа с системой открывает большие возможности.

Здесь включается механизм самоусиления:

● канбан-система организует работу;

● люди организуются вокруг работы;

● взглянув свежим взглядом на канбан-систему, люди понимают, что они могут работать по-другому и лучше, и они меняют систему.

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

Это еще одна сторона прозрачности – наряду со стратегией превращения невидимого в видимое мы стремимся сделать неявное явным, но если (и только если) мы считаем, что это поможет принимать лучшие решения. И снова нам нужен рычаг – несколько тщательно подобранных слов, отражающих суть намерения, а не толстый документ, который охватывает все. Я видел правило, состоящее всего из одного слова «Демо!» на доске над соответствующим столбцом – этого вполне хватало, чтобы подкрепить рабочую договоренность.

Многие правила описывают качества, которыми должны обладать рабочие элементы, входящие или покидающие столбец, например:

● Рабочие элементы в колонке «Готово» не должны задерживаться более пяти дней . В Будапеште мы называли это «правилом пяти дней», которое позже превратилось в «правило двух дней».

● Рабочие элементы не могут перемещаться в столбец «Тест» до тех пор, пока они не пройдут ревью и не будут продемонстрированы всей команде .

Наклейки на доске или рядом с ней типа «<5 дней на разработку», «Разбор программы» или «Демо!» превосходно напоминают о том, чего ждет команда в ближайшем будущем.

Правила могут иметь и более общий характер:

● Стабильность продукта имеет больший приоритет, чем устранение ошибок при тестировании; при этом и первое, и второе имеют более высокий приоритет перед новой разработкой.