Кейс Rossko: как команда из четырёх человек развивает девять проектов
Что находится под капотом у ведущего поставщика автозапчастей
В 2014 году в компании Rossko (ведущий дистрибьютор автозапчастей с 1997 г.) возникли сложности с запуском новых IT-проектов. Ошибки, срывы сроков…
Перед новым IT-директором стояла задача наладить взаимодействие с бизнес-заказчиками и выстроить производственный процесс.
При чем тут IT?
При численности компании более 1000 человек, IT-департамент насчитывает около 50 сотрудников, которые разрабатывают и поддерживают решения на базе платформы 1С.
Основные заказчики в IT-департамент — руководители направлений Логистика, Продажи, Бухгалтерия и т.д. (всего их 9).
Бизнес зависит от стабильности разработанных продуктов и скорости выпуска новых.
Таким образом мы можем смело сказать, что Rossko — IT компания.
Прогрессивные компании уже управляют своими проектами в Kaiten. Присоединяйтесь к лучшим.
Курс на Agile
Пройдя тренинги по Agile-методологиям и проведя внутренние обучения, компания двинулась в сторону гибких методологий разработки.
Для создания нового продукта была собрана команда, которая стартовала работу по Scrum. Эксперимент был успешным — продукт был запущен, бизнес заказчик получил ровно то, что хотел.
Как была организована работа
Разработка новых проектов стартовала по Scrum, а после запуска в промышленную эксплуатацию отдается команде поддержки, которая продолжает активное развитие.
Команда поддержки использует Kanban-метод и обслуживает сразу несколько внутренних заказчиков.
Кроме команды поддержки, Kanban также используют команда разработки основного сайта компании и отдел системных инженеров.
Kanban, эффективное взаимодействие с 9 внутренними заказчиками
Команда поддержки продуктов работает по методологии Kanban:
- используются 2 класса предоставления услуги (срочно — проталкивание задачи, и стандартно — вытягивание);
- все стадии кроме начальной и финальной имеют ограничение на максимальное количество одновременно выполняемых задач;
- у каждого заказчика есть представитель, который отвечает за описание требований, предоставление информации по задаче и приоритизации своей короткой очереди;
- есть релиз-менеджер, который отвечает за реализацию задачи с момента как команда берет обязательства по её выполнению.
Стоит отметить, что в команде на протяжении долгого времени было всего 4 человека.
Рабочее пространство заказчика
Рабочее пространство каждого внутреннего заказчика организовано следующим образом:
- Есть доска с его планами, которая разделена на две колонки: Планы — что надо сделать по его направлению и Готово в работу — что нужно сделать в ближайшее время.
- Подключена доска IT-Производство, которая отражает текущее состояние задач по всем внутренним заказчикам.
Задачи из очереди “Готово в работу” могут занять либо ячейку в дорожке “Срочно”, либо в дорожке №1.
На снимке экрана представлено как это пространство выглядит на мониторе заказчика. Обратите внимание, что оно разделено на две части (две доски):
- “Продажи” — это планы по направлению “продажи” (соответствует блоку “ПЛАНЫ ЗАКАЗЧИКА НОМЕР 1” на схеме);
- DevOne — это команда поддержки, которая обслуживает всех заказчиков (соответствует блоку “IT-ПРОИЗВОДСТВО” на схеме).
В правой части (доска DevOne) отмечены карточки, которые имеют отношение к текущему заказчику.
Обратите внимание, что каждый заказчик использует собственную доску для очереди задач и общую доску производства.
Главная характеристика такого процесса — это прозрачность и понятность текущих статусов. Заказчику не надо звонить/писать/узнавать что с его задачей, достаточно посмотреть на экран и найти свои задачи.
Kaiten позволяет создавать рабочие пространства из существующих досок. Создать описанные пространства в Kaiten можно за несколько минут.
Приоритизация задач между заказчиками
Бизнес определяет приоритет направления согласно стратегическим планам компании.
В рамках стандартного приоритета на доске IT-производство для каждого заказчика есть своя “дорожка”, которая позволяет ему сразу понять где находятся его задачи. Также он видит общую картину по IT-производству — задачи других заказчиков.
Чтобы приоритизировать задачи от 9 заказчиков, введены следующие правила:
- всегда есть лимит на ячейку сделаем у каждого заказчика (ячейка — пересечение колонки с дорожкой), на схемах выше лимиты на ячейках, это цифры 1/3, 1/1, 2/2.
- Суммарный лимит по ячейкам не превышает лимит на стадию “Сделаем”
- Сквозная FIFO-нумерация (First In, First Out — «первым пришёл — первым ушёл») задач в колонке сделаем (на схеме карточка в дорожке заказчика помечена порядковым номером 3, потому что в очередь она попала 3-й по отношению к карточкам от других заказчиков).
Как это работает на практике:
- Бизнес решает какие направления наиболее приоритетные на текущий момент, и исходя из них расставляет лимиты на ячейки по направлениям. То есть для заказчика №1 может быть выделен лимит 3, а для заказчика №2–1 (так сделано на схеме)
- Как только в дорожке заказчика освобождается место в ячейке под карточку, он согласует с релиз-менеджером помещение следующей карточки (согласование заключается только в том, чтобы в карточке были критерии приемки, зафиксированные заказчиком).
- Карточке присваивается порядковый номер в рамках общей очереди (FIFO), таким образом гарантируется равномерное выполнение задач.
- Нумерация карточек в колонке “Сделаем” всегда начинается с 1 и все участники процесса понимают, какая задача пойдёт в работу следующей. Когда разработчики берут задачу из колонки “Сделаем”, номера оставшихся карточек уменьшаются на 1.
- Каждый заказчик имеет возможность менять приоритет задач в своей ячейке, не влияя на общее состояние очереди.
Работа со срочными задачами
Срочные задачи — это задачи, которые обслуживаются вне очереди. Но чтобы срочные задачи не влияли существенно на нормальной процесс — количество одновременных срочных задач ограничено.
Заказчик имеет право занять ячейку в дорожке срочно, если он свободен и это согласовано с другими заказчиками.
Таким образом работа со срочными задачи является управляемым процессом и позволяет заказчикам “проталкивать” реально важные для бизнеса задачи, не ломая основной процесс.
Анализ процесса с помощью аналитических возможностей Kanban
Две самые важные характеристика сервиса — время и качество обслуживания клиента.
Команда поддержки — это сервис для внутренних заказчиков.
Kanban предлагает эффективный способ понять характеристики сервиса и вовремя узнавать об отклонениях.
Пульс проекта (Кумулятивный поток)
На графике видно плавный прирост задач в стадию Готово (Росско / Done), команда практически каждый день поставляет задачи в бой.
Но в период с 15.02 по 29.02 задачи зависли в стадии готово в релиз (оранжевый участок стал шире чем обычно). В этот период была проблема с поставкой обновлений в бой, которая разрешалась практически неделю.
График позволил быстро определить есть ли какие-то проблемные участки, которые стоит обсудить или нет отклонений в работе.
Также любое процессное решение, которое принимается для оптимизации должно сразу же отразиться на данном графике (стали ли мы быстрее или медленне делать задачи и т.п.)
Время разрешения инцидентов
Контрольный график позволяет устанавливать планку для времени разрешения задач (например, срочных инцидентов) и анализировать отклонения.
Например, установив SLA 3 дня, можно посмотреть выполнение какого процента задач укладывается в этот срок.
Пропускная способность команды поддержки
Для контроля пропорционального распределения задач согласно настройкам канбан-системы, команда обращается к графику пропускной способности.
На графике изображены периоды (месяц), в каждом два столбца:
- сколько задач поставили (левый столбец);
- сколько задач было сделано (правый столбец).
График можно смотреть как по количеству задач, так и по их размеру. В данном случае график построен по размерам карточек.
Бизнес-заказчик может в любой момент посмотреть процентное соотношение на выходе по его задачам по отношению к общему.
Когда задача будет готова?
В созданной системе работы с задачами для каждого заказчика можно выделить два временных участка:
- Ожидание — время с момента как задача попала в Готово в работу до попадания в стадию Сделаем;
- Реализация — от Сделаем до Готово.
Первый столбец, например, показывает, что за наблюдаемый период 17 карточек взяли в работу в течение одного дня с момента попадания в короткую очередь (Готово в работу).
Но здесь нужно обратить внимание на вторую вертикальную красную черту, это 85% перцентиль. Это отметка, которая говорит что для 85% задач ожидание составило не более 10 дней (календарных).
То есть когда исполнитель говорит что приступит к этой задаче в течение недели — это с большой вероятностью правда, т.к. подтверждено статистическими данными.
А это распределение времени для отрезка Реализация (с момента как задачу взяли в работу до готовности).
85% задач выполняются менее чем за 13 дней (календарных).
Здесь стоит обратить внимание, что самые долгие задачи длились 20 дней, то есть максимальная задержка по отношению к большинству задач составила всего неделю.
А это график, который захатывает оба временных участка. 85% задач с момента помещения в очередь на ожидание до реализации были сделаны за 20 дней.
Как меняется производительность команды со временем
На графике показано как менялось время выполнения задач по каждому направлению с начала 2016 года до апреля 2016.
Rossko о внедрении Kaiten
Благодаря простому интерфейсу нам удалось достаточно быстро перейти с Jira на Kaiten для Kanban-команд.
С момента когда появилась поддержка Scrum, мы начали постепенно переводить также и Scrum-команды.
Благодаря онлайн-чату для общения с поддержкой Kaiten, сотрудники получили возможность быстро получить консультацию по любому вопросу, касательно функциональности Kaiten.
Одной из основных практик в канбан является ограничение количества одновременных выполняемых задач, стремление как можно быстрее завершить выполнение задач. В начале у коллег были сомнения в эффективности подобного подхода. Например, когда возникала пауза, из-за отсутствия необходимой обратной связи от заказчика или из-за проблемы с выполнением, то казалось, что будет эффективнее отложить выполнение этой задачи и взять новую задачу в работу. Однако по факту оказывалось, что в этом случае, при работе над несколькими задачами параллельно, сразу падала скорость, и в конечном итоге суммарно времени тратилось значительно больше. Некоторым коллегам в этом нужно было убедиться на собственном опыте, после чего вопросов уже не возникало.
– Кирилл Зуев, IT-директор Росско
Возможно, статья показалась вам сложной, но мы готовы продемонстрировать вам всю механику за 30 минут и обсудить применимость Kanban для вашего процесса.
Удачи в ваших проектах!
Если хотите рассказать о своем кейсе, управленческом опыте или стать соавтором статьи, напишите нашему редактору d.lebedeva@kaiten.io
Интересные статьи
Veronika Vesterovskaya
Viacheslav Tsyrulnik
Viacheslav Tsyrulnik
Подпишитесь на наш канал в Telegram!
Там мы публикуем анонсы новых фич, как только они появляются в Кайтене.
Подписаться