Когда с Канбаном познакомилось больше людей, они поняли, что эта система помогает решать проблемы управления изменениями, с которыми они столкнулись в своих организациях. Канбан придает гибкости команде, проекту или компании. Мы пришли к выводу, что Канбан разрешает создать на рынке собственный процесс, оптимизированный для конкретного контекста. Канбан дает разрешение людям думать самостоятельно. Он позволяет быть разными: отличаться от команды, расположившейся в соседнем кабинете, на другом этаже, в другом здании или в конкурирующей фирме. Он дает разрешение отклониться от учебника. Более того, Канбан дает инструменты, которые позволяют объяснить (и оправдать), почему разнообразие – это хорошо и выбрать его – значит поступить правильно.
Чтобы подчеркнуть этот выбор, я разработал дизайн футболки для Общества ограничения незавершенных задач. Я вдохновился постером Шепарда Фэйри для предвыборной кампании Обамы, на который поместил портрет Тайити Оно, создателя канбан-системы в Toyota. Слоган «Да, мы за канбан» призван подчеркнуть, что у вас есть возможность. Вам разрешается попробовать Канбан, модифицировать свои процессы, быть другими. Ваша ситуация уникальна, и вы можете разработать собственное решение для своего процесса, оптимизированное для вашей сферы деятельности и потока создания ценности, рисков, с которыми вы сталкиваетесь, навыков вашей команды и требований ваших клиентов.
Выводы
• Канбан-системы могут быть использованы в любой ситуации через ограничение наличия элементов работы внутри системы.
• Сады Императорского дворца в Токио используют канбан-систему, чтобы контролировать число посетителей в парке.
• Количество сигнальных карточек «канбан», находящихся в обращении, ограничивает объем незавершенных задач.
• Новая работа втягивается в процесс после возвращения в оборот сигнальной карточки, когда предыдущее задание выполнено.
• В IT-сфере мы, как правило, используем виртуальную канбан-систему, поскольку для ограничения количества незавершенных задач не передаются какие-либо физически существующие карточки.
• Доски со стикерами, часто встречающиеся в гибкой разработке ПО, не являются канбан-системами.
• Канбан-системы создают на рабочем месте положительную напряженность, которая вызывает обсуждение проблем.
• Канбан-метод (или Канбан с большой буквы) использует канбан-систему как катализатор изменений.
• Канбан требует формальных политик процессов.
• Канбан использует инструменты разных областей знаний для анализа проблем и поиска решений.
• Канбан предполагает пошаговое улучшение процессов благодаря постоянному выявлению проблем, влияющих на производительность.
• Современное определение Канбан-метода можно найти в сети на сайте Общества ограничения незавершенных задач (Limited WIP Society, http://limitedwipsociety.ning.com/).
• Канбан дает разрешение на отклонения в разработке ПО, поощряет поиск специфических решений в зависимости от контекста вместо догматического следования определению процесса жизненного цикла разработки ПО или шаблону.
Часть II
Преимущества канбана
Глава 3
Рецепт успеха
Последние десять лет я пытался ответить на вопрос, какие действия вам как менеджеру следует предпринять, если вы унаследовали команду, особенно работающую не в соответствии с agile-практиками, которая обладает широким набором способностей и, возможно, совершенно неэффективна. Обычно меня делали агентом организационных изменений. Таким образом, я должен был обеспечить переход к позитивным изменениям и быстрый прогресс, желательно в течение двух-трех месяцев.
Как у менеджера у меня никогда не было возможности в крупных организациях нанять собственную команду. Меня просили приспособить существующий коллектив, причем с минимальными кадровыми изменениями, для проведения революции в производительности организации. Я думаю, что такая ситуация встречается гораздо чаще, чем возможность набрать новую команду.
Постепенно я выработал подход к управлению такими изменениями. Он основан на опыте, в котором учтены все прошлые ошибки. Они связаны, как правило, с попытками использовать административный ресурс для навязывания рабочих процессов. Приказы руководства обычно не приводят ни к чему хорошему. Когда я просил команды изменить свое поведение и перейти на какой-нибудь agile-метод, например Feature Driven Development, я встречал сопротивление. Мои возражения, что бояться нечего, я проведу необходимое обучение и выступлю в роли наставника, почти не давали результата. В лучшем случае люди соглашались с большой неохотой – об истинной и глубокой институциализации перемен не могло быть и речи. Когда вы просите людей измениться, это порождает страх и снижает их самооценку, поскольку тем самым вы даете понять, что их навыки более не нужны.