[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "create", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-158433683", "adfox_url": "//ads.adfox.ru/228129/getCode?p1=bxbwd&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid21=&puid22=&puid31=&fmt=1&pr=" } } ]
{ "author_name": "Konstantin Panphilov", "author_type": "self", "tags": ["\u043a\u043e\u043b\u043e\u043d\u043a\u0430"], "comments": 30, "likes": 20, "favorites": 37, "is_advertisement": false, "section_name": "default", "id": "15249", "is_wide": "1" }
Konstantin Panphilov
12 083

Кейс 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 даст свои плоды, если вы вовлечете в это менеджмент по максимуму.

#Колонка

Популярные материалы
Показать еще
{ "is_needs_advanced_access": false }

Комментарии Комм.

Популярные

По порядку

0

Прямой эфир

Компания отказалась от email
в пользу общения при помощи мемов
Подписаться на push-уведомления