Лого vc.ru

Кейс Kaiten: Как команда из четырёх человек применяет Kanban-методологию для работы с девятью проектами

Кейс Kaiten: Как команда из четырёх человек применяет Kanban-методологию для работы с девятью проектами

Вячеслав Цырульник, руководитель системы управления Kaiten, описал для vc.ru опыт использования Kanban-методологии в дистрибьюторе автозапчастей для упрощения ИТ-разработки.

Поделиться

В 2014 году в дистрибьюторе автозапчастей Rossko не смогли запустить новые ИТ-проекты. Ошибки, срывы сроков.

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

При чем тут ИТ

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

Основные заказчики в ИТ-департаменте —  руководители направлений логистики, продаж, бухгалтерии и так далее (всего их 9).

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

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

Курс на Agile

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

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

Как организована работа сейчас

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

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

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

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

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

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

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

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

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

Cхема рабочего пространства заказчика номер 1:

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

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

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

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

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

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

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

Конфигурация пространства в Kaiten:

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

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

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

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

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

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

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

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

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

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

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

Ценности Kaiten

  1. Простота настройки.
  2. Прозрачность процесса для заказчиков и исполнителей.
  3. Поддержка гибких методологий.
  4. Аналитические возможности по диагностике процесса.

Рекомендация ИТ-директора Rossko, Кирилла Зуева

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

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

Не пытайтесь придумать свой agile и свой framework. Посещайте тренинги.

Agile даст свои плоды, если вы вовлечете в это менеджмент по максимуму.

Присылайте колонки, соответствующие требованиям редакции, на secret@vc.ru

Популярные статьи
Показать еще
Комментарии отсортированы
как обычно по времени по популярности

Хотелось бы уточнить у автора - какого рода задачи решаются отделом?

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

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

В статье нет утверждения о том, что любая задача выполняется за семь дней, речь идет лишь о вероятности. При этом уровень в 85% очень хорош для прогнозов. Чаще всего дата завершения будет определена верно.

Если взглянуть на график, то можно заметить, что время решения самой долгой задачи составило 34 дня. Это те самые 15%, которые являются нашими рисками

0

Есть ли у Kaiten API? Интересует возможность передачи данных о сроках выполнения задач в 1С

0

Спасибо за материал! С назначением Канбана и Kaiten'a понятно. Аналитика, пропускная способность, кумулятивные потоки и т.д. всё это говорит нам о том, насколько мы эффективно обслуживаем/выполняем входящий поток задач. Но, если ключевым параметром эффективности с ваших слов, это скорость выполнения задач (а для большинства, это так), вопрос вот в чём: При отсутствии таймбоксов о какой скорости идёт речь? О скорости смены статусов карточек (что так умело считает аналитика) или о реальной скорости выполнения задач, то есть, о соблюдении заявленного срока к фактическому?

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

Пардон, если сильно мудрено. Интересно узнать ваше мнение.

Промахнулся с ответом, чуть ниже его написал.

0

Кроме измерения фактической скорости, команда использует двухнедельные каденции, для того чтобы контролировать пропускную способность в карточках (или Story Points). - этот параметр аналогичен велосити в Scrum.

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

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

Надеюсь, что я верно понял, заданный вопрос.

0

Возможность комментирования статьи доступна только в первые две недели после публикации.

Сейчас обсуждают
Alexander Pershin
HTML Academy

Все перечисленные задачи типовые для IT, просто взял примеры чуть шире просто программирования.

Называя "обезъянками" других IT-специалистов вы показываете великолепнейший уровень дискусии, достойный только высококласснейших программистов, повелителей логики и алгоритмов.

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

Куда пойти учиться программисту: советы опытного тимлида, преподавателя и новичка
0
Evgeny Rodionov

Ожидания от комментариев вц: обсуждение маркетинговой стратегии крупной продуктовой сети
Реальность: уровень ок.ру с нытьем про бомжей, кассиров и детей

«Товарооборот на 44% превысил ожидания маркетологов»: история акции с «Прилипалами» в «Дикси»
0
Ivan Rakevich

Ты кто такой? 1 раз тебя вижу.

Facebook запретила Live-голосования на основе реакций и ужесточила правила использования эмодзи
0
Сергей Иванов

если вы хотите сказать что красный и синий провод это CAN-H и CAN-L то объясните где питание к датчику, как к примеру вибромотор 2 отпустит шину если сигнал от акселерометра? автор решил присобачить схему с какого нибудь автофорума, собрал бабки и съеб.......

Смерть стартапа: Как создатели «умного» кольца BioRing собрали $460 тысяч на краудфандинге и исчезли
0
Денис Семенов
Mokselle

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

«Я потратил $10 млн и два года на то, что мог выяснить за 4 недели»: основатель Twenty20 об ошибках проекта
0
Показать еще