Система 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-философии. На этом их сходства заканчиваются. На наш взгляд, у этих методик много, очень много отличий.

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

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

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat!

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

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

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

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