Kanban, как команда из четырех человек развивает и поддерживает девять проектов


В 2014 году в компании Rossko (ведущий дистрибьютор автозапчастей с 1997 г.) возникли сложности с запуском новых IT-проектов. Ошибки, срывы сроков…

Перед новым IT-директором стояла задача наладить взаимодействие с бизнес-заказчиками и выстроить производственный процесс.

При чем тут IT?

При численности компании более 1000 человек, IT-департамент насчитывает около 50 сотрудников, которые разрабатывают и поддерживают решения на базе платформы 1С.

Основные заказчики в IT-департамент — руководители направлений Логистика, Продажи, Бухгалтерия и т.д. (всего их 9).

Бизнес зависит от стабильности разработанных продуктов и скорости выпуска новых.

Таким образом мы можем смело сказать, что Rossko — IT компания.

Курс на Agile

Пройдя тренинги по Agile-методологиям и проведя внутренние обучения, компания двинулась в сторону гибких методологий разработки.

Для создания нового продукта была собрана команда, которая стартовала работу по Scrum. Эксперимент был успешным — продукт был запущен, бизнес заказчик получил ровно то, что хотел.

Как была организована работа

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

Команда поддержки использует Kanban-метод и обслуживает сразу несколько внутренних заказчиков.

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

Kanban, эффективное взаимодействие с 9 внутренними заказчиками

Команда поддержки продуктов работает по методологии Kanban:

  • используются 2 класса предоставления услуги (срочно — проталкивание задачи, и стандартно — вытягивание);
  • все стадии кроме начальной и финальной имеют ограничение на максимальное количество одновременно выполняемых задач;
  • у каждого заказчика есть представитель, который отвечает за описание требований, предоставление информации по задаче и приоритизации своей короткой очереди;
  • есть релиз-менеджер, который отвечает за реализацию задачи с момента как команда берет обязательства по её выполнению.

Стоит отметить, что в команде на протяжении долгого времени было всего 4 человека.

Рабочее пространство заказчика

Рабочее пространство каждого внутреннего заказчика организовано следующим образом:

  • Есть доска с его планами, которая разделена на две колонки: Планы — что надо сделать по его направлению и Готово в работу — что нужно сделать в ближайшее время.
  • Подключена доска IT-Производство, которая отражает текущее состояние задач по всем внутренним заказчикам.
Cхема рабочего пространства заказчика №1

Задачи из очереди “Готово в работу” могут занять либо ячейку в дорожке “Срочно”, либо в дорожке №1.

Рабочего пространства заказчика №1

На снимке экрана представлено как это пространство выглядит на мониторе заказчика. Обратите внимание, что оно разделено на две части (две доски):

  • “Продажи” — это планы по направлению “продажи” (соответствует блоку “ПЛАНЫ ЗАКАЗЧИКА НОМЕР 1” на схеме);
  • DevOne — это команда поддержки, которая обслуживает всех заказчиков (соответствует блоку “IT-ПРОИЗВОДСТВО” на схеме).

В правой части (доска DevOne) отмечены карточки, которые имеют отношение к текущему заказчику.

Cхема рабочего пространства заказчика №2 Рабочего пространства заказчика №2

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

Главная характеристика такого процесса — это прозрачность и понятность текущих статусов. Заказчику не надо звонить/писать/узнавать что с его задачей, достаточно посмотреть на экран и найти свои задачи.

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

приоритизация задач между заказчиками

Бизнес определяет приоритет направления согласно стратегическим планам компании.

В рамках стандартного приоритета на доске IT-производство для каждого заказчика есть своя “дорожка”, которая позволяет ему сразу понять где находятся его задачи. Также он видит общую картину по IT-производству — задачи других заказчиков.

Чтобы приоритизировать задачи от 9 заказчиков, введены следующие правила:

  • всегда есть лимит на ячейку сделаем у каждого заказчика (ячейка — пересечение колонки с дорожкой), на схемах выше лимиты на ячейках, это цифры 1/3, 1/1, 2/2.
  • Суммарный лимит по ячейкам не превышает лимит на стадию “Сделаем”
  • Сквозная FIFO-нумерация (First In, First Out — «первым пришёл — первым ушёл») задач в колонке сделаем (на схеме карточка в дорожке заказчика помечена порядковым номером 3, потому что в очередь она попала 3-й по отношению к карточкам от других заказчиков).

Как это работает на практике:

  1. Бизнес решает какие направления наиболее приоритетные на текущий момент, и исходя из них расставляет лимиты на ячейки по направлениям. То есть для заказчика №1 может быть выделен лимит 3, а для заказчика №2–1 (так сделано на схеме)
  2. Как только в дорожке заказчика освобождается место в ячейке под карточку, он согласует с релиз-менеджером помещение следующей карточки (согласование заключается только в том, чтобы в карточке были критерии приемки, зафиксированные заказчиком).
  3. Карточке присваивается порядковый номер в рамках общей очереди (FIFO), таким образом гарантируется равномерное выполнение задач.
  4. Нумерация карточек в колонке “Сделаем” всегда начинается с 1 и все участники процесса понимают, какая задача пойдёт в работу следующей. Когда разработчики берут задачу из колонки “Сделаем”, номера оставшихся карточек уменьшаются на 1.
  5. Каждый заказчик имеет возможность менять приоритет задач в своей ячейке, не влияя на общее состояние очереди.

Работа со срочными задачами

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

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

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

Анализ процесса с помощью аналитических возможностей Kanban

Две самые важные характеристика сервиса — время и качество обслуживания клиента.

Команда поддержки — это сервис для внутренних заказчиков.

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

Пульс проекта (Кумулятивный поток)

График накопленных итогов

На графике видно плавный прирост задач в стадию Готово (Росско / Done), команда практически каждый день поставляет задачи в бой.

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

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

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

Время разрешения инцидентов

Контрольный график

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

Например, установив SLA 3 дня, можно посмотреть выполнение какого процента задач укладывается в этот срок.

Пропускная способность команды поддержки

Пропускная способность

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

На графике изображены периоды (месяц), в каждом два столбца:

  • сколько задач поставили (левый столбец);
  • сколько задач было сделано (правый столбец).

График можно смотреть как по количеству задач, так и по их размеру. В данном случае график построен по размерам карточек.

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

Когда задача будет готова?

В созданной системе работы с задачами для каждого заказчика можно выделить два временных участка:

  1. Ожидание — время с момента как задача попала в Готово в работу до попадания в стадию Сделаем;
  2. Реализация — от Сделаем до Готово.
Распределение времени выполнения на отрезке **Ожидание**

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

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

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

Распределение времени выполнения на отрезке **Реализация**

А это распределение времени для отрезка Реализация (с момента как задачу взяли в работу до готовности).

85% задач выполняются менее чем за 13 дней (календарных).

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

Распределение времени выполнения, захватывающее оба отрезка **Ожидание** и **Реализацию**

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

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

Динамика изменения времени выполнения задач

На графике показано как менялось время выполнения задач по каждому направлению с начала 2016 года до апреля 2016.

Rossko о внедрении Kaiten

Благодаря простому интерфейсу нам удалось достаточно быстро перейти с Jira на Kaiten для Kanban-команд.

С момента когда появилась поддержка Scrum, мы начали постепенно переводить также и Scrum-команды.

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

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


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

Регистрируйтесь и пишите нам

Удачи в ваших проектах!