Методология управления проектами Kanban позволяет настроить рабочий процесс и оптимизировать рутинные задачи. Рассмотрим, из каких элементов состоит эта система, как функционирует, что помогает улучшить и чем отличается от альтернативной методики Scrum.
Методология зародилась в конце 1950-х годов в Японии и изначально была системой организации процессов на производстве. Сотрудники, которые выполняли разную работу, наклеивали на общую доску карточки с задачами, которые они планировали выполнить.
Сегодня Kanban чаще упоминается в контексте IT-сферы, где его активно применяют в командах разработки, службе поддержки и контент-менеджменте.
Kanban помогает:
В основе Kanban лежит пять ключевых элементов и принципов, которые позволяют управлять непрерывным рабочим процессом.
Это физическая или виртуальная доска, которая состоит из колонок со статусами задач и карточек с самими задачами. Количество колонок может варьироваться в зависимости от этапов на проекте. Разработчики передвигают карточки по колонкам — как только работа над задачей завершена, карточка переходит в следующую колонку, и так до тех пор, пока не достигнет последнего столбца с выполненными задачами.
В Kanban есть семь каденций:
Ежедневное собрание (англ. Daily Standup, или просто «дейли»). Члены команды озвучивают текущие задачи, ход их выполнения, есть ли трудности и нужна ли помощь коллег.
Обзор рисков (англ. Risk Review). Проводится раз в месяц, на нем команда разбирает допущенные ошибки и планы по их предотвращению в будущем.
Обзор стратегии (англ. Strategy Review). Помогает определить вектор развития проекта, его цели и пути оптимизации рабочих процессов.
Обзор предоставления услуг (англ. Service Delivery Review). Собрание для заказчика проекта, на котором обсуждают результаты работы — укладывается ли команда в сроки, выполнены ли запланированные задачи.
Обзор операций (англ. Operations Review). Ежемесячное собрание руководителей разных команд для обсуждения методов улучшения рабочих процессов.
Планирование запасов (англ. Replenishment Meeting). Еженедельное собрание для сверки статусов задач — команда смотрит на общее число карточек на доске и при необходимости либо добавляет новые, либо перераспределяет текущие.
Планирование поставок (англ. Delivery Planning Meeting). Встречу проводят при передаче команде новых задач. На ней участники оценивают результаты предыдущих проектов и актуализируют приоритеты.
Эти встречи не обязательно проводить по отдельности, их можно объединять в зависимости от особенностей проекта — например, включить в повестку еженедельного собрания и планирование запасов, и актуализацию статусов текущих задач.
Методология Kanban предлагает несколько подходов к работе с доской. Но каждая команда может адаптировать их под себя в зависимости от задач и особенностей рабочего процесса.
Управление лимитами. На количество карточек в каждой колонке можно настроить ограничение. Оно определяется опытным путем на основе показателей метрик. Если количество карточек в одной из колонок превышает установленный лимит, команда временно откладывает новые задачи и направляет свои ресурсы на закрытие карточек из этой колонки.
Приоритетность выполнения задач. Задает очередность взятых в работу карточек. В приоритете те задачи, которые находятся ближе всех к завершению. Например, у автора блога есть в работе несколько статей. Все они находятся на разных этапах — подготовки, редактирования или финальной доработки. В этом случае приоритет будет у текста, который уже на стадии итоговых правок.
Метрики позволяют оценивать эффективность работы над задачами и прогнозировать сроки их выполнения. Они также помогают выявить слабые места в командном взаимодействии и процессы, которые стоит улучшить.
Например, если карточки начинают накапливаться в колонке «На проверке», значит руководитель не успевает давать исполнителям обратную связь. В этом случае лучше делегировать часть работы заместителю или разбить процесс проверки на несколько этапов.
Основные метрики в Kanban:
Время от создания до закрытия задачи. Этот показатель отражает общий срок работы над задачей. Например, сначала карточки помещают в колонку «На очереди». Затем исполнитель берет ее в работу и переносит в статус «В разработке», и так далее. Время с момента создания карточки до ее перемещения в колонку «Готово» показывает общий срок выполнения задачи.
Время активной работы над задачей. Эта метрика показывает, какой срок фактически уделяется решению задачи. Отсчет начинается с момента взятия карточки в работу, когда исполнитель перенес ее из колонки «На очереди».
Пропускная способность. Показывает количество всех завершенных задач за определенный период времени. Например, сколько статей команда опубликовала за неделю. Эта метрика позволяет оценить вклад одной команды в общий результат и определить, нужны ли изменения. Если увеличение количества публикаций приводит к росту поискового трафика и релевантных лидов, компания может принять решение нанять новых авторов и повысить пропускную способность.
Количество незавершенных задач. Метрика позволяет оценить загрузку команды и эффективность рабочего процесса. Если количество задач в работе постоянно растет или превышает лимиты колонки, это указывает на то, что команда не справляется с нагрузкой и нужно пересмотреть лимиты.
Стоимость задержки. Метрика позволяет оценить последствия задержек в выполнении задач. Например, перенос дедлайна по одной задаче повлияет на сроки выполнения остальных или усложнит взаимодействие с заказчиком. Метрики можно анализировать вручную или использовать сторонние инструменты со встроенными отчетами — например, Jira.
Классы обслуживания определяют приоритеты задач и показывают команде, какие карточки из колонок на Kanban-доске нужно брать в работу первыми. Они присваиваются на основе стоимости задержки и могут меняться в процессе выполнения задачи.
Методология Kanban предусматривает четыре класса:
Ускоренный. Сюда попадают задачи с высокой стоимостью задержки — например, со штрафами от заказчика за срыв сроков.
Стандартный. Чем ближе дедлайн, тем выше приоритет задачи. Например, у редактора есть контент-план статей на месяц. При приближении запланированного срока публикации приоритет задачи повышается.
С фиксированной датой. Такие задачи получают повышенный приоритет и стоимость задержки к определенной дате. Например, если команда тестирования не успеет завершить проверку обновлений к установленному дню, работа программистов будет парализована и это сорвет график проекта.
Нематериальный. Этот статус подразумевает отсутствие стоимости задержки, но не отменяет необходимости закрыть задачу. Например, бэклог не срочных, но важных в дальнейшей перспективе вопросов — их можно отложить на время, но в будущем все равно придется выполнить, иначе степень критичности проблемы может возрасти.
И Scrum, и Kanban — гибкие методологии с рядом сходств в принципах взаимодействия. В обеих есть командные встречи и доски с карточками для визуализации задач. Также есть контроль над выполнением задач, но в Scrum он осуществляется через планирование спринта, а в Kanban — через классы обслуживания.
У обоих подходов есть три принципиальных отличия.
Внедрение. Переход на Scrum требует изменения всего процесса работы. Внедрение Kanban более плавное — оно позволяет вносить изменения поэтапно, начиная с текущего процесса.
Сроки выполнения задач. Цикл разработки в Scrum измеряется спринтами — двух- или четырехнедельными отрезками, к концу которых нужно успеть закрыть все запланированные задачи. После этого проводят планирование нового спринта, и так до завершения проекта. В Kanban дедлайн можно предсказать при помощи метрик и классов обслуживания. Например, с вероятностью 95% разработчик закроет задачу с ускоренным классом обслуживания за пять дней, а со стандартным — за десять.
Цели. Scrum подходит для проектов с оперативной обратной связью, в то время как Kanban — для рутинных задач с непрерывным потоком. Scrum эффективен в условиях частых согласований и обязательного фидбэка от заказчика, а Kanban идеален для работы с запросами пользователей или в производстве контента.
Плюсы:
Визуализация рабочего процесса. Kanban-доска с карточками дает наглядную картину хода проекта и оперативно выявляет риски срыва дедлайнов.
Комфортная адаптация команды. Kanban меняет существующие процессы плавно. Команде не приходится резко изменять привычный ход работы, что позволяет избежать простоев при переходе на новую систему.
Большой арсенал метрик. Они показывают, что мешает эффективной работе и позволяют выявить неочевидные причины там, где, как казалось, все функционирует безупречно.
Баланс загрузки команды. Если руководитель видит, что одна из колонок переполнена карточками, он может сразу перераспределить задачи или пересмотреть их приоритет.
Гибкая методология управления позволяет справедливо распределять задачи между членами команды и не допускать перегрузок отдельных специалистов. В этом также помогут различные сервисы для контроля и оптимизации работы сотрудников.
Систему можно настроить индивидуально под каждого сотрудника с учетом занятости и уровня ответственности его задач. Сервис поможет грамотно распределить нагрузку в команде, а также защитит корпоративные данные от утечек.
Минусы:
Сложность планирования. В начале работы с Kanban может быть трудно прогнозировать результаты — для точного расчета сроков необходима настройка и анализ метрик.
Нюансы в общении с заказчиком. Прогнозы Kanban основаны на метриках и классах обслуживания. Это может создать трудности во взаимодействии с заказчиком, который ожидает четких сроков выполнения задачи.
Подходит не для всех команд. Гибкая модель планирования не приживется в компаниях с жесткой отчетностью и фиксированной системой KPI.
Переход на Kanban — это небыстрый процесс, который требует поэтапного внедрения следующих шести шагов:
Создайте Kanban-доску. Определите этапы проекта и создайте для каждого отдельную колонку. Затем заведите карточки под задачи и разместите их в соответствующих столбцах. Можно поставить настоящую доску в офисе или использовать специальные сервисы — например, Kaiten.
Установите лимит на незавершенные задачи. Например, в колонке «В разработке» может быть не более 15 карточек. Менеджер проекта контролирует число открытых задач и не принимает новую доработку от заказчика, пока команда не выполнит более приоритетное задание.
Управляйте процессом. Чтобы обеспечить равномерный и предсказуемый ход проекта, выявите и устраните «узкие места» в процессе разработки. Например, на одном исполнителе может быть слишком много задач, из-за чего он теряет фокус и продуктивность. В этом поможет настройка лимитов и метрик для отслеживания передвижения карточек между колонками.
Объясните правила. Вся команда должна четко понимать принцип настройки лимитов и статусов, роль классов обслуживания и способ их применения. Это обеспечит понимание того, какие задачи брать в первую очередь, а какие можно временно отложить без вреда проекту.
Обеспечьте обратную связь. После того, как процесс будет налажен, а команда усвоит основные правила, можно внедрить регулярные каденции для обсуждения текущих вопросов, стратегии и возможных улучшений.
Оптимизируйте процессы. Пользуйтесь всеми возможностями Kanban — настраивайте и отслеживайте метрики, находите недочеты во внутренних процессах и постепенно совершенствуйте управление проектом.
В Kanban есть еще один полезный инструмент — модель зрелости. Она позволяет оценить, насколько успешно команда внедрила методологию. Сравните текущее положение с выстроенной желаемой моделью — это позволит выявить точки роста, области для улучшения и недостатки в процессах.
Многие организации управляют проектами по методологии Kanban, но не все применяют на практике полный набор функций этого подхода. Kanban позволяет видеть четкую картину хода проекта и своевременно реагировать на возможные сбои в работе. Эта система подойдет командам, которые не ждут мгновенного результата и готовы трудиться на перспективу — методично внедрять правила и метрики, совершенствуя внутренние процессы команды.