Канбан-доска

Задачи, основной метод и принципы работы системы канбан

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

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

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

Основные принципы концепции:

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

Постоянных установок концепция не содержит, эти принципы направляют действия руководителя.

Зачем нужны карточки kanban

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

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

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

Что такое доска kanban

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

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

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

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

Распределение Lead Time

Но самое интересное начинает происходить, когда мы начинаем собирать статистику Lead Time  по рабочим элементам. Тут-то и раскрывается вся сила и мощь Канбан-метода. Мы получаем в свои руки объективные данные, которые однозначно указывают на характеристики и проблемы в рабочем процессе, и диктуют правильные решения. У менеджера появляется козырь при разговоре с руководством, так как его прогнозы по срокам зиждутся на статистических данных, а не ощущениях или «экспертных оценках».

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

На диаграммах ниже собрана статистика по времени выполнения задач (Lead Time) по разным типам работ. Диаграмма «Распределение 1» показывает статистику для задач типа «мелкий дефект», а диаграмма «Распределение 2» — для задач типа «средней сложности дефект».
Такая диаграмма распределения показывает, сколько задач выполнялось за то или иное время. По горизонтальной оси откладывается количество дней, за которые завершилась задача, а по вертикальной оси — количество задач, которые были завершены за то или иное количество дней.

Видно, что в «Распределении 1» разброс значений меньше, и сама диаграмма уже. Это означает, что основная масса задач типа “мелкие дефекты” завершается за 10 дней, и есть лишь редкие задачи этого типа, которые завершаются либо быстрее, либо медленнее.

«Распределение 2» показывает гораздо больший разброс значений, и это означает, что точность предсказания срока выполнения задач типа «средней сложности дефект»  будет ниже, но и тут можно предсказать, что с вероятностью 91% любая задача такого типа будет сделана за 25 дней.

Имея такие данные, можно давать статистически обоснованные обещания, и договариваться об SLA, точность которых будет около 90%. Точность прогноза в 100% требуется редко: в основном, для задач, стоимость задержки которых крайне высока. Точности 80-90% вполне достаточно для обычных задач.

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

Правила эффективного применения системы канбан

Президентом корпорацию Toyota Motor Corporation Тайити Oно предложены следующие правила эффективного применения карточек канбан:

• Каждый последующий рабочий процесс изымает указанное карточкой канбан количество деталей от предшествующего рабочего процесса.
• Расположенный впереди рабочий процесс производит детали в количестве и последовательности в соответствии с указанной карточкой.
• Ни одна деталь не должна быть произведена без карточки. Этим самым обеспечивается сокращение перепроизводства и избыточные перемещения товаров. Находящееся в обороте количество карточек канбан представляет собой объем максимальных запасов.
• Товар всегда пристраивается к карточке. Карточка является своеобразным заказом на изготовление товара.
• Дефектные детали не передаются дальше в последующий рабочий процесс. Результатом является изготовление полностью бездефектных изделий.
• Уменьшение количества карточек повышает их чувствительность. Они вскрывают существующие проблемы и делают возможным контроль запасов.

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

Схема 4. Пример карточки с применяемыми обозначениями.

Больше аналитических и практических материалов на эту тему можно найти в разделе Канбан библиотеки портала.

Источник

Канбан-доска в CRM-системах

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

Более того, в нашей CRM-системе задачи группируются в виде списка: при работе с электронной системой это намного удобнее, чем карточки и графы Канбан-доски

К примеру, на первичном этапе выполнения задачи менеджеру или исполнителю важно «набросать» задания или идеи в виде списка и лишь потом заняться их разбором: какую-то идею, изначально казавшуюся полезной, отбросить, какую-то — поднять наверх и дать задание реализовать ее нужному сотруднику

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

Материалы по теме:

Положительные эффекты от применения системы Канбан

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

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

1. Основная идея Канбана — визуализация каждого процесса работы на доске. Таким образом, доска превращается в центральный информационный центр. Все задачи видны, они не теряются, что придает прозрачность всем этапам работы. Каждый член команды может быстро получить обновленную информацию о состоянии проекта или задачи.
2. Канбан выявляет узкие места в рабочем процессе. Как только доска заполнится карточками, станет видно, что некоторые столбцы переполнены заданиями. Это поможет выявить узкие места рабочего процесса и устранить их.
3. Канбан обеспечивает гибкость. Если вы взглянете на основные принципы методологии, то поймете, что любой отдел компании может их использовать. Основная причина заключается в том, что Канбан принимает текущее состояние организации, не требуя революционных изменений. Напротив, он предполагает, что все нововведения должны быть постепенным, но при этом компания должна стремится к постоянному совершенствованию своих процессов.
4. Команда становится более ответственной. Сотрудники сосредоточатся на завершении текущих задач, а не создании новых, что улучшит взаимодействие и производительность компании.

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

Подробнее об этом можно почитать здесь >>>

Из чего состоит Канбан-доска? Пример.

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

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

Пример доски:

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

По мере того, как делается работа, стикер с задачей двигается по доске слева направо: от инициации работы к ее завершению (колонка «готово»).

Обычно одна колонка соответствует одному этапу. И этих этапов может быть довольно много, что усложняет читаемость информации с доски, и заставляет людей фокусироваться только на понятных им этапах, игнорируя остальные. Гораздо лучше, если колонок будет не очень много — 5-7 — иначе доска получается перегруженной, и использовать ее сложнее. Чтобы упростить доску,можно объединить колонки, в которых над задачей работают одни и те же люди, а конкретные работы указывать на самом стикере в виде чеклиста.

Обратите внимание на колонку со штриховкой посреди доски на фото выше. Это очень важный элемент Канбан-доски — точка принятия обязательств (commitment point)

Все, что слева от этой колонки, находится в состоянии “решаем, делать нам эту задачу, или нет”, а колонки правее находятся в состоянии “решили делать”.

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

В конце доски, перед последним этапом, есть точка “отдачи обязательств”, когда мы говорим, что работу мы сделали, и готовы ее сдать заказчику.

Время прохождения задачи от точки принятия обязательств, до точки отдачи обязательств называется Lead Time, и на основе его статистического распределения можно делать выводы о характеристиках производственного потока, и как мы можем сделать его более эффективным.

Основа системы

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

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

Канбан как составная часть концепции «Бережливое производство»

Центральная идея системы CANBAN была основана на методе управления запасами. Зарождение этого метода приходится на годы правления Кииширо Тойода – сына одного из основателей компании Toyota. При нём возникло одно из ключевых понятий цикла – «точно вовремя». Суть понятия применительно к автопроизводству сводилась к тому, что любая запчасть автомобиля должна изготавливаться не раньше и не позже, чем в ней появится необходимость. Помимо прочего, это означало отказ от объёмных складских запасов, что снижало текущие издержки на изготовление запчастей и содержание складов. По сравнению с американским автопромом, где склады с большими запасами деталей были нормой, такой подход был новаторским.

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

• картирование (изготовление графических карт) потока создания ценности продукта для потребителя,
• вытягивающее поточное производство,
• система 5s и другие.

Процесс создания ценности на Toyota шёл от спроса и нужд потребителей. Всё, что имело для потребителя непосредственную ценность и было востребовано, включалось в производственный цикл. А то, что, например, обеспечивало «спокойствие» производителю (наличие ассортимента деталей), но не относилось к ценностям потребителя – исключалось. Этот же принцип был перенесён на всю цепочку изготовления продукции, только в средине цикла учитывались потребности смежного звена. Так формировался своего рода процесс вытягивания, при котором последующий этап производства брал («вытягивал») из предыдущего ровно столько, сколько нужно.

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

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

Требования системы

Трудности, связанные с достижением абсолютной чёткости и слаженности всех структур, и считаются основной уязвимостью системы CANBAN. Не каждая производственная культура способна обеспечить высокую согласованность между стадиями производства. А это увеличивает риск срыва сроков поставок и реализации продукции. Как пример возросшей сложности можно привести следующую статистику: в 1976 году на заводах Toyota Motors ресурсы возобновлялись 3 раза в день, а 7 лет спустя – каждые несколько минут.

Зато, если принцип CANBAN удаётся реализовать в полном объёме, то производственные запасы снижаются на 50%, а товарные запасы сокращаются на 8%. Кроме того, целевое снижение запасов, одновременно способствует выявлению и решению проблем, существующих на производстве, поскольку накопление запасов даёт возможность скрыть регулярные поломки, производственный брак.

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

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

Вторая часть: общее понимания и диагностика продолжительность ~3 ч.

1. Ещё раз познакомьте команду с инструментом, расскажите кто его создатель (Патрик Ленсиони) и где можно в интересной форме о нём прочитать (одноименный бизнес-роман «5 пороков команды»). Покажите команде треугольник, но пустой 🙂

1. Скажите команде: «Перед тем как приступить к работе с треугольником давайте сведём результаты ваших тестов в единое»
   Это можно сделать на флипчарте, но для скорости и удобства лучше сделать в Excel. Не показывайте команде результаты, вы вернётесь к ним немного позже — сохраните интригу.
   (Excel вы можете найти здесь: https://is.gd/Jz9xXR)

Верните команду к флипчарту с пустым треугольником и начните совместно с ними заполнять и прорабатывать уровни

Так как вы уже ранее встречались с командой и рассказывали про данный треугольник, здесь важно включить участников в совместное «вспоминание»
Спросите: «Помнит ли кто-то, что у нас на первом уровне?» После того, как назвали, запишите в треугольник. Далее спросите: «Есть ли кто-то кто считает, что доверие не важно в команде?» Если такие есть спросите: «Можешь, пожалуйста, рассказать почему?» Не критикуйте и не переубеждайте, просто выслушайте и посмотрите на реакцию других участников

Если участник не готов сказать — это его право. Если вдруг начинается дискуссия аккуратно остановите её и верните команду к цели сессии.

1. Попросите участников команды на стикерах (1 стикер = 1 мысль) написать, что они понимают под фразой «Взаимное недоверие», далее каждый из участников выходит и, озвучивая, клеит свои стикеры. Когда все наклеили свои стикеры, уточните не хотят ли они ещё что-то добавить и если у кого-то возник инсайт, обязательно запишите. Это упражнение повторяем для всех уровней, однако, с небольшим дополнением: уточните не хотят ли участники переместить свои стикеры на другой уровень.

1. Вернитесь с командой к тесту и посмотрите на результаты, которые получились. В первую очередь посмотрите на те пороки, которые набрали 3-5 баллов. Если у команды получилось более одного порока в данном диапазоне начните с самого первого, например, тест показал, что у команды Порок#1 и Порок#3 попали в диапазон 3-5 баллов, начните с Порока#1 и проработайте его до конкретных шагов и первых результатов и только потом переходим к следующему пороку

Для этого шага у вас заранее должен быть подготовлен флипчарт с вопросом «А как это у нас?».
Попросите участников команды на стикерах (в данном случае можно использовать длинные стикеры) написать ответ на вопрос «А как это у нас?»

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

После того, как участники написали и наклеили стикеры попросите их провести кластеризацию и написать название кластеров

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

Чем отличаются Kanban и Scrum

Kanban часто путают или объединяют с гибкой методологией Scrum. Но это не совсем так.

KANBAN	SCRUM
Нет совещаний	Есть совещания
Нужна отправная точка	Не нужна отправная точка
Могут работать узкопрофильные команды	Только кроссфункциональная команда
Последовательные и плавные перемены	Кардинальные перемены
В команде нет разделения на роли	В команде есть разделение на роли

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

В такой ситуации лучше начать с Kanban. Если команда заметит явные улучшения, то после сможет решиться и на Scrum.

Команда уже внедрила Scrum, но хочет продолжать совершенствовать процесс. Тут снова поможет Kanban.

Плюсы и минусы системы

Как и любая другая система управления проектами, kanban имеет свои преимущества и недостатки.

Начнем с сильных сторон:

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

Слабые стороны:

• Внедрение программы возможно только в команды с численностью от 5 человек.
• Не подходит для матричных структур организации предприятия. Работает исключительно на прямом производстве.
• Не подходит для долгосрочных стратегий.
• Система вряд ли сможет прижиться в команде, где сотрудники не ознакомлены с функциями друг друга. Только при таком условии можно легко найти заминки в производстве и быстро их исправить.
• Отсутствие жестких дедлайнов также может быть и минусом. Если продукция должна быть готова строго к определенному времени, система «канбан» может не сработать.

Управление проектами – сложный процесс. Поэтому, выбирая методологию, адаптируйте ее под себя. Прямое следование постулатам, основанным более 60 лет назад на машинном производстве, может в определенный момент привести в тупик. Обдумайте основные правила и усовершенствуйте свою версию управления – и вперед, к покорению новых вершин!

А что насчет ограничений в других колонках?

Колонка «Готово» свободна от лимитов — чем больше работы сделано, тем лучше!

Есть ли смысл накладывать ограничения на колонку «В ожидании», где скапливаются задачи, к которым разработчик еще не приступал, и нужна ли она вообще? Ведь Agile-методологии подразумевают постоянное общение с заказчиком — новые задачи можно получать, когда завершена предыдущая.

И все-таки иметь небольшой «буфер» задач полезно. У них может быть разный приоритет и сложность

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

Но разработчик уже взялся за дизайн, и на Kanban-доске нет места для новой задачи.

Если бы обе задачи висели на доске в графе «В ожидании», разработчик взялся бы сначала за более важную, а незначительные, но объемные правки отложил на свободное время.

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

Петли обратной связи

Выделяют всего 7 канденций в системе:

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

Как это работает

Японское слово Канбан переводится как «карточка», «сигнал» или «бирка». Но как обычные карточки позволяют наладить эффективное управление целой корпорацией?

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

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

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

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

Разве что теперь разноцветные карточки чаще создаются в электронном виде.

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

На сегодня принципы канбана используются во многих сферах и отраслях. Система популярна в ИТ-среде, цифровой сфере и маркетинге, строительстве, HR и СМИ. В целом методика подходит для любого бизнеса, где процесс создания продукта можно разбить на этапы с ясной последовательностью задач (задача внутри одного проекта проходит одни и те же стадии). При этом существует два основных канбана: канбан-метод и производственный канбан.

Канбан-метод придумал американский эксперт в области менеджмента Дэвид Андерсон с целью оптимизации процессов в интеллектуальных профессиях (разработчики, маркетологи, дизайнеры и так далее). Его применяют многие крупные мировые компании: Microsoft, Intel, Hewlett-Packard, Meizu. В России интересные кейсы у Тинькофф Банка, HeadHunter, REG.RU.

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

Экономика образования

Бережливое производство в жизни: как перестать терять время и ресурсы

Существует также распространенное суждение, что метод часто применяют в ИТ, но это не совсем так. Например, в разработке он используется редко, поскольку разработчикам нужно более строгое планирование задач, разделение на спринты в одну или две недели, возможность оценить промежуточные результаты и скорректировать последующие планы.

«В Mail.ru Cloud Solutions используется Scrum. Обе эти методологии относятся к Agile-подходам, но сильно различаются между собой. Канбан позволяет выполнять потоковые работы и оценивать пропускную способность, Scrum — решать новые задачи разной сложности, дробить их на подзадачи, контролировать и корректировать ход работ и скорость выполнения. Поэтому канбан подойдет, например, для call-центра или отдела техподдержки, но не для разработчиков», — рассказывает Мурад Бяшимов, руководитель команды Mail.ru Cloud Solutions.

Кому вообще нужна оценка?

Когда вы фокусируетесь на том, насколько быстро вы можете реализовать историю, и у вас есть возможность измерить лишь этот параметр, оценки теряют свой прежний вес. На самом деле, многие практики Канбан полностью отказались от оценивания. Кто-то до сих пор оценивает истории, а потом использует полученные оценки вместе со временем полного цикла. Электронные таблицы в таком случае могут помочь вам рассчитать среднее время полного цикла для всех историй из прошлого, которые получали такую же оценку. Если вы придерживаетесь подобной практики, разместите справа от вашей Канбан доски табличку с соответствиями эстимейтов и времен полного цикла. Эта табличка будет отличным ответом на вопрос о реальной продолжительности разработки, который наверняка зададут стейкхолдеры сразу после получения эстимейтов: «А когда мы увидим это в версии на продакшне?». Если ваши стейкхолдеры похожи на моих, им не хочется знать, когда они получат эту конкретную функциональность, нет. Они хотят знать, когда получат все это. Я обнаружил, что если я помещаю каждую историю в электронную таблицу, задам каждой истории время начала и время конца, то я смогу получить интересную временную статистику. Например, я могу сказать, сколько в среднем историй выполняет команда за определенный отрезок времени. Если я вижу что в прошлом команда справилась с 22 историями за 3 неделями, то в среднем она выполняет 7.3 историй за неделю. Если у меня в беклоге висят около 100 историй, я смогу обоснованно полагать, что общее время разработки будет около 13/14 недель (100/7.3). Это «вчерашняя погода» для системы Канбан — по крайней мере, я рассчитываю ее так. Если я знаю, что за трехнедельный период было 15 рабочих дней и 5 разработчиков работали по 8 часов в день, то мы получаем 75 человеко-дней. Знание этого позволяет мне рассчитать среднее количество человеко-дней на одну историю: около 3.4 (75/22). Это число достаточно близко к Пи, что дает мне полагать, что оно верно ;). Это число, 3.4, называется фактором загрузки в экстремальном программировании.