Лого 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

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

Вот, и Сбербанк туда же: tinyurl.com/j7d3gx3

0

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

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

В Agile методологиях достаточно много внимания уделяется тому, как должны ставиться задачи. Это навык, которому можно научиться

Vladimir Rybakov, каким образом ведется контроль за правильностью постановки задач?
Кто, вообще говорит, что делать?

0

Правильность в данном случае это возможность проверить то, что результат соответсвует требованиям. То есть сам бизнес должен ответить на вопрос: Как мы будем проверять, что задача выполнена?

Говорит, что делать естественно представитель бизнеса.

0

Vladimir Rybakov, так я об этом и говорю. Возвращаемся к моему коменту. Никогда не было проблем с распределением задач, есть проблема "сам бизнес должен ответить на вопрос", а бизнес на этот вопрос ответить не может.

0

У разных компаний, разные проблемы. Если бизнес не умеет формулировать собственные потребности, то здесь никакой инструмент не поможет.

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

0

Vladimir Rybakov, в этом и есть предназначение технологий - решать проблемы, которые бизнес решить не может. Именно это я и утверждаю. Что в компаниях нет проблем с управлением процессов - есть проблема с постановкой задачи.

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

0

Vladimir Rybakov, проблема открыта. Ее и надо решать. А делать очердные digital post-it, для решения проблемы, которой не существет, вовсе не обязательно.

0

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

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

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

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

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

0

Vladimir Rybakov, Например, стоит задача разработать новый самолет. Поясните, как это можно сделать с помощью Kaiten?

0

Kaiten - это инструмент для управления процессами, а не для разработки самолётов.

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

Какой-из этапов разработки является проблемой (самым медленным) на данный момент?
Когда будет завершена та или иная задача?
Как изменяется производительность команды во времени?

0

Разработка - это и есть процесс. Точно такой же стандартный процесс, как и любая разработка.

Да нет никаких проблем с упрвлениями процессами. Самолеты то как-то то строят и летают. Все под полным контролем. Основной затык - это придумать самолет, а процессы все отлажены.

0

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

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

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

0

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

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

Да в целом любой процесс разработки можно подвязать под Kanban на этапе планирования и приоритизации самого процесса разработки.

Имхо: может я как-то не так понял статью.

0

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

Можно использовать kanban и с большой вариативностью, хотя естественно, что качество прогноза при этом снизится. Аналогичная ситуация происходит и со всеми другими методологиями - чем однороднее оценка наших задач, тем более качественный прогноз мы можем сделать.

0

Александр, аналитика дает вам возможность работать с рисками.

Вот вам пример:
- Петя сколько времени надо чтобы сделать эту задачу (неважно какого размера)?
- Я подумал и думаю что на нее уйдет 2 недели

Вы смотрите аналитику на основе статистических данных и видите, что департамент Пети в целом 85% задач делает за 2 недели. То есть ваши риски лежат в тех самых 15%, которые могут уехать в 3 недели.

Далее вы принимаете для себя решения - устраивает ли вас такой риск, или нет. Если нет - вы решаете что с этим делать.

- Петя, ты знаешь у нас жесткий дедлайн, за 2 недели надо точно выпустить
- Хорошо, давайте тогда пустим эту задачу по "срочной" дорожке, чтобы максимально митигировать риски.

1с, самолет, и т.д. Неважно.

0

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

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

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

0

В целом то статья интересная и продукт интересен.

Возник вопрос с готовой интеграцией/встраиванием в битрикс24(облако и коробка). Есть ли готовые механизмы и т.д.?

0

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

0

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

В случае если вариативность большая, просто помечаются задачи майками: (S)mall, (L)arge, (XL)arge, и условно говоря Пете достаточно только сказать, это точно XL.

0

Давайте рассматривать теоретический кейс.
Канбан относительно специфическая система и бизнес не может вести все задачи в канбане. В данном конкретном случае нашему бизнесу привычно/удобно вести задачи в битрикс24 или аналогах.
Соответственно заказчикам бизнеса удобней ставить задачи в нем.
Но отдел разработки в целом лучше работает с канбан. Поэтому либо нужна сквозная интеграция, либо довесок над битриксом/аналогом.
Либо нужно дублировать задачи в канбан.

Но это так мысли вслух)
Только импорт будет не удобен. Как минимум нужен обмен комментариями по задачам/карточкам в обе стороны, чтобы выстраивать коммуникации и какой-то обмен статусами.

0

В целом с майками и декомпозицией понятно. Обдумаем этот момент)

0

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

0

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

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

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

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

0

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

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

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

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

0

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

Сейчас обсуждают
Ярослав Белов

*Подготовка спецификации ужасно утомительна, и если она делается вручную, то занимает ужасно много времени.*
Если бы в stand up были дизайнеры, это была бы основная тема монолога. Спасибо за статью, зациклился на этой боли.

Обзор инструментов для создания дизайн-спецификаций: Avocode, Sympli и Zeplin
0
Misha Senseev

Генераторы говносайтов были. Поисковики их банить научились. Ход за Амазоном :)

Программист заработал более $3 млн на продажах некачественных книг на Amazon
0
Den Xxx

С регистрацией.

Mercedes-Benz представил электромобиль Generation EQ — конкурента Tesla Model X
0
Роман
ShareBike

Ну да, российские продукты от Яндекса до Призмы никому не известны. То ли дело гремящие на весь мир украинские стартапы :)

«Половина украинцев — это программисты, копирайтеры и маркетологи»
1
Никита Егоров

Клуб компьютерных игр :)

«Подделки принесли нам 1,5 миллиона рублей за два месяца»
0
Показать еще