Ко всем урокам
Click to order
Оформление подписки
Total: 
Для удобства будет подключено автоматическое продление подписки. Его можно отключить в личном кабинете на странице оплаты.
Close
Задать вопрос
Напишите мне, если есть вопросы или предложения
Telegram
WhatsApp
12 неделя
12.4 Kanban
Время усвоения: ~ 1 час
Цель урока
Понять основные практики, необходимые для организации процессов разработки продукта
Kanban

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


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


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



Цель Канбана — визуализировать объем работы и определить оптимальный способ получения желаемого результата. У каждого процесса есть свой поток — шаг или последовательные шаги для предоставления продукта или услуги.

Мы можем свести канбан к трем простым практикам:
  1. Визуализируйте свою работу
  2. Тяни работу (не толкай ее)
  3. Ограничить незавершенную работу
Многие команды делают 1). Такие инструменты, как Trello, Asana и Notion, упрощают работу.
Мало кто делает 2) и 3).

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

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


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

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


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

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

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

Допустим, вы менеджер по продукту и работаете с тремя разработчиками: Урелия, Джон и Нэнси. Вот как сейчас выглядит ваша канбан-доска.

Большинство продакт-менеджеров заметят две вещи:
  • В столбце «Готово» ничего нет
  • Там еще много дел
«Ничего не делается! А у нас еще много дел! Давайте поручим Урелии и Джону больше работы!»

Проблема? Урелии и Джону теперь приходится переключаться между задачами, нарушая их ход. Это может привести к тому, что им потребуется больше времени для завершения работы.
И технически они не «Выполняют» свою новую Задачу — они все еще работают над другой Задачей!
Менеджер по продукту просто хочет видеть больше задач в разделе «Выполнение». Это убеждает их в том, что они «делают успехи».
Но как умный продакт-менеджер вы решаете этого не делать.
Вместо этого вы поощряете свою команду тянуть работу, когда они могут взяться за новую задачу.
Когда Джон и Урелия завершают свою задачу в разделе «Выполнение», они тянут задачу в разделе «Сделать»:


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

Однако «Я никогда не видел, чтобы это работало для новичков»
Да, этот тип рабочего процесса бросит вызов людям, которые не работали таким образом. Но научите их. Ваша работа как менеджера по продукту состоит в том, чтобы создать самоуправляемую команду, а это значит, что вы должны уделять время коучингу!
Скажем, младший член команды заканчивает задачу и не знает, над чем работать дальше. Спросите их: «Какая из этих задач кажется вам достижимой? Какие задачи вы в конечном итоге хотите выполнять самостоятельно?» Вступайте в этот разговор с некоторым представлением о том, над чем они могут работать, но помогите им направить себя к задаче, над которой они могут работать.
Ограничение WIP
Идеи мониторинга и ограничения незавершенного производства (WIP) оказали большое влияние на сообщества Agile, Lean и Kanban. Это пустая трата времени — приоритизировать 300 элементов в бэклоге команды, когда команда выполняет только 10 элементов за итерацию. Введение новых элементов или изменение приоритетов со временем изменит последовательность в вашем бэклоге.

Каждый этап наполним задачами во имя эффективности, однако слишком много незавершенной работы (WIP - work in progress) на одном этапе создает неэффективность. Это создает очереди. Работа стоит в очереди на выполнение.

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

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

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

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


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


На второй день попросите вашу команду подумать над этими вопросами:
Превышали ли мы лимит незавершенного производства?
Каково наше оправдание, когда мы превышаем лимиты незавершенного производства?
Мы произвели больше работы? Или мы по-прежнему производим примерно столько же?

Если ваша команда не превысила лимит незавершенного производства, отлично! Если ваша команда превысила его, помогите ей понять, почему. Часто это может быть признаком согласия на многие запросы от разных заинтересованных сторон. Или, возможно, лимит WIP не виден — мы устанавливаем его и забываем.

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


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


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


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


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

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


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

Выводы

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


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


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


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