Система Kanban: доски, принципы и возможности управления

Kanban помогает управлять командой и соблюдать дедлайны

Представьте, что для запуска проекта вам нужно собрать команду спецов. У вас есть ТЗ на 100 (а лучше — на 200 страниц), упрямый заказчик и сроки. ОЧЕНЬ ЖЕСТКИЕ СРОКИ. Как организовать работу, чтобы все успеть, а заказчик сказал спасибо?

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

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

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

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

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

Фундамент современного канбана — Agile-философия. Это 4 ценности.

То есть канбан — это философия, метод, принцип, если угодно — стандарт или модель управления. Полезная и эффективная.

Тут многие спросят: о чем речь? Какая философия — бизнес-коуч на семинаре рассказывал про доски и карточки.

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

Вообще, канбан — это японский термин. Его 50-х придумали на заводе Toyota. С 1962 года на канбан как на принцип организации производства и снабжения перевели все предприятие. Вот в чем суть.

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

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

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

Современный канбан имеет мало общего с промышленностью — он перекочевал в офисы. Но от японцев этот принцип перенял самое полезное — наглядность задач и процессов.

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

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

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

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

В современном канбан смешались принципы гибкой (Agile) и бережливой (Lean) разработки. Сегодня здесь нет строгих правил, но есть принципы — на них должны опираться все члены команды.

• Оптимизация и совершенствование. Разработка базируется на существующих методах и начинается строго по плану. Но в процессе приветствуются изменения, улучшающие процесс. Рекомендуется не допускать резких разворотов — приветствуются короткие, но эволюционные перемены
• Уважение. К ролям в команде, к обязанностям каждого члена, к сложившемуся порядку взаимодействия
• Инициатива. Ее надлежит поощрять. Каждый, кто проявляет инициативу, привносит в процесс разработки улучшающие изменения и работает лучше других, заслуживает на поощрение
• Мотивация. Члены команды — это не просто ресурс. Им нужно дать больше, чем просто задания
• Простота. Команда должна исключать из задач лишнюю работу. Важно только то, что приносит результат
• Скорость. Команда должна как можно чаще выпускать функционирующий продукт — это показатель прогресса. Для этого разработка ведется короткими итерациями
• Минимизация потерь. Потери — это все, что не несет ценности для конечного пользователя. Лишние функции, медленная коммуникация, бюрократия — команда работает над тем, чтобы это исключить

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

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

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

У канбан как у философии и инструмента управления есть масса преимуществ. Подумайте, как они могли бы улучшить работу вашей команды.

Гибкость планирования

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

Сокращение времени цикла

Канбан — это приоритет обучения. Все члены команды работают над однообразными задачами. При этом они делятся знаниями и навыками — так обеспечивается приоритет обучения в команде. За счет обмена опытом уровень команды автоматически повышается — цикл разработки сокращается.

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

Меньше узких мест

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

Наглядность

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

Непрерывная поставка

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

К сожалению, как инструмент, канбан не безупречен. Мы в Oko выделяем 4 главных недостатка, которые ограничивают применение этой философии при разработке ПО.

• Проблемы с продуктовыми командами. Канбан неэффективен в командах, которые разрабатывают онлайн-продукты. Это обусловлено тремя его следующими недостатками
• Только для маленьких команд. Канбан требует максимальной вовлеченности разработчиков в процесс, взаимного уважения, взаимопомощи и поддержки. Как Д'артаньян и три мушкетера. Если мушкетеров было бы восемь или двенадцать, среди них обязательно нашелся бы свой кардинал Ришелье. В общем, система хорошо работает для команд до 6 человек: 5 разработчиков + менеджер
• Только для узких, монопрофильных команд. Канбан не подойдет для кросс-платформенных команд, где есть разные роли и исполнители отвечают только за свои зоны и участки. Канбан — это коллективная ответственность за весь поток задач
• Не подходит для долгосрочного планирования. Так сложилось исторически. Канбан — это философия для краткосрочной разработки. Даже если не применять итерации, система требует конкретного, достижимого и осязаемого результата точно и в срок. Без дальновидных планов и прогнозов

Любой проект состоит из набора процессов и задач. Первый этап работы с этими процессами по логике канбан — их описание и анализ. А затем — разбивка на этапы реализации. Например, в Oko разработка любого онлайнового продукта обычно состоит из таких этапов.

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

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

На одной доске можно вести сразу несколько проектов. Просто используйте разные стикеры: 1 цвет — 1 проект. 

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

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

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

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

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

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

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

Основные отличия от канбан мы отразили в таблице.

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

Возможно, вам и вашей команде вообще не нужно постигать философию японских инженеров Toyota. Для постановки и решения проектных задач многим достаточно одной лишь доски канбан. Такая, кстати, есть в OkoCRM — очень удобно. А если понравится — познакомьте команду с общими принципами канбан. Они полезны, когда группе людей нужно точно и в срок дать позитивный результат. И не важно, это разработка ПО или запуск на рынок нового шампуня. Канбан полезен в любой сфере и для любой проектной команды.

Что нужно запомнить:

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