Андреа Фрайреар
В основе Kanban лежит парадокс: ограничивая объем текущей работы, мы становимся более продуктивными. Такой рост продуктивности и делает Kanban одним из наиболее предпочитаемых Agile-фреймворков. Его основная цель - визуализация рабочего процесса команды и повышение эффективности выполнения задач.
Если задуматься, сколько времени мы теряем из-за многозадачности (или, точнее, переключения между задачами, поскольку никто не может быть по-настоящему многозадачным), становится понятно, почему эта методология так полезна.
Как применять Kanban в разработке ПО сформулировал Дэвид Дж. Андерсон в 2013 году в книге «Kanban. Альтернативный путь в Agile». Этот подход приняли с меньшим энтузиазмом, чем Scrum в первые дни развития Agile-разработки. Но для команд, которые страдают от строгости процесса Scrum, Kanban стал хорошей альтернативой.
Происхождение Kanban
Хотя концепция kanban (строчная буква «к») была адаптирована к интеллектуальной работе всего несколько лет назад, она существует уже несколько десятилетий.
Японский термин "kanban" переводится как "сигнальная карточка", метод был первоначально разработан компанией Toyota в 1940-х годах. Следуя опыту продуктовых магазинов, в которых хранится ровно столько продуктов, сколько нужно людям, производственные команды Toyota начали использовать карточки, или kanban, чтобы сигнализировать другим частям производственной линии о том, что им нужно больше деталей.
Использование kanban было частью подхода JIT (точно в срок, Just in Time), который позволял заводам создавать столько деталей, сколько было необходимо в данный момент, и экономить ресурсы, не производя лишних. Эта производственная система заложила основы Lean, поставив цель создать ценность без растраты ресурсов.
Предупреждение непродуктивной деятельности на сборочном конвейере
Допустим, моя работа заключается в установке шин на автомобиль. Расточительством было бы иметь запас из сотен шин, не нужных мне в данное время, сложенных позади меня.
Для команды, которая производит шины, экономически целесообразно производить их точно в срок, чтобы я успел установить их на автомобиль. Поэтому, как только мои запасы достигают оговоренной точки, скажем, десяти шин в наличии, я выставляю карточку «Kanban», чтобы подтолкнуть команду, отвечающую за шины, к действию. На всем сборочном конвейере рабочим на каждом этапе процесса не разрешается выполнять работу, пока они не получат сигнал Kanban от нижестоящего этапа.
При использовании в разработке программного обеспечения и маркетинге физические сигнальные карточки не требуются. Сигналом к началу новой работы служит визуальное количество незавершенной работы в любом конкретном состоянии.
Например, если я отвечаю за редактирование контента в своей маркетинговой команде, то по количеству задач в столбце «Готовность к редактированию» (Edit Ready) я делаю вывод о том, пришло или не пришло время добавить новый проект к своим задачам. (Предполагается, что перед этим количество незавершенных проектов в колонке "Редактирование" (Editing) станет ниже установленного лимита WIP, что позволит мне добавить новые задачи).
Kanban и kanban
Как и Scrum, внедрение Kanban требует наличия приоритетного бэклога работ, из которого команда вытягивает свои задачи.
Владельцы бизнеса и заинтересованные стороны несут ответственность за тщательное ведение этого списка задач и определение приоритетов, поскольку он является единственным источником работы для маркетинговой команды.
Вы наверняка видели Kanban-доски отслеживания, используемые в самых разных командах, но просто наличие бэклога и перемещение работы с одной стороны доски на другую еще не означает, что вы используете Kanban. Андерсон напоминает нам, что «столбцы и карточки по своей сути не являются системами Kanban. Это всего лишь системы визуального контроля. Они позволяют командам визуально наблюдать за незавершенной работой, самоорганизовываться, назначать собственные задачи и перемещать работу из бэклога в завершенные без указаний руководителя проекта или линейного менеджера. Если нет явного ограничения на объем незавершенной работы и нет сигнала для вытягивания новой работы через систему, это не система Kanban».
Таким образом, если вы повесили кучу карточек на стену, это еще не значит, что вы используете Kanban.
На самом деле, многие команды Scrum используют этот тип визуализации для управления своей работой. Главная отличительная черта Kanban - это ограничению количества активных задач, еще называемое незавершенным производством (WIP).
Что дают ограничения WIP
Вместо использования временных рамок для управления своей работой, как это делает команда Scrum, команда Kanban использует ограничения WIP. Каждый столбец с определенным статусом работы имеет максимальный объем задач, которые могут находиться в этом столбце.
Если команда превышает этот предел, в систему попадает непродуктивная деятельность – ожидания, очереди. Этот верхний предел затем становится формализованной частью процесса Kanban.
Производительность команды может быть оптимизирована путем ограничения WIP. Поначалу это кажется нелогичным, но члены команды приступают к новой работе только после завершения предыдущего задания, что позволяет им не перегружаться работой.
Это ограничение является одной из основных практик Kanban. Оно позволяет команде быть эффективной, пластичной и сосредоточенной на рабочем процессе. Но лимиты WIP не постоянны; они варьируются от команды к команде и от одного статуса работы к другому.
Например, ваша команда из 5 человек может иметь лимит WIP 10 в столбце «В работе», что позволяет каждому работать над двумя задачами одновременно. Однако предел для работы, находящейся на проверке, может быть другим, в зависимости от того, сколько времени занимает эта часть рабочего процесса, сколько человек назначено для проверки работы и других факторов.
Регулярно экспериментируйте с лимитами WIP и документируйте результаты, чтобы убедиться, что ваша система Kanban функционирует на максимально возможном уровне.
Пять основных свойств Kanban
Ограничения WIP - наиболее известная характеристика Kanban, но это не все, чем вы можете воспользоваться. Андерсон определяет пять основных черт этого подхода, которые повышают эффективность работы команды:
-
Визуализация рабочего процесса
-
Ограничение количества задач в работе
-
Измерение и управление потоком
-
Понятные политики процессов
-
Использование моделей для поиска возможностей улучшения.
В отличие от Scrum, Kanban не предписывает способ управления работой; он не диктует регулярные встречи и не создает уникальные роли в команде.
Kanban позволяет повысить гибкость существующих рабочих процессов. При этом Kanban предполагает, что у вас уже есть установленный процесс управления работой, и вы хотите постоянно ее совершенствовать. Маркетинговым командам легче внедрить Kanban, чем Scrum, потому что Kanban можно начать использовать сразу же, без расходов на предварительное обучение.
Kanban хорош тем, что вы можете начать с текущих задач. Метод легко указывает на проблемные участки рабочего процесса, на которые можно обратить внимание и улучшить.
Kanban также легко адаптируется к изменяющимся условиям. Две команды, даже в одном подразделении, могут использовать его по-разному. В этом есть смысл: узкие места в рабочем процессе каждой команды свои, поэтому и стратегия совершенствования у каждой команды своя. Для Андерсона такой подход дает больше свободы:
«Kanban дает разрешение на создание индивидуального процесса, оптимизированного под конкретные условия. Kanban дает разрешение думать самостоятельно... У вас есть разрешение попробовать Kanban. У вас есть разрешение изменить свой процесс. У вас есть разрешение быть другим. Ваша ситуация уникальна, и вы заслуживаете того, чтобы разработать уникальное определение процесса, адаптированное и оптимизированное для вашей области деятельности, вашего потока создания ценности, рисков, которыми вы управляете, навыков вашей команды и требований ваших клиентов.»
Если вы новичок в Agility и еще не готовы думать самостоятельно, это может показаться скорее пугающим, чем предоставляющим свободу. В этом случае вы можете начать с внедрения Scrum, прежде чем переходить к Kanban.
Визуализация потока с помощью вашей доски Kanban
Доска Kanban является основным элементом системы Kanban. Доска содержит столбцы, каждый из которых обозначает отдельный этап рабочего процесса (например, To Do, Doing, Done). Карточки в колонках показывают ход выполнения каждой задачи; доска помогает команде визуализировать рабочий процесс и взять на себя обязательства по выполнению нужного объема работы.
Первое правило вашей первой доски Kanban — она должна отражать реальность, а не официальный или идеальный процесс выполнения задачи вашей маркетинговой команды.
Первый шаг — определить начальную и конечную точки для вашей команды. Где вы берете на себя полный контроль над задачей, а где передаете ее другой команде или подразделению? Это начало и конец визуализации рабочего процесса.
Затем заполните то, что происходит в команде между этими двумя точками.
Подумайте о любых важных воротах (gates) в вашем рабочем процессе — согласованиях, проверках, передачах от одного сотрудника другому или релизах — и используйте их для названия столбцов вашей доски. Другой подход заключается в том, чтобы подумать о тех этапах вашего рабочего процесса, которые имеют ограничения по количеству задач — сколько задач можно выполнять одновременно без снижения производительности.
В самом простом случае маркетинговая доска Kanban может начинаться с пяти колонок: Сделать, В работе, Просмотреть, Протестировать и Готово.
Команда разработчиков контента может начать с такой доски:
Создание вашей первой доски Kanban
Возможно, вам будет полезно сначала схематично отобразить поток, не пытаясь вписать его в вертикальные столбцы.
В первые несколько недель в макет доски, скорее всего, будет вноситься множество изменений, поэтому не стремитесь сделать его идеальным с первого раза. Вы можете создавать столько столбцов, сколько вам нужно, и экспериментировать с визуализацией. Используйте формат, который можно легко изменить, например, легко стираемые маркеры и стикеры на доске.
Когда вы убедитесь, что поток отражает поток вашей команды, вы можете создать более постоянную версию на доске или с помощью ПО.
В зависимости от типа работы, которую обычно выполняет ваша команда, полезными могут оказаться столбцы для работы, которая вышла из одного состояния и ожидает перехода в другое. Такие столбцы, называемые буферами, могут помочь некоторым командам визуализировать узкие места. Этот образец доски контент-маркетинга, например, включает колонки для контента, готового к рассмотрению и готового к публикации.
При первой настройке вашей доски Kanban, не будьте слишком строги с ограничениями WIP, которые вы устанавливаете для каждого столбца; сделайте их немного больше, чем вам нужно. На начальном этапе ваш рабочий процесс будет страдать от непостоянства, непродуктивной деятельности и узких мест, и вы не хотите, чтобы эти проблемы помешали внедрению менталитета, основанного на вытягивании.
Доска Kanban отлично подходит для того, чтобы сделать рабочим процесс прозрачным. Когда возможности для улучшения становятся очевидными, вы можете уменьшить лимиты WIP и добавить нужные буферы.
Ежедневные стендапы и after meeting встречи
Ежедневные стендап-совещания являются неотъемлемой частью Kanban, как и в Scrum, но их формат несколько отличается.
Точное отображение на доске Kanban всей текущей работы избавляет членов команды от необходимости ежедневно сообщать о состоянии дел. Вместо этого на собрании обсуждается, как работа протекает (или не протекает) через систему. Фасилитатор перемещается по доске, обычно справа налево, просматривая карточки и, когда возникает необходимость, запрашивая у членов команды обновление статуса или недостающую информацию.
Стендап Kanban фокусируется на заблокированных элементах (статус, обозначенный на карточке флажком) или на карточках, статус которых не менялся в течение нескольких дней.
Такой концентрированный стиль стендапа является одной из причин того, что команды Kanban могут быть значительно больше, чем команды Scrum. Команды численностью до 50 человек могут проводить такие стендапы менее чем за 15 минут, что невозможно при использовании формата стендапа Scrum.
Многие команды Kanban также участвуют в так называемом After Meeting мероприятии - неформальном собрании членов команды, которые работают вместе над своими собственными проектами.
Андерсон сообщает, что эта церемония «возникла как спонтанное поведение, потому что члены команды хотели обсудить то, что у них на уме: причины блокировки задач, вопрос технического дизайна или архитектуры, но чаще всего - вопрос, связанный с процессом». В результате эти встречи обычно становятся местом генерирования инноваций и идей по улучшению процесса.
Пополнение очереди Kanban
Вместо ревью и ретроспектив команды Kanban используют собрания по пополнению очереди для поддержания приоритетов и уточнения бэклога. Они должны проводиться через регулярные промежутки времени, но их ритмичность или каденция не должна быть привязана к какому-либо другому циклу Kanban.
Даже если вы выпускаете новый контент каждую неделю, пополнение очереди может происходить только раз в месяц. Какие бы сроки вы ни выбрали, убедитесь, что они последовательны, потому что «стабильная периодичность пополнения очереди снижает координационные затраты на проведение собрания и обеспечивает определенность и надежность отношений между бизнесом» и маркетинговой командой.
По возможности включайте в состав участников совещания по пополнению очереди широкий круг лиц, принимающих решения, начиная с самых старших менеджеров.
Эти участники часто могут предоставить больше информации о контексте и принять решения, которые участники более низкого уровня должны были бы отложить. Цель состоит в том, чтобы создать бэклог, на основе которого команда маркетинга сможет работать с максимальной уверенностью, поэтому вам нужны участники, которые смогут сделать это во время встречи.
6 шагов для успешного использования Kanban
Если вы выберете Kanban в качестве своей первой методологии Agile-маркетинга, помните, что «суть начала работы с Kanban заключается в том, чтобы изменить как можно меньше», и что нужно составить карту существующих процессов и потока создания ценности, прежде чем приступать к постоянным улучшениям.
Этот рецепт успеха принадлежит Дэвиду Андерсону, который разработал его на основе своего опыта в качестве нового менеджера, входящего в существующую команду. Эти шаги подойдут и для маркетинговых команд, желающих использовать эту методологию.
-
Сосредоточьтесь на качестве: Андерсон в первую очередь сосредоточился на этом шаге, чтобы сократить количество времени, которое команда разработчиков тратит на устранение дефектов ПО; маркетологам тоже стоит начать с этого. Если вы не будете стремиться к максимально возможному качеству маркетинговой работы, не имеет значения, сможете ли вы повысить свою производительность.
-
Сократите объем незавершенного производства или задач в работе: существует прямая зависимость между снижением ограничения WIP и повышением качества, поэтому этот второй шаг должен быть реализован вместе с шагом 1 или сразу после него. Сокращение объема работы, которую команда и ее члены выполняют в какой-то момент времени, уменьшает время, необходимое для завершения работы, и повышает ее качество. Держите WIP на как можно более низком уровне.
-
Доставляйте (выпускайте) часто: частые выпуски контента, электронных писем, постов в социальных сетях и практически любых других маркетинговых материалов, о которых вы только можете подумать, укрепляют доверие аудитории и заинтересованных сторон. Они также увеличивают количество возможностей обучения для вашей Agile-команды.
-
Баланс между спросом и пропускной способностью: на этом этапе вы сосредотачиваетесь на определении скорости включения новых задач в маркетинговый бэклог, которая соответствует скорости, с которой вы можете обеспечить высокое качество маркетинговой работы. Это эффективно ограничивает WIP для вашего бэклога, и это означает, что обсуждение приоритетов и обязательств по завершению новой работы может происходить только после того, как какие-то работы были выпущены. Такой баланс приводит к неполной загрузке команды; только те, кто работает в узких местах, постоянно заняты, но даже им нельзя давать повода чувствовать себя перегруженными. Неполная загруженность - это мощный инструмент, поскольку он позволяет членам команды сосредоточиться на точном и качественном выполнении своей работы и дает им время для того, чтобы нацелить себя на улучшение команды и ее рабочего процесса. Этот шаг может быть трудным, потому что мы, как правило, хотим оптимизировать рабочий процесс, чтобы использовать свободное время каждого; но непрерывное совершенствование Kanban требует от системы некоторого ослабления рабочей нагрузки на сотрудников, которое может быть достигнута только путем нахождения баланса между спросом и производительностью.
-
Расставляйте приоритеты: когда в вашей команде нет предсказуемости, расстановка приоритетов не имеет большого значения, поэтому она стоит 5 шагом. Но когда высококачественная работа выходит стабильно, а у команды появляется свободное время, руководство может начать следить за тем, чтобы выполнялась самая ценная работа. Кроме того, для маркетинговых команд, которым не хватает политического влияния в организации, укрепление доверия путем демонстрации улучшенного рабочего процесса может предшествовать любым попыткам изменить стратегию или приоритеты.
-
Устранение источников изменчивости для улучшения предсказуемости: изменчивость нежелательна, так как она приводит к увеличению количества WIP и удлинению циклов выпуска продукции. Но понимание ее влияния и способы ее уменьшения - это сложные темы. Когда вы достигнете высокого уровня зрелости Agile, вы сможете приступить к этому последнему шагу, экспериментируя с существующими политиками процесса.
Поиск Agile-подхода, который наиболее подходит для вашей команды
Команды, которые плохо воспринимают строгость Scrum, могут найти свободу в системе Kanban. Те, кому нужен буфер между исполнителями и высшим руководством, могут найти его в виде скрам-мастера и владельца продукта.
Для команд, совершенно не привыкших к agile-методологиям, ритуалы и постоянство Scrum могут дать им чувство безопасности. Kanban чаще всего применяется, когда Scrum начинает давать сбои, и поэтому для некоторых команд может стать хорошей второй итерацией agile-маркетинга.
Главное — не пытайтесь заставить свою команду маркетологов перейти на систему, которая им не подходит.
Agile — это постоянное совершенствование, и это касается как ваших процессов, так и ваших продуктов.