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

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

Есть давняя история о том, как много лет назад архитектор построил кампус колледжа. Но вместо того, чтобы на самом деле установить тротуары в кампусе колледжа, он просто посеял повсюду траву. Они открыли кампус. После первого года работы архитектор вернулся и посмотрел на то место, где студенты проложили в траве дорожки. И в этих местах он положил тротуары. В этом разница между организацией работы в соответствии с тем, что говорит вам организационная схема, и организацией работы в соответствии с тем, как люди естественным образом самоорганизуются друг с другом, чтобы выполнять работу наиболее эффективно. Эта "притча" объясняет идею Канбан, который фокусируется на действиях, управляет работой, а не людьми. Что действительно важно, так это то, достигаем ли мы наших целей? Компания хочет, чтобы люди работали вместе и находили новые эффективные способы совместной работы и сотрудничества.

1. Визуализируйте свою работу
2. Тяни работу (не толкай ее)
3. Ограничить незавершенную работу

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

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

Методология визуализируется в виде доски со столбцами. Граница между столбцами — это то, что называется точкой обязательства – point of commitment. Она ясно показывает взаимосвязь между незавершенным производством(WIP) и время выполнения: по мере того, как мы сокращаем WIP, сокращается время выполнения заказов.

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

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

• В столбце «Готово» ничего нет
• Там еще много дел

1. Задачи должны быть четко сформулированы. Любой член команды должен прочитать карточку задачи и не иметь вопросов по задаче, потому что там есть вся информация. Избегайте написания расплывчатых задач! Шаблоны помогают. Они избавят вас от необходимости отвечать на кучу вопросов позже.
2. Общее определение того, что нужно сделать, сделать и сделать. Выясните вместе со своей командой, что означает каждый столбец. Мне нравится «Сделать» как задачи, которые мы еще не начали, «Выполнение» как задачи, над которыми мы работали, и «Выполнено» как задачи, которые мы завершили. Выполнение ≠ задач, которые люди планируют выполнять. Выполнение означает задачи, над которыми есть доказательства того, что над ними работали. Эти определения могут не иметь смысла для вашей команды. Найдите, что делает.
3. Общее определение того, что означает добавление вашего лица на карту. Хорошее значение по умолчанию: лицевая сторона карты означает, что над этой Задачей работает этот человек. Обычно я избегаю нескольких лиц на одной карточке, потому что это часто размывает, кто что делает в этой задаче. Задачи по умолчанию являются совместными, но полезно иметь одного распорядителя, ответственного за продвижение этой работы. Этот управитель может привлекать других, чтобы помочь им по мере необходимости.
4. Согласие команды на самоуправление! Сообщите своей команде, что вы не собираетесь перекладывать на них работу. Предложите им перенести задачи из списка дел в список дел, когда у них появится возможность.

Ограничения по WIP могут быть установлены на всех этапах. Основной вопрос команды: как мы решаем, какой лимит установить?

Если вам нужно с чего-то начать, попробуйте ограничить WIP 2-3 задачами (которые занимают более одного дня) в каждом столбце на вашей доске. Сделайте этот лимит незавершенного производства видимым на вашей доске. А затем следите за тем, перемещается ли больше (или меньше) задач в состояние «Done».

Первое, что вам нужно знать, это то, что лимиты незавершенного производства — это ограничение, а не квота. Если у вас есть столбец с пределом незавершенного производства, равным 10, вы можете иметь 10, и совершенно нормально иметь шесть, но вам просто не нужно 11. Таким образом, предел незавершенного производства может быть меньше, но никогда не может быть превышен.

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

Основная цель ограничения незавершенного производства — завершить работу с достаточно высоким уровнем качества, чтобы увеличить пропускную способность. Смысл лимита WIP в том, чтобы помочь вашей команде сделать больше. Если он этого не делает, то почему? Тот же уровень производительности после использования лимитов WIP может быть признаком того, что лимит WIP слишком высок или слишком низок. Определите, является ли он слишком высоким или слишком низким. Затем отрегулируйте.

Какие узкие места продолжают возникать? Как мы можем устранить эти узкие места в будущем?

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

Важно: вся команда должна понимать, что значит "Done", а также WIP каждой колонки.

Еще примеры интерпретации досок можно посмотреть тут.

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

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

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

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