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

Systems Thinking Approach to Introducing Kanban (S.T.A.T.I.K) — это системный подход к внедрению метода Kanban в компании. То есть вы проходите определенные шаги, оцениваете задачи, проблемы и ожидания.

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

В идеале метод S.T.A.T.I.K приветствует совместные совещания с сотрудниками, заказчиками и партнерами компании для обсуждения Kanban–системы. В реальности реализовать это весьма сложно.

Systems Thinking Approach to Introducing Kanban (STATIK) — это системный подход к внедрению метода Kanban в компании. То есть вы проходите определенные шаги, оцениваете задачи, проблемы и ожидания. И из этих элементов получаете взгляд на систему в целом. Здесь будут видны все недостатки, которые есть в процессах, и пути по их исправлению.

Гуру Канбана Дэвид Андерсон выделяет 8 ключевых шагов. Это те самые действия, которые нужно последовательно совершить для внедрения Канбан–метода.

Какие у него ожидания по срокам, качеству продукта, безопасности и предсказуемости результата?

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

Нужно узнать, чем те и другие недовольны на данном этапе. К примеру, клиент жалуется на затягивание сроков разработки продукта. А сотрудники недовольны сбоями и задержками, которые происходят из–за незапланированных задач. Тут легко увидеть взаимосвязи и разобраться с ними.

Если вы решите проблемы сотрудников, то автоматически разберетесь и с недовольством клиентов. Источники недовольства будут входными данными для Kanban–системы.

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

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

Здесь нужно ответить на вопрос, как мы можем удовлетворить ожидания заказчика (вспомним Шаг 1). Что нам мешает? Какие есть узкие места в процессе выполнения заказа, и как мы можем их исправить.

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

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

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

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

К этому шагу мы уже понимаем, какой процесс проходим в каждом типе задач, их приоритетность. Теперь нужно решить, сколько досок нам нужно, для их отражения. Хватит одной? Или нужно 2-3?

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

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

Стоит определить как будет меняться Канбан–система. Что можно внедрить сегодня, завтра, что через месяц.

В идеале подход S.T.A.T.I.K приветствует совместные совещания с сотрудниками, заказчиками и партнерами компании для обсуждения Kanban–системы. В реальности реализовать это весьма сложно.

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

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

Создали дорожную карта проектов. Оказалось в компании нет сформулированных целей, что делает планирование фактически невозможным. Совместно с руководством они были поставлены. Затем расставили приоритеты и создали дорожную карту. Важность проектов оценивалась по шкале от 1 до 100. Чем больше число, тем выше приоритет проекта.

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

Начали использовать Канбан–доску. В компании остро стояла проблема ограниченности ресурсов. Проектная команда состояла из 9 человек. При этом в разработке постоянно находилось в районе 30 проектов разного приоритета. Канбан–доска позволила визуализировать процессы. Понять, какой проект приносит в компанию деньги и отдать задачам, связанным с ним, наивысший приоритет.

На ежедневных совещаниях у доски команда отвечает на три вопроса:

• Что сделано вчера?

• Какие были проблемы?

• Что будет сделано сегодня?

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

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

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

Свою эффективность Kanban–метод показал уже через 3 месяца. В компании было успешно завершено 2 крупных сложных проекта и несколько небольших типовых.

Компания разрабатывает и производит наукоемкие приборы. В портфеле находится порядка 100 проектов (часть из них в работе, другая — в очереди).

Есть проблемы:

• Заказчики недовольны реализацией своих заявок в НИОКР

• В компании никто не владеет информацией о стадиях проектов. Какие сейчас активны, какие нет.

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

• Один человек мог вести 5-8 проектов одновременно.

• Нет точных сроков завершения проекта. И никто не может их спрогнозировать.

• Не расставлены приоритеты по проектам. В работу берут не самые важные, а те на которых настаивает заказчик.

• Копятся незавершенные проекты, по которым переносится срок. Это происходит из–за поступления новых, более важных задач.

Что было сделано:

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

• Ввели систему премирования разработчиков за завершенные проекты.

• Наняли в компанию менеджера проектов. В дальнейшем — создали проектный отдел.

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

• Ввели ограничение на количество проектов в работе.

• Начали отчитываться перед заказчиком о статусе проекта один раз в неделю.

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

• Стали использовать чек–листы для описания критериев перехода проекта из одной стадии в другую.

• Стали детально анализировать процессы, чтобы находить в них узкие места.

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

• Разработчик получал в работу одновременно три разных проекта. Приходилось переключаться между ними. Это увеличивало сроки спринта. Заказчики беспокоились.

• Накапливались незавершенные задачи.

• Все проекты имели одинаковую степень важности.

• Найм второго разработчика в команду проблему не решил.

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

Установили WIP лимиты. По 2 проекта на сотрудника.

Расставили приоритеты. Проекты начали оценивать по важности и срочности.

В результате в компании перестали возникать ситуации с незавершенными проектами и очередями из них. Загрузка в команде стала равномерно распределяться. Проекты стали выполнять в зависимости от их приоритета. Заказчики стали четко понимать сроки завершения работы.

В дальнейшем компания перешла от физической Канбан–доски к виртуальной.

Диджитал–агентство полного цикла. Занимается представлением бизнеса в онлайн, рекламой в соцсетях созданием и сопровождением сайтов.

• Все процессе вели в Битрикс 24. Возникали проблемы с распределением задач по специалистам отдела разработки.

• Была плохо налажена коммуникация между отделами. Некоторые из них были зарубежными.

• Решения принимались быстро и без обсуждений.

В агентстве решили попробовать Kanban StatiK и пройти 8 шагов, о которых мы рассказали в начале статьи.

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

• Внедрили ежедневные утренние митинги для координации работы.

• Установили WIP лимиты на количество задач в процессе. Через несколько дней это дало свои плоды: задачи перестали «зависать», доделывать их стали гораздо быстрее.

• Наладились связи между отделами. Сотрудники стали работать как единая команда.