Склад Toyota не будет затовариваться, как в первом случае, и компании не придется долго хранить заранее изготовленные детали. Все потому, что то, что сейчас производится на конвейере, является нормой для недавно проданного автомобиля.
Система канбан. Как устроено умное управление проектами на реальных примерах
Канбан — это система управления проектами. Он визуализирует ход реализации проекта от концепции до готового продукта. Это помогает контролировать и ограничивать количество задач. Это помогает равномерно распределить рабочую нагрузку между сотрудниками и позволяет команде делать больше меньшими усилиями.
Канбан можно использовать в любом проекте — он может помочь в управлении отделом продаж, планировании мероприятий или строительстве космического корабля. В этой статье рассказывается о том, как Kanban помогает управлять и реализовывать проекты (на примере команд Mindbox по разработке и проведению мероприятий). В ней также объясняются три ключевых принципа системы и то, как применять ее в любом проекте.
Все, что вам нужно для этой системы, — это доска Канбан с колонками, показывающими все задачи, и карточками, показывающими, где находится единица работы.
Содержание
Канбан помогает оптимизировать рабочие процессы. Принципы Канбан не диктуют, например, как разбивать задачу на части или как быстро ее выполнять, но принципы должны соблюдаться, чтобы инструмент работал.
Дмитрий Кожевников, старший технический менеджер компании Mindbox
Визуализация задач в виде карточек
В переводе с японского канбан означает «значок, карточка». На карточках указаны выполняемые задания. Они помогают команде отслеживать статус задач и, в случае задержек, сразу видеть, на каком этапе они находятся.
Карта может быть физической (в виде наклейки) или электронной. Обычно стикер содержит всего несколько деталей: название задания, срок выполнения и имя ответственного лица. Электронная карточка более подробная — она собирает всю информацию о задании и обсуждает ее с коллегами:
Распределение задач по колонкам
Карточки размещаются на специальной доске Канбан, которая разделена на три колонки:
— Задачи, которые необходимо выполнить,
— Задачи, над которыми команда работает в настоящее время,
Это базовое разделение, которое подходит для любой задачи. Но колонн может быть больше, и самое главное — учитывать все фазы разработки продукта. Для разработчиков программного обеспечения в таблице Kanban, например, помимо столбцов «Бэклог», «Разработка» и «Завершено», вероятно, есть столбцы «Анализ», «Черновик» и «Приемка».
Названия столбцов в таблице Канбан — это этапы, через которые проходит задача. Когда задание переходит на следующий этап, исполнитель перемещает карточку в следующий столбец.
Мнение
В таблице карточки с заданиями двигаются слева направо, от идеи к результату, который можно проверить в производстве.
Положение карты на доске показывает, сколько денег было вложено в каждую задачу. Чем ближе задача находится к правому краю, тем больше денег на нее было потрачено. Если задание еще не находится в колонке «Выполнено», оно не имеет значения.
По этой причине карты нельзя перемещать в противоположном направлении — если вы это сделаете, приборная панель перестанет отражать реальность.
Дмитрий Кожевников, старший технический менеджер компании Mindbox
Если карты начинают скапливаться в колонке, это признак того, что работа на данном этапе не настроена должным образом. В разработке, например, работа часто накапливается на этапе приемки, когда заказчик (часто владелец продукта) должен рассмотреть проект. В этом случае Канбан иллюстрирует проблему: узкое место, которое снижает скорость работы команды.
Решение этой проблемы заключается не в том, чтобы взять на себя больше работы, потому что количество задач, которые необходимо выполнить, не увеличится, а в том, чтобы найти способ расширить это узкое место.
Точка принятия обязательств обозначает момент, когда имеет смысл начать мониторинг конкретной задачи, собирать метрики по ней и принимать управленческие решения.
13 причин перейти на Kanban. И никаких суеверий
В процессах развития, как и в других сферах деятельности, не всегда можно сразу «почувствовать» правильный путь, и часто приходится переживать множество всплесков. Будущая жизнь продукта или услуги зависит от выбора правильной методологии разработки. Мы собрали 13 преимуществ Канбан для разработки программного обеспечения.
Что такое Kanban?
Давайте проанализируем следующий пример, рассмотрев две ситуации.
Во-первых, представьте себе конвейерный завод в советское время, который напрямую зависел от Госплана, в котором количество продукции, которую необходимо произвести, было четко определено. В результате склады были переполнены, так как ответственные за государственные планы часто неправильно оценивали спрос. Продукция не могла быть реализована вовремя.
Вторая ситуация сегодня — это автосалон Toyota. Покупатель выбирает модель и оплачивает ее. Однако в данный момент на складе Toyota нет цвета вашего автомобиля. Заказ отправляется в штаб-квартиру Toyota. Они сообщают вам, когда автомобиль будет доставлен. Только в это время начинается производство автомобиля. Только для тебя. Принцип очевиден: сначала продажа, потом производство. Другими словами, работает принцип «точно в срок» (JIT): Сначала цели и сроки, затем план и работа.
Склад Toyota не будет затовариваться, как в первом случае, и компании не придется долго хранить заранее изготовленные детали. Все потому, что то, что сейчас производится на конвейере, является нормой для недавно проданного автомобиля.
Одним из ключевых элементов принципа JIT является Канбан: доски и карточки Канбан — это своего рода светофорная система «точно в срок». Канбан позволяет компании реагировать на потребности клиентов, а не предугадывать их, как это было в первой описанной ситуации.
Аналогичный пример можно найти в области разработки программного обеспечения:
Вместо сегментов, задач разработки или ошибок. Перед испытателем ставятся различные задачи по проверке. Когда у QA больше нет задач для тестирования, он должен сообщить об этом разработчикам и запросить новые задачи. Если разработчики не в состоянии выполнить новые задачи, тестировщик просто становится безработным на определенный период времени.
Может произойти и обратное: У службы обеспечения качества слишком много задач и нет времени, чтобы проверить их все. В этом случае дата выпуска продукта также откладывается.
Сбалансировать Kanban в разработке программного обеспечения гораздо сложнее, чем в производстве. На это влияет специфика работы: когда машины производят однотипные детали, разработчики работают с кодом с помощью усилий собственного мозга, в котором около 100 миллиардов нейронов и один, но тяжелый человеческий фактор.
Для чего разработке ПО нужен Kanban?
Я открыл для себя преимущества Канбан в 2008 году, и с тех пор использую доски Канбан повсюду — от личного программирования и разработки до внедрения Канбан в гончарной мастерской.
Порог WIP может быть разным для определенных специалистов или отделов в зависимости от их ресурсов. Цель отсечения — сфокусировать внимание сотрудника на одной задаче, а не пытаться выполнять много задач одновременно.
Как выглядит канбан-доска: примеры
Каждая команда сама решает, как должна выглядеть доска Канбан, в зависимости от сложности проекта, разнообразия задач и количества задействованных сотрудников. В самом простом виде это может быть маркер или доска, на которой можно рисовать или наклеивать стикеры.
Простая доска Канбан, источник: pyrus.com.
Такие доски полезны для личного планирования или для небольших групп, работающих вместе в офисе.
Для удаленной работы и проектов с несколькими командами на разных уровнях цифровые доски Канбан гораздо практичнее. Они позволяют входить в систему и выполнять задания по статусу из любого места, создавать несколько досок и групп одновременно, оставлять неограниченное количество комментариев и многое другое. Подробнее об услугах для работы с досками Канбан читайте ниже.
Пример цифровой доски Канбан Источник: giphy.com
Кому подходит и не подходит канбан
Можно сказать, что доски Канбан не имеют ограничений в применении. Разработчики используют его чаще, но Kanban может помочь вам организовать работу над любым проектом, даже если это планирование свадьбы или подготовка к экзамену.
Однако Канбан не очень полезен для долгосрочных проектов, требующих четкой структуры и пошагового подхода. Такой подход гораздо эффективнее для текущих задач, приоритеты и статус которых постоянно меняются. Кроме того, подход Kanban может не подойти для больших команд, состоящих более чем из 10 человек. Контролировать задачи на одной доске будет сложно; лучше создать разные рабочие места и разделить участников проекта на небольшие группы.
Чтобы узнать, какой метод подходит именно вам, смотрите таблицу ниже, где мы собрали лучшие уроки по agile-разработке, Scrum и Kanban.
Необходимым условием Kanban являются регулярные встречи и анализ успехов и неудач команды. Они необходимы для обеспечения работы команды в правильном направлении и своевременной сдачи результатов.
Чем на самом деле является Канбан-доска?
Может показаться, что доска Kanban — это просто инструмент для контроля работы подчиненных. В действительности это не так, и назначение доски Kanban совершенно иное. Канбан-доска — это инструмент отражения, средство, позволяющее понять, как работает рабочий процесс и какие управленческие решения необходимо принять для его ускорения и оптимизации.
Чтобы объяснить, почему это так, давайте немного углубимся в историю. Идея визуализации рабочих процессов и управления их характеристиками зародилась в компании Toyota в 1950-х годах. Она пыталась победить в конкурентной борьбе за японский автомобильный рынок, где спрос был очень ограничен.
Руководители столкнулись с проблемой повышения эффективности рабочего процесса без увеличения имеющихся ресурсов. Они решили применить системный подход и создали карту потока создания стоимости, которая показывала путь деталей и сырья от одного производственного процесса к другому до момента поставки деталей заказчику. Она выглядела сложной и научной:
Что они искали в этой карте рабочего процесса? Потерянное время. Желтые треугольники на этой диаграмме представляют собой запасы деталей или сырья, которые накапливаются перед тем или иным этапом производства. Почему показана эта гора запасов? Потому что предыдущий этап работает быстрее, и следующий этап не успевает за потреблением сырья или компонентов.
Хорошо это или плохо? С одной стороны, это гарантирует отсутствие простоев в любой области. Здесь всегда есть чем заняться, и все места заняты на 100%. Разве это не правильно? В этом и заключается работа менеджера — следить за тем, чтобы все работали на 100 %. Верно?
Но менеджеры Toyota думали по-другому. И именно этот фактор привел их к успеху. Давайте рассмотрим подробнее.
Целостный взгляд и анализ эффективности
Менеджеров Toyota интересовала не загруженность отдельных сотрудников, а эффективность всего рабочего процесса. В общем, как быстро автомобиль сходит с конвейера в надлежащем качестве.
Оказалось, что стопроцентная загрузка каждого отдела может замедлить, а не ускорить или даже сделать нерентабельным производство готовой продукции. Это тот самый запас, который скапливается перед производственными помещениями. Если представить эти складские запасы как очереди, в которых компонент должен «стоять», прежде чем его можно будет обработать, то становится очевидным, что чем длиннее очередь из компонентов перед каждым этапом, тем больше времени требуется одному компоненту для перемещения по конвейеру.
Удивительно, но это факт.
Для того чтобы детали быстро «летели» по конвейеру, производственный поток должен быть сначала «сглажен», чтобы минимизировать задержки между этапами и уменьшить «очереди» на каждом этапе. При таком подходе требование, что каждый этап должен быть использован на 100 %, отходит на второй план.
А чтобы выровнять весь производственный поток, необходимо взглянуть на общую картину и применить системное мышление.
Именно так и поступили менеджеры Toyota. Используя карты потока создания стоимости, они проанализировали текущий рабочий процесс, нашли узкие места, перегрузки, простои и другие нарушения, и разработали решения для их устранения.
Таким образом, карта потока создания ценности — это инструмент для анализа и размышлений, а не для контроля. Мы должны помнить об этом факте, потому что идея доски канбан возникла на основе идеи картирования потока создания ценности.
Канбан в нематериальном производстве
Гораздо позже были предприняты попытки перенести идеи Toyota на нематериальные сферы производства и обслуживания. В отличие от завода Toyota, где компоненты и сырье можно потрогать и измерить, в нематериальном производстве или секторе услуг ничего этого нет.
Например, когда разработчик принимает заказ на разработку, он не получает ничего материального, ни сырья, ни комплектующих. Ему дается задание, иногда письменное, иногда устное, и он начинает реализовывать его в виде программного кода. Обратите внимание, что код и программа также несущественны.
Для того чтобы менеджер в нематериальном производстве начал улучшать рабочий процесс, ему также необходим инструмент, позволяющий взглянуть на весь процесс и улучшить его, используя системное мышление. Доски Канбан стали таким инструментом. Они позволяют анализировать рабочий процесс, обдумывать увиденное и принимать разумные управленческие решения.
Прежде чем двигаться дальше, давайте уточним значение слова «Канбан». В переводе с японского оно имеет два значения — «значок» и «информационная табличка». В производственной системе Toyota канбан представлял собой сигнальную карточку, отправляемую на вышестоящий этап для начала производства и доставки необходимых деталей. Эти карты использовались для минимизации запасов и ускорения производства.
В этом смысле доска Канбан также является своего рода «сигнальной системой», которая показывает менеджеру, на что следует обратить внимание, на каком этапе необходим анализ и размышление, чтобы улучшить весь рабочий процесс и оптимизировать рабочий процесс.
Также учитывается специфика работы на разных фазах (является ли она повторяющейся или нет, является ли она необязательной и т.д.), правила перехода рабочих заданий с одной фазы на другую и многое другое.
Преимущества и недостатки канбан
Kanban имеет такие достоинства:
- Гибкость в дизайне. Команда фокусируется только на незавершенной работе; приоритет задач устанавливает руководитель.
- Сильное вовлечение команды в процесс разработки. Благодаря постоянным встречам, прозрачным процессам и возможностям для самоорганизации сотрудники поддерживают связь и проявляют неподдельный интерес.
- Сокращение времени цикла. Если несколько человек обладают схожими навыками, продолжительность работы сокращается, но если задействован только один человек, возникает узкое место. Поэтому сотрудники должны делиться своими знаниями, чтобы оптимизировать время цикла. Затем вся команда может взять на себя прерванные задачи и восстановить плавный поток.
- Меньше узких мест. Пороговые значения RWP позволяют быстро выявить узкие места и узкие места, возникшие из-за недостатка внимания, людей или навыков.
- Видимость. Когда все исполнители имеют доступ к данным, узкие места легче выявить. Команды Канбан обычно используют два общих отчета в дополнение к самим диаграммам: диаграммы управления и кумулятивные блок-схемы.
На практике система отлично себя показывает в сферах неосновного производства:
- Группы поддержки программного обеспечения или службы технической поддержки.
- Канбан хорошо подходит для управления стартапами, которые не имеют четкого плана, но их развитие активно продвигается.
Канбан имеет и недостатки:
- система плохо работает с командами, состоящими более чем из 5 человек.
- Он не предназначен для долгосрочного планирования.
Отличия от Скрама
Scrum, как и agile Kanban, является гибкой методологией и также широко используется в ИТ. Различия между ними не очевидны на первый взгляд. В обоих подходах есть много общего, например, наличие текущего проекта.
Повторяющиеся спринты фиксированной продолжительности
Релиз
В конце каждого спринта после утверждения менеджером проекта (владельцем продукта).
Поток продолжается без перерыва или по усмотрению команды
Владелец продукта, Скрам-мастер, команда разработчиков.
Команду возглавляет PM, в некоторых случаях привлекаются тренеры по agile kanban
Ключевые показатели
Принятие изменений
Во время спринта изменения нежелательны, так как они могут привести к неправильному восприятию целей.
Изменения могут произойти в любое время
Примеры применения в IT
Сразу с Microsoft: Дебют Канбан в сфере программных разработок
Применение принципов Канбан в информационных технологиях началось 10 лет назад. Дэвид Андерсон, один из главных сторонников Канбан для разработчиков программного обеспечения, консультировал компанию Microsoft в 2005 году, где были недовольны работой своего отдела XIT Sustained Engineering, который исправлял ошибки во внутренних приложениях. В начале отчетного года этот отдел был худшим в своей области. Количество нерассмотренных заявлений в пять раз превышало допустимое количество, а время рассмотрения заявления — время оборота — обычно составляло пять месяцев.
Новый руководитель, воспользовавшись советами Андерсона, за 9 месяцев увеличил производительность проблемного отдела на 155%. Время выполнения заказа теперь составляло 5 недель, объем невыполненных работ вернулся к своему обычному размеру, а своевременность выполнения составляла 90%. Все эти результаты были достигнуты при минимальном количестве новых сотрудников, при этом сотрудники продолжали исправлять ошибки программы, используя те же методы — изменился только подход организации.
Думитриу столкнулся с отделом, состоящим из трех программистов и трех тестировщиков, с незавершенным балансом из 80 запросов. Руководитель был назначен на временной основе, поскольку требования к должности включали знание технологии ASP, управление SQL Server и знание MS Project Server. Начальство рассматривало эту должность как «техника», который должен был устанавливать сроки, составлять отчеты и прогнозировать рабочую нагрузку. В то время бытовало мнение, что проблема отдела должна быть выявлена путем сбора внушительного количества данных. Думитриу, однако, не был таким «техником».
Однако начав вместе с Андерсоном анализировать работу XIT, он быстро выявил ключевые факторы, которые негативно влияли на скорость отдела:
- Потребовалось много времени, чтобы предсказать последствия (ROM), к которым приведет выполнение запроса. И программист, и тестировщик должны были потратить целый день на проведение необходимых расчетов, проверку кода и его документирование. В среднем каждый день поступал один запрос. По оценкам руководителя, ПЗУ поглощало 40 % производительности отдела,
- Приоритет отдавался более дорогим запросам. XIT получил финансирование по стоимости запроса. Приоритетность запросов обсуждалась каждый месяц на встрече руководителей отделов с клиентами — руководителями других отделов. При наличии всего 6-7 запросов в месяц, другие запросы постоянно переназначались в зависимости от прошедшего времени. Многие из них были отложены на «более поздний срок», который не наступал даже в следующем месяце.
- На этапе ПЗУ половина запросов была отклонена. Некоторые из них были слишком масштабными и были отнесены к проектам, порученным другим агентствам, другие были слишком дорогими и были просто отменены. Некоторые заявки не были приняты, поскольку их реализация заняла бы слишком много времени. Например, 40 % производительности службы уходило на анализ заявок, из которых 50 % отклонялись. Около 15-20% трудовых ресурсов тратилось впустую.
- Подготовка к подаче заявки может занять несколько месяцев, прежде чем начнется ее реализация. Расчеты на этапе ПЗУ могут быть потеряны или забыты в течение этого периода. Особенно если реализация была выполнена не тем разработчиком, который инициировал анализ.
Канбан-решения для проблемного отдела Microsoft
- Думитриу и Андерсон в ходе обсуждений с высшим руководством и менеджерами клиентов настояли на том, чтобы отказаться от этапа ROM. Расчеты были сделаны непосредственно перед внедрением и тем же разработчиком, что означает, что они остались «свежими».
- Приоритетность запросов устанавливалась не на ежемесячных совещаниях, а в каждом конкретном случае по телефону или электронной почте. 80 задач в бэклоге были отсортированы по клиентам. Последних просили назвать самые важные требования, которые должны быть выполнены в первую очередь.
- Финансирование XIT было стабилизировано.
- Затраты на запросы больше не учитывались.
- PM ввел буферы в таблицу Kanban. Разработчики получали работы из двух областей: утвержденные и завершенные. В буфере было 6 запросов, 5 были обработаны. Рецензенты, выбранные из буфера «ожидающих тестов». Некоторые задачи, не требующие изменения кода, выполнялись там в обход разработчиков. Разделив запросы на отдельные процессы выполнения задач, PM смог лучше контролировать статус и обеспечить прозрачность для клиентов. Введение буферов сократило время доставки. В предсказуемой системе клиентам было легче определить, чей запрос должен быть отправлен в буфер следующим.
- Слишком большие или слишком дорогие запросы решались немедленно. Если разработчик подтверждал, что он готов выполнить работу в течение 15 дней или что изменение имеет смысл, запрос принимался, независимо от размера или стоимости.
- После мониторинга рабочего процесса в отделе, руководитель пришел к выводу, что штатное расписание должно быть изменено в пользу разработчиков, у которых больше работы. Изменения были сделаны по принципу 2:1, в XIT было 4 разработчика и 2 тестировщика.
Ограничения необходимы для повышения производительности труда персонала и ускорения выполнения задач. Это базовая практика, основанная на поиске баланса между производительностью команды и объемом работы, которую необходимо выполнить.
Правила работы с карточками
Основные правила Канбан для работы с карточками направлены на поддержание потока процесса, корректировку сроков и наблюдение за задачами, которые по какой-либо причине не попадают в поток:
Порог WIP может быть разным для определенных специалистов или отделов в зависимости от их ресурсов. Цель отсечения — сфокусировать внимание сотрудника на одной задаче, а не пытаться выполнять много задач одновременно.
Лимит регулирует количество карт в каждой колонке. Лимит основан на фактической вместимости группы и включает все используемые карты.
Вы не можете начать новую карту, если предыдущая карта не была завершена. Если задание не может быть выполнено по какой-либо причине, его следует переместить в колонку «Заблокировано» и искать другие способы его выполнения.
Приоритет задач в Kanban зависит от их важности для бизнеса или клиента и размера упущенной выгоды или затрат, если они не будут выполнены вовремя. Чтобы членам команды было понятно, какая задача является наиболее важной, вводятся категории эффективности, которые обозначаются на карточках с символами:
срочные — не терпят отлагательств,
с установленным сроком — работа должна быть завершена к определенной дате,
стандартный — стоимость увеличивается пропорционально задержке, поэтому желательно, чтобы работа была выполнена вовремя,
несущественная — стоимость задержки увеличивается медленно, работа не является срочной и не требует немедленного выполнения, когда есть более важные дела.
Должно быть ответственное должностное лицо — руководитель службы — которое следит за продвижением карточек Канбан. На каждые три-пять групп может быть только один менеджер по обслуживанию.
Обязанности менеджера по предоставлению услуг:
Добавлять новые задачи в бэклог на основе требований бизнеса или клиентов,
Проанализируйте проблемные зоны,
Определите нерешенные задачи,
Выявить коренные причины трудностей.
Метод Канбан не предусматривает назначение специального координатора — аналога Скрам-мастера в Скраме. На практике, однако, такой человек часто бывает необходим. Это может быть гибкий тренер, который работает с несколькими командами одновременно. Его задача — поддерживать команды в адаптации Канбан к потребностям компании и постоянно совершенствовать процессы.
Ритм работы команды
Канбан рекомендует проводить регулярные собрания для координации работы команды и обратной связи. Они проводятся на уровне команды и компании.
Собрания на уровне команды:
Kanban-совещания — ежедневные 15-минутные встречи для обсуждения текущих задач на день,
Совещания по обновлению бэклога — раз в неделю в течение 30 минут для добавления новых задач и определения их приоритетности,
Встреча с клиентом — 30-минутная встреча с клиентом, на которой команда определяет, довольны ли они качеством и темпом работы,
Обзор рисков — ежемесячная встреча для обсуждения прошлых ошибок и поиска путей их исправления.
Встречи на уровне компании:
Анализ рабочих процессов — проводится ежемесячно для оценки общей эффективности работы всех команд и отделов и определения путей улучшения,
Обзор стратегии — ежеквартальная встреча для оценки работы всей организации путем определения ключевых вопросов. Присутствуют ключевые члены команды и руководители.
Некоторые виды совещаний можно объединить в одно, чтобы участники не были обременены большим количеством совещаний. Некоторые из них могут оказаться бесполезными для вашей организации.
Чем канбан отличается от скрама
Scrum и Kanban — это agile-методы, и оба используют карточные таблицы и общие принципы и ценности agile-менеджмента. Однако они не взаимозаменяемы и используются в командах с разными целями.
В Scrum работа над продуктом делится на запланированные спринты — периоды времени, в течение которых выполняется заранее определенный список задач, обычно две недели. Во время спринта в проект не могут быть добавлены новые карточки из бэклога. Скрам подходит для команд, разрабатывающих продукт, который можно спланировать, и не подходит для команд, где приоритеты меняются ежедневно.
В Kanban карточки перемещаются по доске непрерывным потоком на основе приоритетов. Приоритеты могут быть изменены в любое время в зависимости от обстоятельств. Это обеспечивает большую гибкость, чем Scrum.
Канбан — это метод управления командами, когда составление расписания невозможно. Это может быть, например, в случае с технической поддержкой: Если клиент позвонил и сообщил о проблеме, команда не может планировать ее решение в следующем спринте через две недели. Важно решить проблему как можно быстрее и не потерять лояльность клиентов, что означает, что планирование и расстановка приоритетов должны быть гораздо более динамичными, чем в Scrum. Используя Kanban в своей службе поддержки, вы повышаете уровень удержания и удовлетворенности клиентов.
В офисе Corbis была установлена доска Kanban, где Андерсон ежедневно проводил обсуждения с командой. Цель ПМ заключалась в улучшении визуального контроля процессов, поощрении самоорганизации и укреплении ответственности персонала. Система Канбан также должна была уменьшить контроль со стороны руководства и повысить производительность.
Десять самых распространенных ошибок при использовании «Канбана»
В простоте метода Канбан кроются тонкости, которые приводят к его неправильному применению.
1. Все начинается и заканчивается доской
Самая типичная и распространенная ошибка, которую мы видим сегодня, — это понимание Канбан как матрицы визуализации. Многие считают, что у них есть Канбан, как только они наклеили на стену кучу стикеров с описанием задач. Это в корне неверно.
«Канбан» — это метод совершенствования услуг эволюционным путем, включающий шесть ключевых практик. Если нет всех этих элементов, то реализация концепции несовершенна и не должна даже носить название «Канбан». Недостаточно просто визуализировать проект.
2. Отсутствуют организационные изменения
Метод Канбан предназначен для ускорения изменений, поэтому он должен привести к организационной трансформации компании. Барьеры между отделами будут разрушены, и они больше не будут работать изолированно друг от друга. Другие отделы будут сливаться, исчезать или появляться. Вся организационная структура должна стать динамичной и чутко реагировать на потребности рынка.
Большинство компаний, внедряющих Канбан, хотят сохранить статус-кво и любой ценой избежать изменений. Однако если в течение трех месяцев в компании не произошло эволюционных изменений, можно с уверенностью сказать, что Канбан здесь даже не пахнет.
3. Нет самоорганизации
Еще одним показателем неправильного понимания Канбан является отсутствие самоорганизации. Люди, которые организуют свою работу с помощью Канбан, должны сами изменять и оптимизировать свой процесс. Во многих компаниях эту задачу выполняют менеджеры, а не ключевые сотрудники.
Самоорганизация является важной частью системы Канбан, и ею нельзя пренебрегать. Даже если у вас есть совет директоров и организационные изменения заметны.
4. Проводится организация людей, а не работы
Многие имитации Канбан сосредоточены на организации людей, а не на работе, которую эти люди выполняют. Это распространенная ошибка, но ее легко заметить. Посмотрите на доску Канбан: Если горизонтальные пути помечены именами людей, значит, компания попала в ловушку организации людей. Это снова не «Канбан».
«Канбан» предназначен для организации работы, поэтому горизонтальные ряды доски должны показывать типы или этапы работы, а не имена людей.
5. Нет циклов обратной связи
Петли обратной связи — одна из обязательных практик Канбан. Циклы могут варьироваться от ежедневной подготовки, регулярных демонстраций (тестов) пользователям, обзоров обеспечения уровня обслуживания, функциональных обзоров, частоты поставок и частоты пополнения системы.
Важно, чтобы эти мероприятия проводились регулярно и чтобы обратная связь служила основой для организации работы команды.
6. Нет ограничений одновременно выполняемой работы
«Канбан» ограничивает объем работы, который может быть выполнен за один раз. К сожалению, эта практика игнорируется даже чаще, чем петли обратной связи.
Ограничения необходимы для повышения производительности труда персонала и ускорения выполнения задач. Это базовая практика, основанная на поиске баланса между производительностью команды и объемом работы, которую необходимо выполнить.
7. Договоренности не меняются
«Канбан» требует четких договоренностей между членами команды, что обычно не является проблемой. Однако команды часто забывают, что соглашения также необходимо регулярно обновлять, и представляют соглашения на пожелтевших листах бумаги. Это не Канбан.
