Собираетесь внедрить канбан в бизнес-процессы? Вот с чего стоит начать. Система Канбан: что такое, с чего начать, как внедрить, главные принципы

Максимально коротко о Канбан-методе, его основные термины и области применимости.

Максимально коротко описали Канбан-метод, его основные термины и области применимости.

1. Что такое Канбан-метод?

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

Канбан, как инструмент в IT-менеджменте был представлен Дэвидом Дж. Андерсоном в компаниях Microsoft (2005) и Corbis. А широкое распространение и название, как метод, получил в 2007 году.

2. Канбан-метод и Канбан Тойоты – это одно и то же?

(Самая большая карточка). Не совсем так. Канбан на заводах Тойоты – это бережливое производство, определяющим принципом которого является понятие “точно в срок”. Канбан, как термин в управлении, действительно пошел от Тойоты. В переводе с японского это слово означает “сигнал” или “карточка”. На автомобильных заводах такие карточки использовались, чтобы передать информацию с одного этапа на следующий о том, сколько и каких деталей потребуется.

Давайте разберем короткий пример. Нам нужно сделать три автомобиля “точно в срок”. Это значит, что мы точно заранее можем определить, сколько нам потребуется деталей на определенных этапах, и начинаем с конца вытягивать необходимое количество деталей для создания этого автомобиля, отвечая на вопросы: “Сколько литров краски нам потребуется?”, “Сколько колес?”, “Сколько двигателей?” и так далее. Таким образом, мы не создаем излишки запасных частей в виде остатков и экономим на складах, логистике и прочих издержках.

Канбан-метод тоже придерживается понятия “точно в срок”, но в отличие от заводов Тойоты здесь речь идет об интеллектуальном труде. Иными словами, код программиста или идею маркетолога нельзя пощупать и увидеть обычному человеку, пока он(она) не превратится в конечный продукт или сервис. Таким образом, Канбан-метод используется для визуализации потока интеллектуальной работы и сокращения количества этой незавершенной работы. За счёт этого достигается равномерная и предсказуемая скорость оказания услуги конечному потребителю.

3. Можно ли использовать Канбан-метод не в IT?

Да. Канбан-метод подходит для визуализации потока любой творческой и интеллектуальной работы. Но гораздо эффективнее использовать его через призму сервисной парадигмы. Посмотрите на то, что вы делаете, как на сервис. Через какие стадии проходит работа, чтобы сервис был оказан? По каким критериям вы поймете, что сервис оказывается в соответствии с ожиданиями Заказчика? Это отправная точка в применении Канбан-метода. Канбан-практики называют эту точку “начните с того, что есть сейчас”.

4. Канбан – это как Скрам?

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

5. У Канбана есть ценности?

Да. Их девять: прозрачность, баланс, сотрудничество, клиентоориентированность, поток, лидерство, понимание, согласие, уважение.

6. Вы написали о принципах Канбана. Какие они?

У Канбана действительно есть базовые принципы, которые еще называют принципами управления изменениями:

  1. Начните с того, что есть сейчас.
  2. Договоритесь об эволюционном развитии.
  3. Поощряйте развитие лидерства на всех уровнях.

Так как Канбан-метод живет в сервисной парадигме, он придерживается ее принципов:

  1. Выясните потребности и ожидания заказчика.
  2. Управляйте работой, дайте людям организоваться вокруг нее.
  3. Развивайте правила, чтобы улучшить показатели.

7. А что за практики в Канбане?

Их тоже шесть:

  1. Визуализируйте.
  2. Ограничивайте незавершенную работу.
  3. Управляйте потоком работы.
  4. Используйте явные правила.
  5. Вводите петли обратной связи (каденции).
  6. Улучшайте и эволюционируйте.

Это непосредственно практические приемы, которые мы используем для улучшения нашей работы и повышения качества сервиса.

8. О, каденции! Что такое каденции в Канбане?

Каденция – термин из музыки. В контексте Канбан-метода она обозначает ритм. Каденциями называют регулярные встречи, которые еще являются петлями обратной связи. Регулярность задает ритм, с которым течет поток работы. Каденций семь:

  1. Канбан-митинг (ежедневная). Здесь обсуждаем статус заблокированных задач.
  2. Встреча по наполнению очереди (обычно раз в две недели). Берем на себя обязательства, что будет делать, как сервис.
  3. Встреча по планированию поставки (обычно раз в две недели). Возвращаем выполненные обязательства обратно.
  4. Встреча по обзору сервиса (обычно раз в две недели). С метриками обсуждаем качество сервиса и как его улучшить, если нужно.
  5. Операционная встреча (обычно раз в месяц). С метриками обсуждаем качество взаимодействия связанных сервисов.
  6. Встреча по обзору рисков (обычно раз в месяц). С метрикам обсуждаем влияние заблокированных задач на работу сервиса.
  7. Встреча по обзору стратегии (обычно раз в квартал). С метриками обсуждаем изменения в стратегии.

9. Я что-то слышал про классы обслуживания. Что это?

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

  1. Ускоренный класс – неотложная скорая помощь-реанимация. Едет по выделенной полосе. Нет времени откладывать решение проблемы. Нужно как можно скорее.
  2. Класс с фиксированной датой – стоимость задержки резко возрастает после определенного периода. Пример: проект в виде ФЗ с фиксированной датой начала действия. Не успеем вовремя, есть риск потерять лицензию.
  3. Стандартный класс – стоимость задержки растет пропорционально времени. Если делаем сразу, получаем прибыль сразу. Если делаем долго, получаем прибыль долго.
  4. Нематериальный класс – делаем, но явной прибыли эта работа не несет, стоимость задержки растет медленно. Например, уборка в доме. Можно и не убираться регулярно, но через пол года придется делать генеральную уборку.

10. Что на счет метрик? Как померять эффективность работы сервиса?

У Канбан-метода есть метрики, которые позволяют ответить на вопросы: какие проблемы в потоке работы, какая пропускная способность у сервиса, какое время выполнения, какое время разрешения блокировок, какое время цикла и по каким типам распределяется работа? Все это позволяет менеджеру сервиса принимать решения о развитии и улучшении качества сервиса на основе накопленных данных.

11. С какими проблемами сталкивается Канбан при внедрении?

Основная трудность – это объяснить людям на всех уровнях ценность практик Канбана: визуализации и ограничения незавершенной работы. Из-за того, что люди не видят объем интеллектуального труда, им сложно понять, какой нагрузке они подвергаются. А ведь мозг, к примеру, такая же мышца, как и бицепс. Представьте себе тренажерный зал: вы приходите и видите вес на штанге: “Так, это слишком мало. А сейчас – слишком много. А вот это в самый раз!” С мозгом нужно работать точно также: “Вот эта – большая задача, а эта – маленькая, да и вообще как-то много я на себя взвалил. Ограничу-ка я нагрузку”. Когда на всех уровнях мы делаем сквозную визуализацию потока работы и ограничиваем количество незавершенной работы, мы создаем вытягивающий принцип для интеллектуального труда и делаем равномерный поток его результатов для наших клиентов.

12. А какие есть программы для Канбан-метода?

Их тоже много. Перечислим только профессиональные, разработанные специально под метод. Наше сердце отдано российской разработке Kaiten . Кроме нее есть еще TargetProcess, SwiftKanban, LeanKit и другие.

13. И в каких компаниях уже используется Канбан-метод?

Среди российских это Альфа-Банк, Хоум Кредит Банк, Почта-Банк, Додо Пицца, HeadHunter, Clever и другие. Из иностранных: Wargaming, Microsoft, Automotive IT, Blizzard Sports, Dr Dobb’s, Siemens, Tupalo. Этот список можно продолжать долго.

14. Есть еще что-то важное?

Да. Напоследок хотелось бы отметить важность двух ролей в Канбан-методе. Это менеджер сервиса поставки (service delivery manager) и менеджер сервиса запросов (service request manager). Первый отвечает за устранение препятствий в потоке поставки. Второй – за управление потоком запросов к сервису от множества заказчиков. Очень важно, чтобы эти две роли были партнерами и работали в паре.

15. Окей, я понял. С чего начать внедрение Канбана в организации?

Чтобы начать внедрение Канбана в организациях, мы используем инструмент S.T.A.T.I.K. – системный подход к применению Канбана. Подробнее о нем можно почитать в Интернете. Но мы рекомендуем посетить тренинг , на котором данный инструмент преподается в формате бизнес-игры. На примере своего сервиса (организации) вы можете спроектировать Канбан-систему для последующего применения в боевых условиях.

Тренер и консультант по гибким методологиям, Скрамтрек.

Добрый день!

Одним из моих профессиональных интересов, как координатора команды тестировщиков, являются методологии разработки программного обеспечения. В настоящее время все большую популярность приобретают так называемые Agile-методологии, в особенности Scrum и Kanban. На «раcпиаренных» терминах играют недобросовестные «тренеры», семинары и сертификации («сертифицированный Scrum-мастер», «сертифицированный Product owner» и т.д.) растут как на дрожжах.

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

В процессе работы я часто сталкивался с непониманием и неверным трактовкам инструментов методологий, применения модной методологии без учета контекста. После прочтения статьи я понял что проблема скорее глобальная, чем локальная. Предлагаю сегодня немного рассмотреть Kanban, его историю, основные принципы, и возможные границы применения.

История термина
Kanban – японский термин, который начали использовать применительно к производству в 60-х годах 20-го века в компании Toyota. В основу данного принципа положен конвейерный метод производства, а также различные скорости выполнения отдельных технологических операций на производстве. Попробую объяснить на пальцах. При любом производстве есть основное производство («главный конвейер») и дополнительное производство («дополнительные конвейеры»). Темп выпуска конечных изделий задает главный конвейер, в то время как дополнительные конвейеры не могут ускорить темп выпуска изделия, но могут замедлить его, в случае несвоевременного выпуска требуемых деталей.

Дополнительно, при производстве может произойти смена приоритетов. К примеру выяснилось что станция, которая производила левые зеркала произвела 20 шт., а станция производившая правые зеркала - 10 шт., в то время как на конвейере находятся 15 автомобилей и необходимо 15 штук зеркал обоих типов. Налицо конфликт метрики - количественно производство не упало (дополнительные конвейеры выпустили 30 изделий в срок), но производство все равно рискует остановится. Kanban призван помочь с этой проблемой.

В упрощенном варианте, Kanban включает в себя два простых правила:

  • производственная станция имеет план производства деталей («backlog»). План отсортирован по приоритету, и может меняться в любое время (к примеру станция производящая слишком много левых зеркал должна иметь возможность переключиться на правые как можно скорее);
  • количество задач, выполняемых на станции одновременно ограничено (т.е. производить не более заданного количества зеркал одновременно). Это ограничение необходимо для управления скоростью производства на станции, а также скоростью реагирования на изменения плана.
Настоящее время
В последнее время, Kanban набирает большую популярность в производстве программного обеспечения. Некоторые команды считают эту методологию исключительно полезной, некоторые используют по принципу «культа Карго». Основываясь на моем эмпирическом опыте чистый Kanban плохо работает для продуктовых команд (читай - «основной конвейер»), но отлично работает с командами поддержки, такими как:
  • группы поддержки программного обеспечения, где не важен «план», но важна скорость реагирования на изменения;
  • группы тестирования, работающие отдельно от групп разработки;
  • службы поддержки;
  • другие примеры «неосновных производств».

Отдельно необходимо отметить, что Kanban хорошо работает в стартапах, не имеющих четкого плана, но активно работающих над разработкой. Предлагаю рассмотреть пример использования Kanban в разработке программного обеспечения. Заранее прошу простить за некрасивые иллюстрации. Давайте представим себе команду из одного разработчика, работающего над небольшим проектом. План разработки (backlog) отсортирован в порядке приоритета кусков работы, лимит команды на задачи в процессе - 1 шт.

Для управления процессом руководитель проекта может:

  1. изменить лимит на количество задач в работе;
  2. добавить задачу с более высоким приоритетом (к примеру p0) для того чтоб она была взята как можно скорее;

В процессе работы может так произойти, что работа заблокирована (сломался хостинг, не скачан нужный framework и т.д.). В общем случае, заблокированная работа возвращается в backlog, и выбирается новая задача, с максимальным приоритетом. В зависимости от характера задач и типа команды лимит может быть увеличен или уменьшен. К примеру, наш разработчик может одновременно рисовать форму регистрации и смотреть за процессом развертывания нового сервера. Тем не менее, если время завершения задач будет меньше требуемого, руководитель проекта может уменьшить лимит, или увеличить команду. Таким образом, при грамотном руководстве, Kanban обеспечивает максимально возможную для данной команды скорость работы, максимальную скорость реагирования на изменения и в то же время сократить «расходы» на поддержку методологии. В общем все! Kanban - это не просто, просто. Это очень просто!

К ограничениям Kanban"а при использовании его в продуктовых командах можно отнести:

  • данная методология плохо работает с большими командами (больше 5 человек);
  • в чистом виде, Kanban плохо работает с кросс-функциональными командами. Т.е. в отличие от Scrum, тяжело совместить тестирование и разработку в одной команде. Более удачной мыслью является разбить процесс на «станцию» разработки и «станцию» тестирования с отдельными руководителями и backlog-ами;
  • ввиду своей истории и специфики, Kanban не предназначен для долгосрочного планирования.
Заключение
В заключение, хочу добавить, что сравнение любых методологий по принципу «кто круче» не продуктивно и контр-конструктивно (капитан очевидность). Каждая, более-менее распространенная, методология имеет свои плюсы, минусы и границы применения. Дополнительно, Agile-методологии в принципе накладывают большие требования на сработанность и опыт членов команды.

В случае возникновения интереса к теме продолжу рассмотрение Kanban"a подробнее. В последствии, предлагаю разобрать по полочкам и картинкам Scrum и RUP.

Более подробно, и наглядно можно посмотреть в.

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

Сущность понятия и основные особенности метода

Сегодня можно наблюдать яркую тенденцию к увеличению затрат на хранение запасов, что является основной причиной формирования комплексов «мгновенного» управления ими, куда относится и система канбан. В переводе с японского "канбан" означает "бирка", "значок". Данный термин служит методом информирования, посредством которого дается разрешение или же указание на производство или исключение (передачу) продукта в вытягивающей системе.

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

Разработчиком столь продуктивной системы является Toyota Motors, поясняющая представленную идею как одну из первых попыток практического внедрения метода «точно в срок». По системе канбан производство осуществляется в соответствии со следующим правилом: подразделения предприятия снабжаются ресурсами в конкретном количестве и к четко определенному сроку, необходимому для выполнения заказа.

Подробности процесса

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

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

  1. С n-го этапа на n-1 запрашивается ("вытягивается") необходимое количество незавершенного производства.
  2. С n-1-го этапа на n-ый направляются ресурсы материального характера в нужном объеме.

Инструменты передачи информации

Чтобы лучше понять, канбан - что это такое, следует уяснить, что инструментом передачи сведений в данной системе служат специальные карточки, которые классифицируются на две группы:

  1. Инструменты, имеющие прямое отношение к производственному заказу. В такого рода карточках в первую очередь указывается число деталей, которое должно быть произведено на предшествующей ступени производственного процесса. Они отправляются с n-го этапа производства на стадию n-1 и служат основной причиной для разработки производственной программы этих участков.
  2. Инструменты отбора содержат информацию в отношении объема необходимых ресурсов материального характера (сюда можно отнести полуфабрикаты, материалы, детали и пр.), которые должны быть взяты на предшествующем этапе сборки. Такого рода карточки отображают ресурсный объем, по факту полученный n-ым этапом производственного процесса от n-1-ого.

Важно отметить, что карточки могут осуществлять циркуляцию не только в отношении внутренней инфраструктуры предприятия, но и между его филиалами или корпорациями, которые поддерживают сотрудничество.

Эффективные методы использования канбан - что это такое?

Тайити Оно, президент корпорации Toyota Motor Corporation, разработал ряд принципов, позволяющих с максимальной эффективностью применять карточки канбан:

  • Последующая операция в отношении производственной деятельности изымает объем деталей, указанный карточкой, от предшествующей операции.
  • Производственная операция, находящиеся впереди, осуществляется в соответствии с созданием деталей в том количестве и последовательности, которая указана в конкретной карточке.
  • Нет таких деталей, которые могут быть созданы без карточки. Данное положение позволяет обеспечить сокращение перепроизводства, а также избыточное перемещение продукции. Так, объем карточек, пребывающих в обороте, равнозначен максимальному количеству запасов.
  • Карточка - это заказ на изготовление продукта (товар в любом случае пристраивается к соответствующей карточке).
  • Детали, имеющие какой-либо дефект, не могут передаваться в последующий процесс. Это положение позволяет сделать выпуск изделий максимально бездефектным.
  • Снижение числа карточек увеличивает уровень их чувствительности. Так, наружу выходят имеющиеся проблемы и осуществляется результативный контроль в отношении запасов.

Особенности применения карточек

Как выяснилось, управление канбан осуществляется по определенной схеме, которая предполагает использование специальных карточек. Так, в ходе их применения в полной мере должны реализовываться требования по обеспечению абсолютной обзорности и предельной безопасности рассматриваемой системы: полностью исключается потеря карточек, а также их смешивание.

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

Преимущества применения метода канбан - что это такое?

Предприятиям, применяющим осуществляется ежедневная поставка материальных ресурсов (а зачастую и несколько раз на протяжении дня). Это позволяет в полной мере обновлять производственные запасы приблизительно 100-300 раз в течение года. Если сравнить канбан с такими системами, как MRP или MAP, то в рассматриваемом случае происходит обновление примерно в 10 раз чаще.

Целесообразны для оценки метода канбан примеры, выявляющие его абсолютное преимущество над другими, менее продуктивными. Так, корпорация Toyota Motors на один из множества участков производства в 1976 году поставляла ресурсы три раза в день, а в 1983 г. - уже каждые десять минут.

Зачастую канбаны применяются в работе с супермаркетами (специально сформированным для этого запасом). Так, потребитель направляет к супермаркету канбан отбора, где указывается, как отмечалось выше, объем продукта, а супермаркет передает ему заданное количества изделий. В то же время супермаркет направляет в сторону поставщика канбан восполнения, после чего поставщик передает продукцию в супермаркет.

Основополагающие элементы метода

Важнейшими компонентами системы канбан являются следующие:

  1. Информационный комплекс, который содержит в своей структуре не только карточки, но и графики производственного, транспортного или снабженческого характера, а также карты технологической направленности.
  2. Комплекс, имеющий прямое отношение к контролю над потребностями и в профессиональном плане.
  3. Комплекс, позволяющий осуществить всеобщий (TQM) и выборочный ("Дзидока") контроль качества продукта.
  4. Комплекс, осуществляющий абсолютное выравнивание производства.

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

Недостатки системы и результаты ее применения

Как и любая разработка, система «точно в срок» наделена некоторыми минусами. Во-первых, это сложность организации высокого уровня согласованности между этапами производства того или иного продукта.

Во-вторых - существенный риск срыва процесса производства, соответственно, и реализации изделий. Тем не менее подробный анализ мировой практики в отношении применения рассматриваемого метода показал, что представленная система дает возможность снизить производственные запасы в два раза, а товарные - на 8%, при значительном ускорении оборачиваемости оборотных средств и, естественно, повышении качества готового продукта.

Важно отметить, что применение канбанов не заканчивается на производственных процессах. Так, система активно используется в офисной и проектной деятельности, в программировании (существует целый комплекс kanban development), а также в достижении личных результатов (персональный тип канбана).

Система канбан начала свой путь в 1950-х годах на производственных линиях корпорации Toyota, после чего перекочевала в офисы и стала важным инструментом для проектных менеджеров.

Бескрайняя гибкость практики и ее возможности для самоорганизации персонала позволили добиваться эффективности там, где другие подходы не работали. Это тот случай, когда визитной карточкой системы стала сама карточка — она утвердилась как внутренняя валюта в организациях, которые внедрили канбан.

Происхождение

Как и концепция бережливого производства (Lean), система канбан была разработана менеджерами Toyota. Автора системы, японского инженера Тайити Оно, вдохновил принцип работы американских супермаркетов, где покупатель сам выбирал нужные себе товары. Роль «супермаркета» в корпорации Toyota выполнил склад.

Там сигнальными карточками — а именно так дословно с японского языка переводится «канбан» — обменивались работники, собственноручно регулируя производственный процесс.

Карточки крепились к таре с деталями. На таких бирках указывалась информация о номере и количестве деталей, какой отдел их отправляет и куда они должны прибыть.

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

Производственный «канбан» заменялся на «канбан» с запросом для склада и отправлялся на производственную линию запчастей — верхний поток. Поэтому производилось именно то количество деталей, которое указывалось в карточке. Тара с новыми запчастями относилась транспортировщикам на монтажную линию.

Принципы канбана

Менеджеры Toyota сформулировали 6 системообразующих правил:

  1. Исполнители из нижнего потока изымают ровно столько деталей из склада, сколько указано в канбане
  2. Представители верхнего потока тоже поставляют запчасти строго в соответствии с карточками
  3. Ничто не производится или не перемещается без канбана
  4. Канбан должен быть всегда прикреплен к деталям
  5. Бракованные запчасти не используются в системе
  6. Уменьшение количества карточек канбан делает управление более чувствительным к переменам. Но без крайней необходимости менять устоявшееся количество карточек не стоит.
Канбан — это «вытягивающая» система. В ней создается баланс между постоянным потоком, который устраняет затраты на ожидание, и минимальным количеством работы в процессе (РВП), что снижает риски перепроизводства. РВП регулируется с помощью карточек: их количество зафиксировано, а инструкции в них направляют исполнителей нижнего потока.

Правило обязательно прикрепленной бирки работает как закон сохранения энергии.

Лимит РВП составляется в пропорции к количеству канбан-карточек, которое рассчитывается в зависимости от уровня продаж и статистической вариантности в текущих процессах. Максимальное количество бирок — та самая «энергия» в системе — закрепляет верхний уровень РВП в любое заданное время. РВП также ограничивается принципом вытягивания: скорость производства верхнего потока зависит от скорости работы нижнего.


На графике видно, что одним из базовых элементов системы является культура Кайзен. Автономный процесс и стандартная вариантность освобождает менеджмент от постоянного управления, поэтому он может сосредоточиться на улучшении работы сотрудников.

Применение канбан в IT

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

Только карточки, на которых указаны информация о сроках выполнения, описание или номер процесса и имя исполнителя, теперь прикрепляются не к таре с запчастями, а к доске с расчерченными колонками:

  • Бэклог — задачи, которые надо выполнить
  • Задачи, которые в данный момент разрабатываются
  • Задачи, которые выполнены, но еще не переданные тестировщикам
  • Задачи, готовы к передаче отделу тестирования
  • Задачи, которые проходят проверку проект-менеджером (ПМ)
  • Выполненные задачи

Над колонками обычно пишется число — лимит , указывающий на максимальное количество процессов в ней. Лимит бэклога высчитывается в зависимости от ведущего времени. Если в системе 5 работ в процессе, и завершение каждой из них в среднем занимает 1 день, то и бэклог можно ограничить лимитом 5.


Структура выше не является строгой — в зависимости от специфики проекта могут быть добавлены импровизированные колонки. Нередко встречается канбан система, в которой требуется определить критерии готовности задачи перед ее выполнением. Тогда появляются две колонки, которые в английском языке называются specify (уточнить параметры) и execute (взяться за работу).

  • Еще может добавляться колонка с приоритетной очередью. Когда исполнитель освобождается, то он должен опустошить именно эту колонку с задачами, а затем браться за другие.
  • Задачи, которые не были выполнены, либо возвращаются в бэклог, либо вычеркиваются из схемы.
  • Канбан не поощряет многозадачность, поэтому устанавливается лимит процессов для одного исполнителя.
  • Выполненная работа предпочтительнее нескольким начатым.
  • Браться за вторую работу можно, если первая была заблокирована.
  • Время для выполнения задачи должно быть сбалансировано. Слишком короткий срок отразится на качестве. Чересчур растянутый лимит растрачивает ресурсы команды и повышает стоимость процесса.


Почему повсеместно используется канбан-доска, а не, например, планшеты или огромный монитор? Как отвечают на этот вопрос поклонники системы, обычная доска имеет два преимущества: она проста и обеспечивает визуальный контроль. На ней легко вносить изменения, и она обеспечивает тактильное и социальное взаимодействие между участниками команды.

Преимущества и недостатки канбан

Kanban имеет такие достоинства:

  1. Гибкость планирования. Команда концентрируется только на текущей работе, приоритет задачи выставляется менеджером.
  2. Высокое вовлечение команды в процесс разработки. Благодаря постоянным собраниям, прозрачности процессов и возможностям самоорганизации работники сплачиваются и проявляют искренний интерес.
  3. Меньшая продолжительность цикла. Если несколько человек обладает схожими навыками, продолжительность сокращается, если же только один — появляется узкое место. Поэтому сотрудники должны делиться знаниями и тем самым оптимизировать продолжительность цикла. Тогда вся команда сможет взяться за работу, которую забуксовала,и восстановить плавный поток.
  4. Меньше узких мест. Лимиты РВП позволяют быстро находить узкие и проблемные места, которые появились из-за дефицита внимания, людей или навыков.
  5. Наглядность. Когда все исполнители имеют доступ к данным, то узкие места легче заметить. Kanban-команды, помимо самих карточек, обычно используют два общих отчета: графики управления и совокупного потока.

На практике система отлично себя показывает в сферах неосновного производства:

  • группы поддержки программного обеспечения или службы поддержки.
  • Канбан хорошо работает при управлении стартапами без четкого плана, но где активно продвигается разработка.

Канбан имеет и недостатки:

  1. система плохо работает с командами численностью более 5 человек
  2. он не предназначен для долгосрочного планирования.

Отличия от Скрама

Скрам, как и agile kanban, является гибкой методикой и тоже часто применяется в IT-сфере. Различия между ними не очевидны на первый взгляд. Существует много схожестей, например, наличие бэклога в обоих подходах.

Скрам

Канбан

Темп

Повторяемые спринты фиксированной продолжительности

Непрерывный процесс

Выпуск релиза

В конце каждого спринта после одобрения проектным менеджером (владельцем продукта)

Поток продолжается без перерывов или на усмотрение команды

Роли

Владелец продукта, Scrum-мастер, команда разработчиков

Команда под руководством ПМ, в некоторых случаях привлекаются тренеры по agile kanban

Главные показатели

Скорость команды

Ведущее время

Приемлемость изменений

В ходе спринта изменения нежелательны, так как могут привести к неверной оценке задач

Изменение могут случиться в любой момент

Примеры применения в IT

Сразу с Microsoft: Дебют Канбан в сфере программных разработок

Использование принципов канбана в сфере информационных технологий началось чуть более 10 лет назад. Дэвид Андерсон, один из главных популяризаторов канбана для программных разработчиков, консультировал в 2005 году компанию Microsoft. Там были недовольны работой своего отдела — XIT Sustained Engineering, который устранял ошибки во внутренних приложениях. К началу отчетного года этот отдел был худшим в своем департаменте. Бэклог превысил допустимый размер в 5 раз, а время на обработку одного запроса — ведущее время — обычно занимало 5 месяцев.

Новый ПМ с помощью консультаций Андерсона за 9 месяцев повысил продуктивность проблемного отдела на 155%. Ведущее время теперь составляло 5 недель, бэклог вернулся к нормальному размеру, а своевременное выполнение задач утвердилось на уровне 90%. Все эти результаты были достигнуты с минимальным привлечением новых работников, персонал продолжал теми же методами исправлять программные ошибки — поменялись лишь подходы к организации работы.

Интересный факт: программный менеджер Драгос Думитриу, который взялся переломить ситуацию в XIT, как раз был увлечен книгой Андерсона. К своему удивлению, он встретил идеолога программного канбана в самой компании Microsoft, куда тот накануне устроился. Думитриу попросил Андерсона помочь со своей задачей, и последний согласился применить принципы своей книги на практике.

Думитриу застал отдел, состоявший из трех разработчиков и трех тестировщиков, у которых в бэклоге накопилось 80 запросов. Сам ПМ был назначен временно, так как требования к вакансии включали умение работы с технологией ASP, администрирование с помощью SQL Server и знание MS Project Server. Начальство видело на этой должности «технаря», который умеет программировать, должен составлять отчеты и прогнозировать загрузку бэклога. Как считалось тогда, проблема отдела будет выявлена, если собрать внушительный массив данных. Думитриу же таким «технарем» не был.

Однако начав вместе с Андерсоном анализировать работу XIT, он быстро выявил ключевые факторы, которые негативно влияли на скорость отдела:

  • На прогнозирование последствий (ROM), к которым приведет исполнение запроса, уходило слишком много времени. И разработчику, и тестировщику приходилось тратить полный рабочий день, чтобы провести необходимые вычисления, проверку кода и заполнить документацию. В среднем ежедневно приходил один запрос. По подсчетам ПМ, на ROM уходило 40% от производительности отдела;
  • Приоритет отдавался запросам с большей стоимостью. XIT получал финансирование за счет стоимости заказа. Приоритетность запросов обсуждалась каждый месяц на встрече менеджеров отдела с заказчиками — менеджерами других отделов. При распирающем бэклоге при текущий скорости, когда за месяц обрабатывались лишь 6-7 запросов, постоянно менялись приоритеты других заявок из-за проходящего времени. Многие из них были отложены на внушительное «потом», не равное даже следующему месяцу.
  • На стадии ROM отсеивалась половина запросов. Часть из них были слишком большие и переквалифицировались в проекты с передачей другим отделам, другие являлись слишком дорогими и попросту отменялись. Некоторые запросы не брались в разработку из-за того, что их внедрение оказалось бы слишком долгим. Таким образом, 40% производительности отдела уходило на анализ запросов, 50% из которых были забракованы. Около 15-20% рабочих ресурсов тратилось впустую.
  • Подготовительная работа по запросу могла длиться месяцами, прежде чем начиналось внедрение. Вычисления на стадии ROM могли за это время затеряться или забыться. Особенно, если внедрением занимался не тот разработчик, который начинал анализ.

Канбан-решения для проблемного отдела Microsoft

  1. Думитриу и Андерсон настояли в беседе с руководством и менеджерами-заказчиками на отказе от стадии ROM. Расчеты производились непосредственно перед внедрением и тем же исполнителем, то есть оставались «свежими».
  2. Приоритизация запросов проводилась не в ходе ежемесячных совещаний, а по ситуации, посредством телефонных звонков или электронных писем. 80 задач в бэклоге рассортировали в зависимости от заказчиков. Последних попросили выделить главные запросы, которые нужно выполнить в первую очередь.
  3. Финансирование XIT стало фиксированным.
  4. Стоимость запросов перестала браться в расчет.
  5. ПМ ввел буферы на канбан-доске. Разработчики брали работу из двух зон: одобренные и выполненные задачи. В буфере находились 6 запросов, 5 брались в работу. Тестировщики выбирали из буфера «ожидает тестирования». Некоторые задачи, которые не требовали изменений в коде, попадали туда, минуя разработчиков. Разбив запросы на однозадачные процессы, ПМ мог лучше контролировать ситуацию, а также обеспечить прозрачность для заказчиков. Введение буферов уменьшило ведущее время. Заказчики в условиях предсказуемой системы стали лучше определять, чей запрос должен попасть в буфер следующим.
  6. По слишком большим или дорогим запросам решение принималось сразу. Если разработчик подтверждал, что он готов выполнить задачу в течение 15 дней или изменения стоят того, то запрос брался в работу вне зависимости от размера или стоимости.
  7. Понаблюдав за потоком в отделе, ПМ пришел к выводу, что структуру штата стоит изменить в пользу разработчиков, которые были больше загружены работой. Изменения проводились в соотношении 2:1: в XIT стали работать 4 разработчика и 2 тестировщика.



По итогу 2005 года производительность отдела выросла на 155%. Чтобы еще улучшить работу XIT, туда привлекли двух сотрудников: одного разработчика и одного тестировщика. Количество запросов в бэклоге снизилось до 10, а один разработчик стал стабильно обрабатывать 11 заявок за квартал. В среднем за квартал завершались 56 запросов против 11 ранее. Стоимость запросов упала с $7500 до $2900.

Применение в компании Corbis

Добившись успеха в Microsoft, Андерсон в 2006 году приступил к решению новой сложной задачи. Теперь он работал в Corbis — другой компании Билла Гейтса, который тогда еще не покинул MS. Одним из видов деятельности Corbis было лицензирование фотографий. На тот момент это был второй крупнейший в мире фотосток с базой около 3,5 тыс. снимков.

Задачей Андерсона было ускорить главные релизы от компании. Интервал между их выходами составлял три месяца и мог вырасти еще больше. Только обсуждение плана релиза отнимало у менеджмента две недели. Требовалось наладить выпуск второстепенных релизов или обновлений каждые две недели. При этом ключевые ресурсы должны были быть направлены на работу над главным проектом.

В офисе Corbis появилась канбан-доска, у которой Андерсон ежедневно беседовал с коллективом. Целью ПМ было улучшить визуальный контроль над процессами, способствовать самоорганизации и большей персональной ответственности исполнителей. Также система канбан была направлена на уменьшение надзора со стороны менеджеров и увеличение производительности.


Кроме разноцветных карточек и графиков, на доске появилась «мусорная корзина» — в нее отправлялись задачи слишком большого размера.


Фото из официальной
A Kanban System for Sustaining Engineering on Software Systems by David J Anderson

Система kanban прояснила, когда поток перестает быть плавными и где возникают задержки, так называемое бутылочное горлышко. Быстрые обсуждения с командой помогали выявить текущие проблемы. Например, тестирование длилось 3 дня, что негативно отражалось на сроке релиза. Трое сотрудников объединились и нашли способ, как уменьшить время до одних суток.

Бутылочное горлышко — участок схемы или алгоритма работы компании, где ограничение ресурсов или продуктивности людей резко сокращает проходимость потока задач. Нехватка рабочих рук, плохой интернет или директор в отпуске блокирует или замедляет выполнение задач.

Лимиты для канбан-карточек дважды устанавливались эмпирическим путем. В колонке «готово для разработки» лимиты были увеличены. Также появилась новая колонка — «готово для тестирования». Многие запросы для нижнего потока были некорректно сформулированы, вызывая лишние затраты времени. Поэтому ПМ исследовал работу верхнего потока и нашел ошибки.

Обработка запросов могла занимать 100 дней, но релизы все равно стали выходить раз в две недели, как и планировалось. Решение по содержимому выпуска принималось за 5 дней до публикации. Практика подсчетов, как и в случае с отделом XIT Microsoft, была отброшена в пользу продуктивности. Приоритет задачам расставлялся согласно «стоимости задержек» или готовности ресурсов.

Канбан система не только помогла добиться Андерсону поставленной цели, но и улучшила настроения в коллективе. Благодаря совместным обсуждениям и наглядности процессов у сотрудников утвердилось доверие друг к другу. Также персонал приобщился к кайзену, то есть практике постоянного улучшения.

Что такое методология kanban и как она позволяет выполнять задачи в поставленные сроки?

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

Минутка истории kanban

Основа идеи kaban была придумана компанией Toyoyta Motors. Производитель автомобилей нес большие потери из-за неправильного распределения запасов и мощностей на производственной линии. Часть этапов производства могла простаивать, а часть была перегружена.

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

Таким образом у каждой детали была карточка, а излишков просто не могло быть. В итоге запасы не росли на участках, а каждый следующий рабочий получал ровно то количество деталей, которое ему было необходимо.

Давайте сформулируем что же такое kanban и перенесем его на разработку интернет продуктов.

Kanban, это система управления бережливыми производством (перевод с японского: «сигнал»/«карточка»), которая использует информационные карточки для передачи заказа на всех этапах изготовления. Простыми словами, мы отслеживаем весь путь продукта, от идеи до выхода “на полку магазина”.

Выше изображена kanban доска. Это основной инструмент отображения статуса по задачам. Главный принцип: мы видим на каком этапе производственного процесса находится та или иная задача. Плюс, отслеживается время на всех участках, то есть всегда можно обнаружить “ ” в системе и поработать с ними.

Количество столбцов вы определяете сами исходя из особенностей своего проекта. Важно, чтобы это были основные этапы, которые проходит ваш продукт. Пример выше, это плюс-минус основные этапы, которые проходит интернет продукт.

Применение методологии весьма широкое. Kanban используют для реализации проектов, управления службой продаж, производственных линий, it-разработки и даже для организации собственной жизни.

Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал . Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

Принципы kanban

  • Визуальное отображение задач. Все задачи должны быть представлены в виде карточек и отражены на доске. Очень важно обновлять статус задач. Например, если разработчики подготовили код и передали в тестирование, то карточка с задачей должна перейти в соответствующий столбец. Таким образом, любой участник команды в любой момент времени может посмотреть на каком этапе находится задача.
  • Ограничение по столбцам WIP (work in progress или работу, выполняемую одновременно) на каждом этапе производства. Чтобы система рано или поздно не “захлебнулась” от потока задач, необходимо устанавливать ограничения. К примеру, на kanban доске выше в столбце Analisis (аналитика) у нас работают 2 человека и они могут обрабатывать не более 2 задач, нет смысла нагружать их больше, так как последующие этапы системы будут простаивать. Ограничение по столбцам подбираются опытным путем.
  • Фокус на невыполненных задачах. Смотря на доску с задачами в первую очередь уделяйте внимание тем задачам, которые “подвисают” в том или ином столбце. Если у вас какой-то из этапов занимает больше всего времени, то попробуйте перераспределить ресурсы или же добавить людей, если есть такая возможность.
  • Постоянное улучшение. Как только вы уравновесите нагрузку в системе, вам будет проще наблюдать за всем процессом в целом. Измеряйте время цикла (сколько задача висит в отдельном столбце, а сколько от момента попадания в To do, до релиза Done). Меняйте нагрузки в системе и сокращайте время на прохождение всех стадий.
  • Уделяйте внимание мелочам. К примеру, если код, который пишут разработчики периодически не проходит тестирование и возвращается на доработку, то возможно, есть варианты улучшить качество разработки, чтобы в тест попадал более качественный продукт?

Подход kanban может показаться идеалистичным, но уверяю вас его принципы приносят результаты. В первую очередь необходимо адаптировать методологию под свою ситуацию, а после шлифовать систему.

Инструменты kanban

Или где вести kanban доску.

  • Excel таблицы
  • Доска со стикерами
  • Еще фантазия…

На самом деле вариантов масса, можно погуглить и набраться вдохновения. Главное, чтобы у вас была эта доска и все участники процесса могли видеть, что происходит с задачами в данный момент.

Примеры kanban досок

Вот доска, которая висит на стене, где каждая задача отражена на стикерах.

Или же это может быть облачный сервис, типа Trello.

Есть ряд мнений по-поводу того, какие же инструменты и варианты использовать в работе, но это по-большей части вкусовщина. Просто попробуйте разные решения и остановитесь на том, которое больше понравится. Суть в том, чтобы начать использовать kanban, а не стопориться на использовании максимально красивой доски.

Мое мнение такое: для мозгового штурма или проработки кейсов в оффлайне хорошо работает обычная доска со стикерами. Но для повседневной работы само собой нужно использовать облачное решение типа Jira, Kanbantool, Trello и прочее. В них вся команда может добавлять комментарии к задачам, двигать их по столбцам и многое другое.

Нюансы/мыли

Если говорить об интернет продуктах, то kanban работает, помогает и улучшает, но есть ряд опасений или же нюансов, которые необходимо учитывать.

  • Скорее всего введение лимитов WIP на столбец может немного напугать управленческий состав проекта. Ведь как определить сколько разработчик или, например тестировщик могут параллельно решать задач? А вдруг мы введем ограничения и они будут попросту прохлаждаться?

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

  • Как утверждают гуру kanaban, система идеально работает в кросс-функциональных командах. Ну что-то вроде того, если тебе нечего делать, иди помоги товарищу по цеху. Правда, чтобы сколотить себе команду, где разработчики могут быть тестировщиками и наоборот, а архитектор системы поможет дизайнеру, нужно будет выложить немалые деньги, да и стоит ли?

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

Поэтому, я больше склоняюсь к оттачиванию своего скила, если уж выдалась спокойная минута. Посмотри, что сделал, подумай, как можно улучшить, почитай полезные статьи. Человек, это живой организм, а не шестеренка в конвеере.

Итого

Мы разобрали методологию kanban и теперь, надеюсь, вы понимаете как ее применить в своем проекте. Попробуйте разделить свои процессы на основные этапы и оптимизировать систему с учетом полученных знаний.