Kanban доска примеры использования

Обновлено: 04.05.2024

Многие считают, что цель Kanban-доски для руководителя проста — видеть, в каком статусе находится каждая задача и чем занимается каждый сотрудник. На самом деле все сложнее. И основная ценность доски — отнюдь не контроль сотрудников, а анализ рабочего процесса «в целом» и поиск точек для улучшения. Посмотрим на примерах, что скрывается за Канбан-доской и как ее использовать.

Если поискать в Google ответ на вопрос “Что такое Kanban-доска?”, то можно получить следующие ответы:

“один из инструментов, который может использоваться при внедрении метода управления разработкой «Канбан»”;
“это инструмент управления Agile-проектами”;
“это инструмент для совместной работы над проектами”;
и т.д.

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

Чтобы разобраться, начнем с того, что Канбан-метод (Kanban Method) — это один из подходов к менеджменту. Он помогает руководителям принимать верные управленческие решения на основе полной рабочей картины происходящего во вверенном ему подразделении. Для этого нужно визуализировать весь рабочий процесс, и Канбан-доска — это инструмент визуализации.

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

Из чего состоит Канбан-доска? Пример.

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

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

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

По мере того, как делается работа, стикер с задачей двигается по доске слева направо: от инициации работы к ее завершению (колонка «готово»).

Обычно одна колонка соответствует одному этапу. И этих этапов может быть довольно много, что усложняет читаемость информации с доски, и заставляет людей фокусироваться только на понятных им этапах, игнорируя остальные. Гораздо лучше, если колонок будет не очень много — 5-7 — иначе доска получается перегруженной, и использовать ее сложнее. Чтобы упростить доску,можно объединить колонки, в которых над задачей работают одни и те же люди, а конкретные работы указывать на самом стикере в виде чеклиста.

Обратите внимание на колонку со штриховкой посреди доски на фото выше. Это очень важный элемент Канбан-доски — точка принятия обязательств (commitment point). Все, что слева от этой колонки, находится в состоянии “решаем, делать нам эту задачу, или нет”, а колонки правее находятся в состоянии “решили делать”.

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

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

В конце доски, перед последним этапом, есть точка “отдачи обязательств”, когда мы говорим, что работу мы сделали, и готовы ее сдать заказчику.

Время прохождения задачи от точки принятия обязательств, до точки отдачи обязательств называется Lead Time, и на основе его статистического распределения можно делать выводы о характеристиках производственного потока, и как мы можем сделать его более эффективным.

Рабочий элемент

Если колонки обозначают те или иные работы, то как назвать то, что перемещается между колонками? Это не может быть задача на какую-то часть работы, вроде “анализ требований” или “проверка результата”, потому что все этапы работы уже отражены в виде колонок.

По доске двигается бизнес-задача, или “рабочий элемент” в терминах Канбан-метода. То есть, стикер на доске содержит в себе понятное для бизнеса описание задачи, с конкретной ценностью. Например «Новый механизм авторизации на сайте» или «Коммерческое предложение»

Вот возможный дизайн стикера:

На стикере отображается все необходимое, чтобы легко можно было понять в чем суть бизнес-задачи, к какому проекту (эпику) она относится, текущий прогресс по ней (выполненные подзадачи в виде прогресс-бара), кто в данный момент ее делает, и состав обязательных, повторяющихся работ (чеклист внизу стикера).

Вы вольны добавлять на стикер другие блоки с информацией, которые могут вам сразу разобраться, в чем суть задачи, кто ею занимается, какие есть зависимости, и из каких обязательных работ она состоит.

Чем на самом деле является Канбан-доска?

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

Чтобы объяснить, почему это так, немного погрузимся в историю. Идея визуализации рабочего процесса, и управления его характеристиками возникла в 50-х годах XX века в компании Тойота. Она пыталась выиграть конкурентную борьбу за авторынок Японии, в условиях очень ограниченного спроса.

Перед менеджерами стояла задача: повысить эффективность рабочих процессов не увеличивая имеющиеся ресурсы. Они решили подойти к этому вопросу системно, и составили карту производственного потока (Value Stream Map), которая отражала путь деталей и сырья от одного производственного процесса к другому, и так до момента отгрузки клиенту. Выглядела она сложно и научно:

Что они искали на этой схеме рабочего процесса? Потери времени.
Желтенькие треугольники на этой схеме обозначают запасы деталей или сырья, которые копятся перед тем или иным производственным этапом. Почему появляется эта гора запасов? Потому что предыдущий этап работает быстрее, и следующий за ним не поспевает синхронно использовать поступившее сырье или детали.

Хорошо это или плохо? C одной стороны, это гарантия отсутствия простоя на всех участках. Всегда есть что обрабатывать, и каждый участок занят на 100% рабочего времени. Вроде так и надо? Вроде бы в этом и состоит задача менеджера — сделать так, чтобы все были при деле и работали на 100%. Верно?

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

Целостный взгляд и анализ эффективности

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

Оказалось, что загрузка каждого участка на 100% может не ускорить, а замедлить выпуск конечной продукции, или даже сделать его экономически невыгодным.
Все дело в этих самых запасах, которые копятся перед производственными участками. Если представить эти горки запасов как очереди, в которых надо “отстоять” детали прежде чем она будет обработана, то получается, что чем длиннее очередь деталей перед каждым этапом, тем дольше отдельно взятая деталь будет двигаться по конвейеру.

Парадоксально, но факт.

Чтобы детали быстро “пролетали” по конвейеру, нужно сперва “выровнять” производственный поток, чтобы задержки между этапами были минимальными, то есть сократить «очереди» на каждом этапе. При таком подходе требование, чтобы каждый этап был загружен на 100%, отходит на второй план.

А чтобы выровнять весь производственный поток, надо увидеть всю картинку целиком и использовать системное мышление.

Именно это и сделали менеджеры Тойота. С помощью карт производственного потока (Value Stream Map), они проанализировали текущий рабочий процесс, нашли в нем “заторы”, перегрузку, простои и другие дисфункции, и придумывали решения, как их устранить.

Таким образом, Value Stream Map — это инструмент анализа и рефлексии, а не контроля. Запомним этот факт, потому что именно из идеи визуализации Value Stream возникла идея Канбан-доски.

Канбан в нематериальном производстве

Много позже идеи компании Тойота попытались приспособить к нематериальному производству и сфере услуг. В отличие от завода Тойота, где детали и сырье можно потрогать и посчитать, в нематериальном производстве или сфере услуг ничего этого нет.

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

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

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

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

Использование Канбан-доски

Давай разберемся, какую полезную информацию можно извлечь из такой визуализации.

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

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

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

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

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

Логика очень простая:

Задача находится ближе всего к колонке “готово”, то есть еще немного, и мы ее можем завершить, и получить пользу (прибыль, новых клиентов и тд и т.п.);
Задача находится выше остальных по шкале “ценность”.

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

В Канбан-методе это описывается фразой: “перестаньте начинать [новые задачи], начните завершать [задачи которые уже в работе]”.

Чем еще может быть полезна Канбан-доска?

На этой картинке явно видно, что одному сотруднику явно нужна помощь, он слишком перегружен, и что другой сотрудник недогружен.

Что дальше делать с доской

Рассмотренный нами пример Канбан-доски еще далек от совершенства. В дальнейшем на этой доске можно наглядно отобразить:

разные типы рабочих элементов;
ограничения на загрузку (WIP-лимиты);
разные классы обслуживания задач, с точки зрения «стоимости задержки» (cost of delay);

А также учесть специфику работы на разных этапах (повторяющиеся работы или нет; есть ли опциональные работы и т.д.), учесть правила перехода рабочих элементов от этапа к этапу и много чего еще.

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

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

Распределение Lead Time

Но самое интересное начинает происходить, когда мы начинаем собирать статистику Lead Time по рабочим элементам. Тут-то и раскрывается вся сила и мощь Канбан-метода. Мы получаем в свои руки объективные данные, которые однозначно указывают на характеристики и проблемы в рабочем процессе, и диктуют правильные решения. У менеджера появляется козырь при разговоре с руководством, так как его прогнозы по срокам зиждутся на статистических данных, а не ощущениях или «экспертных оценках».

Собрав нужные данные, менеджер сможет с вероятностью 80-90% предсказывать точный срок завершения той или иной задачи. И это будет не гадание на кофейной гуще, а научно обоснованный подход к проблеме.

На диаграммах ниже собрана статистика по времени выполнения задач (Lead Time) по разным типам работ. Диаграмма «Распределение 1» показывает статистику для задач типа «мелкий дефект», а диаграмма «Распределение 2» — для задач типа «средней сложности дефект».

Такая диаграмма распределения показывает, сколько задач выполнялось за то или иное время. По горизонтальной оси откладывается количество дней, за которые завершилась задача, а по вертикальной оси — количество задач, которые были завершены за то или иное количество дней.

Видно, что в «Распределении 1» разброс значений меньше, и сама диаграмма уже. Это означает, что основная масса задач типа “мелкие дефекты” завершается за 10 дней, и есть лишь редкие задачи этого типа, которые завершаются либо быстрее, либо медленнее.

«Распределение 2» показывает гораздо больший разброс значений, и это означает, что точность предсказания срока выполнения задач типа «средней сложности дефект» будет ниже, но и тут можно предсказать, что с вероятностью 91% любая задача такого типа будет сделана за 25 дней.

Имея такие данные, можно давать статистически обоснованные обещания, и договариваться об SLA, точность которых будет около 90%. Точность прогноза в 100% требуется редко: в основном, для задач, стоимость задержки которых крайне высока. Точности 80-90% вполне достаточно для обычных задач.

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

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

Kanban-доска — отличное решение. Этот инструмент для совместной работы над проектами широко используется в разработке ПО, маркетинге, строительстве, логистике и в любых решениях, где присутствует постоянный поток задач. Kanban-подход помогает командам визуализировать рабочие процессы, грамотно анализировать их и повышать эффективность управления задачами. Этот пост мы посвящаем самым актуальным в 2019 году онлайн инструментам, ориентированным на Kanban. Сравните их и выберите самый подходящий.

Но прежде, чем рассмотреть лучшие программные решения с Kanban досками, стоит узнать, для чего они вообще нужны.

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

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

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

Эффективный Kanban-инструмент поможет управлять Agile-разработкой с помощью удобных досок и карточек, потока действий, функций Swimlanes и WIP limits, диаграмм и таймлайнов — всего, что помогает качественно визуализировать управление рабочими процессами.

Что включает в себя мощное Канбан ПО

На первый взгляд, система Канбан может показаться сложной и не всегда применимой. Но настоящая сила Kanban в том, что, как только команда начинает применять его принципы, то сразу может оптимизировать и стандартизировать рабочие процессы.

Тем не менее, существуют решения, которые выполняют работу лучше и эффективнее других. Рассмотрим главные критерии для поиска лучшего Канбан-инструмента:

Kanban доска — система, которая предназначена для организации карточек с задачами с помощью горизонтальных колонок (Swimlanes), ограничений (WIP limits), сабколонок, а также стандартного набора колонок («To-do», «In Progress» и «Done»).
Kanban карточка — элемент системы Канбан, который назначает задачи при помощью чек-листов и вложений. Карточки позволяют связывать задачи, добавлять иерархию и назначать необходимые ресурсы.
Аналитика — система, позволяющая создавать отчеты.
Интеграция — способность инструмента легко интегрироваться с другими системами управления проектами.
Автоматизация — возможность настроить рабочий процесс в соответствии с условиями вашего проекта.

Лучшие Канбан инструменты для управления проектами

У вас, по сути, есть два пути:

Не заморачиваться и бездумно зарегистрироваться в проверенные и пресловутые JIRA или Trello.
Потратить немного времени на изучение новой волны крутого ПО по управлению проектами, ориентированного на Kanban, с целью отбора самого подходящего софта для ваших нужд.

ПО	Лучше всего для
JIRA	Для разработки программного обеспечения Agile-командами. Не лучший вариант для нетехнических команд и процессов вне системы Agile. Идеальный вариант – для IT компаний с большим штатом разработчиков.
Trello	Для частного и командного использования в разных областях (маркетинг, продажи, HR, и т.д.) которым необходим функционал Kanban. Не лучший вариант для Agile-разработчиков. Идеальный вариант – индивидуальное использование Канбан-досок.
Hygger	Преимущественно для Agile-команд разработчиков. Поддерживает Kanban и Scrum, estimations, Burndowns, Swimlanes и WIP limits. Предлагает качественную приоритизацию бэклога. Идеальный случай – любая Agile-ориентированная команда.
MeisterTask	Для тех же потребностей, что и Trello, но с улучшенной интеграцией с MindMeister.
Favro	Для мелких и средних команд разработчиков. Поддерживает Kanban и Scrum процессы.
Asana	Для персонального использования и для небольших команд, которым преимущественно нужны to-do листы и базовый функционал Канбан доски.
Kanbanchi	Для персонального использования Канбан досок с тесной интеграцией с G Suite.
Paymo	Для агентств и команд, которым нужно автоматически отслеживать время, приоритизировать задачи и следить за рабочим временем.
Breeze	Для команд, которым нужна усовершенствованная версия Basecamp с базовым Kanban-функционалом.
Blossom	Лучше всего для распределенных команд. Минималистичный инструмент для управления проектами, построенный на основе Kanban-досок.
ProofHub	Для команд, которым необходимо полноценное решение с Kanban-досками, диаграммами Ганта, календарем, заметками, обсуждениями, листами задач. Это своеобразный Basecamp «на стероидах».
ZenHub	Это плагин для GitHub, который добавляет поддержку Multi-repo Boards, Epics, индивидуальных рабочих пространств и улучшенный репортинг.
Taiga	Опен-соурс программа для разработчиков, которым нужно проверять задачи и пользоваться стандартным набором для управления проектами.
Leankit	Для создания кастомизированных досок с детальным потоком задач.

Описывая JIRA, часто употребляют слова «мощная» и «мультифункциональная». Это действительно популярный универсальный РМ софт, который позволяет командам разработчиков планировать задачи, назначать исполнителей, работать со спринтами, устанавливать приоритеты и сроки и многое другое.

JIRA предоставляет большое количество настроек фильтрации, удобную визуализацию, подробные отчеты и удобный трекер времени.

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

Trello

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

Сомнения: Trello не имеет своего собственного учета времени, поэтому вам придется платить за другое программное обеспечение (например, Everhour или Toggle). Кроме того, в Trello нет функций WIP limits, Swimlanes и диаграмм Burndown.

Hygger

Hygger — яркий представитель нового поколения PM-инструментов, который отлично подходит продуктовым компаниям, стартапам и организациям средних размеров. Сервис предоставляет удобные to-do листы с кастомными полями, Канбан досками, функциями Swimlanes, WIP limits и Timelines.

Достоинством сервиса является возможность приоритизировать функции, идеи или задачи, используя различные методы приоритизации. Этот фактор часто является решающим при выборе Hygger vs Trello. Кстати, если вы знакомы с функционалом Trello, то быстро освоиться в Hygger не составит труда, потому что платформа имеет похожий интерфейс.

Hygger предлагает определять приоритеты с помощью простых методов (Eisenhower matrix, Value vs Effort, Value vs Risk), а также продвинутых техник (ICE и RICE, Weighted Scoring).

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

Asana

Asana – не менее популярный сервис с доступными iOS и Android приложениями, который хорош в управлении задачами, отслеживании дедлайнов и постановке приоритетов. Asana позволяет качественно следить за статусом выполнения задач и статусом проекта в целом.

Сервис чаще всего выбирают для личного пользования и работы небольших команд, которых в первую очередь нужны to-do листы и базовая Канбан-доска.

Сомнения: Платформа вряд ли будет полезна маркетинговым и креативным агентствам или сервис-компаниям.

Favro

Favro предоставляет инновационное решение для управления проектами, более всего подходящее для разработчиков, маркетологов и руководителей, которые планируют, отслеживают и развивают свои идеи. Favro предлагает встроенную поддержку Kanban и Scrum досок с панелями управления, масштабируемыми бэклагами и отчетами.

Функция Breakdown в Favro помогает разбить ваши проекты на различные задачи. Инструмент интегрирован с Google Drive и Dropbox, что позволяет прикреплять файлы к доске планирования.

Сомнения: Управление досками не так просто, как может показаться. Не все функции ПО могут быть использованы в полной мере: лучше меньше фич, но более качественная работа сервиса.

MeisterTask

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

Канбан доски MeisterTask помогают пользователям просматривать и управлять текущими действиями и активными проектами, создавать планы проектов и сотрудничать с членами команды. Платформа предлагает интеграцию с GitHub, DropBox, Zendesk и Bitbucket.

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

Kanbanchi

Kanbanchi – еще одно подходящее решение, если вам нужно программное обеспечение для управления задачами и совместной работы с досками Kanban, диаграммами Ганта и системой учета времени.

Вы легко визуализируете рабочие процессы всех задач и действий с помощью удобных досок проектов со списками и карточками. Инструмент предназначен для G Suite. Вы должны зарегистрироваться в учетной записи Google, управлять досками в виде файлов на Google диске, помещать даты в Google календарь и т. Д. Приложение отлично подходит для работы отделов компании, потому как каждый член команды знает, над чем он работает.

Сомнения: Нет мобильной версии и некоторых важных интеграций, нет возможности группировать карты вместе.

Paymo

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

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

Breeze

Еще одно отличное решение для управления клиентскими проектами с помощью досок Kanban. Breeze подойдет малому бизнесу и фрилансерам, которым нужно все четко и быстро организовывать и отслеживать.

Инструмент основан на принципах Agile и Lean и включает в себя следующие основные функции: списки задач, отслеживание времени, бюджетирование проекта, отчетность, календарь, экспорт данных, неограниченное количество пользователей, поддержка Android и iOS, интеграция с Google Drive и Dropbox, и т.п.

Сомнения: Малое количество инструментов, с которыми Breeze может быть интегрирован.

Blossom

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

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

Сомнения: Нет бесплатного плана для личного использования. Интеграционные возможности — только отправление обновлений на канал Slack.

ProofHub

Известные бренды, выбравшие ProofHub, по достоинству оценили это программное обеспечение для управления облачными проектами, которое помогает им легко управлять сроками и результатами.

ProofHub предлагает расширенные функции и ценовые пакеты в соответствии с требованиями различных компаний, а также приложения для iOS и Android, что позволяет пользователям работать более продуктивно. Среди ключевых функций выделим списки задач, календари, обсуждения, диаграммы Ганта, удобные расписания и т. д.

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

ZenHub

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

Инструмент можно использовать для организации, планирования и запуска спринтов. Нет необходимости в специальном обучении — ZenHub широко используется как командой разработчиков, так и продуктовиками. Основными функциями являются Kanban-доски, списки дел, графики Burndown, оценки времени, интеграция со Slack и др.

Сомнения: Zenhub не предоставляет достаточно аналитических и отчетных функций. В UX есть некоторые «причуды», которые могут периодически отвлекать и беспокоить.

Taiga

Taiga — выбор разработчиков, менеджеров проектов, дизайнеров и других практиков Agile-методологии. Облачная платформа включает в себя совместную работу над проектом, управление задачами, отслеживание ошибок, отчетность и систему учета времени. Выбирая инструмент, вы также получаете настраиваемые доски Kanban и бэклоги.

Сервис можно легко интегрировать с GitHub, GitLab, Webhooks, Bitbucket и Gogs. Доступны мобильные приложения для Android, iOS и Windows.

Сомнения: Интерфейс выглядит немного старомодно. Экраны довольно сложные — это немного запутывает работу с разными их видами.

LeanKit

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

LeanKit предлагает удобный способ соединения досок проектов на уровне команды и проекта и предоставляет пользователям полную видимость. Вы также получите модуль отчетности и аналитики с полезными показателями и метриками. Платформа поддерживает интеграцию с JIRA, Zendesk, Pivotal Tracker и другими инструментами.

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

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

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

Канбан особенно легко внедряется начиная с топ-менеджмента и прекрасно комбинируется с теорией ограничений, изложенной в книге «Цель» Элияху Голдрата. Канбан выбирают для себя отделы техподдержки, системные администраторы, и даже менеджеры по персоналу и бухгалтеры, тесно работающие с IT.

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

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

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

Выгоды внедрения

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

1) Канбан создан для того, чтобы увеличить прозрачность процессов внутри организации

Как часто происходит, что люди не понимают, как устроены процессы в той части компании, с которой им приходится взаимодействовать, но которая выполняет другую функцию? Например, как много маркетологи знают о работе программистов? А программисты о работе маркетологов?

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

2) Канбан помогает бороться с «многозадачностью» в самых плохих ее проявлениях

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

3) Канбан позволяет больше не заниматься оценкой сроков выполнения конкретной задачи

Вместо этого предполагается использовать статистические методы. Представьте себе, что вы измеряете диаметр сечения водопроводной трубы и скорость потока, а не занимаетесь предсказанием, как быстро конкретная капля(пусть даже помеченая синим красителем) пролетит через трубу из точки A в точку B.

Полезные инструменты, делающие Канбан эффективным

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

Канбан-доска

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

Инструкция по внедрению:

1) Определите, через какие состояния реально проходит ваша типичная задача. Вариант «гнев, отчаяние, торг, депрессия, принятие», конечно, не принимается, но звучит поразительно часто.

И вторая доска может быть расшифровкой слова «Дизайн» в первой доске, когда одна карточка на большой доске выглядит, как много мелких подзадач на дизайн в технической.

2) Разлинуйте и обустройте физическую или виртуальную доску. На первый этап рекомендуется просто повесить маркерную или пробковую доску на стену и разделить ее линиями, соответственно вашему предполагаемому процессу.

Физическое перемещение карточек по доске вместо электронного варианта дает определенное удовольствие, хотя и доставляет неудобства, особенно распределенным командам. Через 2-3 недели, когда вы поймете, какие именно состояния бывают у ваших работ на самом деле, можно перейти к электронному варианту.

Ограничение на количество работ в процессе. (WIP Limit)

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

Как внедрить:

1) обсудите завалы недоделанных задач(если они есть) и примите решение с ними бороться;

2) введите ограничение на самый заваленный столбец и только на него;

3) как только мы начинаем уделять особенное внимание какой-то части процесса и ликвидируем «завал» в этом месте, то самым узким местом станет другой участок производства, найдите новое самое узкое место и поставьте ограничение и на этот столбик
(даже если для этого вам придется убедить смежное подразделение тоже обзавестись канбан-доской, почему нет);

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

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

SLA — Service level agreement, или соглашение об уровне сервиса

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

Внедрение

1) Подсчитайте статистическими методами, сколько времени в среднем проходит от постановки задачи в очередь заказчиком (внутренним или внешним). А также, в какой временной промежуток уложились наиболее быстрые 10% (назовем его X), и в какой уложились только 90% (назовем его Y). Подсчитайте также время Z для «долгостроев», сколько времени занимали самые длинные задачи.

2) Возьмите Х и прибавьте к нему Y, и вы получите реалистичные сроки выполнения 90% задач, даже если заказчики будут «набегать» со срочными поручениями, которые не могут ждать указанный срок и будут отодвигать ваши задачи. Скажем по секрету, что они наверняка приходят со срочными задачами и сейчас тоже в особом порядке. Автору известны случая «внутренней коррупции», где нарушение приоритетов стоило чашку кофе или шоколадку, некоторые рассказывают о реально заплаченных деньгах.

3) Договоритесь с заказчиком(не имеет значения, внутренним или внешним) о том, что в штатной ситуации задача обрабатывается за время X+Y, и лишь 10% задач могут выполняться крайне долго по тем или иным причинам вплоть до времени Z.

Классы сервисов

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

Как внедрить?

Обсудить эту возможность, написать официальное письмо и добавить разделение строк на доску, оно обычно называется Swimlines, и если в Jira с этим проблем не было в старой версии, то в Asana кажется без дополнительных скриптов это невозможно.

Роль Менеджера запросов(SRM)

В материалах по Канбану авторы изредка честно говорят, что эта роль нужна скорее для того, чтобы не увольнять Product Owner при переходе со скрама, но и в этой позиции (SRM) нет особенной нужды, если нет проблем с получением заданий от заказчика. Эта роль может быть полезна тем командам, которые страдают от отсутствия «единой точки входа» в продуктовых компаниях. Тогда этот человек может устанавливать формальные политики и разбираться с входящей очередью, но это точно не предполагается как работа на полную ставку. Как вариант, можно иметь одного реквест менеджера на несколько команд, и превратить в него бывшего менеджера проектов или руководителя группы разработки(в общем того, кто в новом процессе остался без лишней работы).

Роль Менеджера поставки(SDM)

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

Каденции. Различные встречи с изменяемой под процесс периодичностью

Таких встреч в канбане много, даже слишком много. Различные встречи от ежедневных до встреч планирования поставок и и планирования наполнения очереди(аналог планирования спринта в скраме).

Ежедневная «летучка» standup

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

Operations Review

Как при работе не уйти в формализм и следование правилам в ущерб продукту?

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

Планирование поставки

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

Наполнение бэклога

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

Метрики

Существует стандартный набор метрик продукта: выручка, прибыль, ARPPU(average rate per paying user), чуть более нелюбимая ARPU(average rate per user, которая учитывает выручку в пересчете на всех пользователей, а не только платящих) и другие. Эти метрики очень полезны для любого процесса в продуктовой компании, немного другие, но весьма схожие — для аутсорсной. Но это конечно касается стратегического уровня.

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

Взаимодействие с управлением продуктом

Профессия менеджера продукта сродни работе стартапера, с той только разницей, что у менеджера продуктов есть только зарплата и, если повезет, процент от прибыли, а вот у стартапера зарплаты нет, но зато потенциальная прибыль принадлежит ему полностью(или в доле с партнерами).

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

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

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

Кросс-функциональные команды

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

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

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

И снова про доску, которую многие по ошибке принимают за сам канбан

Как сделать так, чтобы программиста, тестировщика или любого другого инженера больше не дергал менеджер или любой представитель смежных подразделений с вопросом «когда будет готово?»

Достаточно научить людей читать доску и ставить задачи на доску. Ведь в представлении многих канбан = доска, хотя это на самом деле не так.

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

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

Одним из моих профессиональных интересов, как координатора команды тестировщиков, являются методологии разработки программного обеспечения. В настоящее время все большую популярность приобретают так называемые Agile-методологии, в особенности Scrum и Kanban. На «раcпиаренных» терминах играют недобросовестные «тренеры», семинары и сертификации («сертифицированный Scrum-мастер», «сертифицированный Product owner» и т.д.) растут как на дрожжах.

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

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

Если вам не хочется читать — я сделал видео, где на пальцах описываю историю и основные принципы метода Канбан.

История термина

Kanban – японский термин, который начали использовать применительно к производству в 60-х годах 20-го века в компании Toyota. В основу данного принципа положен конвейерный метод производства, а также различные скорости выполнения отдельных технологических операций на производстве. Попробую объяснить на пальцах. При любом производстве есть основное производство («главный конвейер») и дополнительное производство («дополнительные конвейеры»). Темп выпуска конечных изделий задает главный конвейер, в то время как дополнительные конвейеры не могут ускорить темп выпуска изделия, но могут замедлить его, в случае несвоевременного выпуска требуемых деталей.

Дополнительно, при производстве может произойти смена приоритетов. К примеру выяснилось что станция, которая производила левые зеркала произвела 20 шт., а станция производившая правые зеркала — 10 шт., в то время как на конвейере находятся 15 автомобилей и необходимо 15 штук зеркал обоих типов. Налицо конфликт метрики — количественно производство не упало (дополнительные конвейеры выпустили 30 изделий в срок), но производство все равно рискует остановится. Kanban призван помочь с этой проблемой.

В упрощенном варианте, Kanban включает в себя два простых правила:

производственная станция имеет план производства деталей («backlog»). План отсортирован по приоритету, и может меняться в любое время (к примеру станция производящая слишком много левых зеркал должна иметь возможность переключиться на правые как можно скорее);
количество задач, выполняемых на станции одновременно ограничено (т.е. производить не более заданного количества зеркал одновременно). Это ограничение необходимо для управления скоростью производства на станции, а также скоростью реагирования на изменения плана.

Настоящее время

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

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

Отдельно необходимо отметить, что Kanban хорошо работает в стартапах, не имеющих четкого плана, но активно работающих над разработкой. Предлагаю рассмотреть пример использования Kanban в разработке программного обеспечения. Заранее прошу простить за некрасивые иллюстрации. Давайте представим себе команду из одного разработчика, работающего над небольшим проектом. План разработки (backlog) отсортирован в порядке приоритета кусков работы, лимит команды на задачи в процессе — 1 шт.

изменить лимит на количество задач в работе;
добавить задачу с более высоким приоритетом (к примеру p0) для того чтоб она была взята как можно скорее;

В процессе работы может так произойти, что работа заблокирована (сломался хостинг, не скачан нужный framework и т.д.). В общем случае, заблокированная работа возвращается в backlog, и выбирается новая задача, с максимальным приоритетом. В зависимости от характера задач и типа команды лимит может быть увеличен или уменьшен. К примеру, наш разработчик может одновременно рисовать форму регистрации и смотреть за процессом развертывания нового сервера. Тем не менее, если время завершения задач будет меньше требуемого, руководитель проекта может уменьшить лимит, или увеличить команду. Таким образом, при грамотном руководстве, Kanban обеспечивает максимально возможную для данной команды скорость работы, максимальную скорость реагирования на изменения и в то же время сократить «расходы» на поддержку методологии. В общем все! Kanban — это не просто, просто. Это очень просто!

данная методология плохо работает с большими командами (больше 5 человек);
в чистом виде, Kanban плохо работает с кросс-функциональными командами. Т.е. в отличие от Scrum, тяжело совместить тестирование и разработку в одной команде. Более удачной мыслью является разбить процесс на «станцию» разработки и «станцию» тестирования с отдельными руководителями и backlog-ами;
ввиду своей истории и специфики, Kanban не предназначен для долгосрочного планирования.

Заключение

В заключение, хочу добавить, что сравнение любых методологий по принципу «кто круче» не продуктивно и контр-конструктивно (капитан очевидность). Каждая, более-менее распространенная, методология имеет свои плюсы, минусы и границы применения. Дополнительно, Agile-методологии в принципе накладывают большие требования на сработанность и опыт членов команды.

В случае возникновения интереса к теме продолжу рассмотрение Kanban'a подробнее. В последствии, предлагаю разобрать по полочкам и картинкам Scrum и RUP.

Читайте также: