Часто Kanban ассоциируется с продуктовыми командами. Но мы в Точка Банк решили внедрить его в Devexp — это команда, которая занимается предоставлением и сопровождением, а также разработкой и развитием инфраструктуры и сервисов для разработчиков. У ребят уже была небольшая база в виде простой панели в проекте Jira, но отсутствовали необходимые процессные метрики. Мы использовали системный подход STATIK, но адаптировали его с учётом специфики инженерной работы.

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

С чего всё началось 

Devexp (Developer Experience) — это часть инженеров и разработчиков большой инфраструктурной команды. Ребята занимаются предоставлением, развитием и сопровождением верхнеуровневой инфраструктуры и сервисов для разработчиков: Kubernetes, мониторинг, логи, стораджи, внутренняя библиотека сервисов и т.д. Я пришел туда два года назад, чтобы навести порядок в задачах и выстроить рабочие процессы. 

На тот момент в команде:

• Не было единой методологии — ни канбана, ни скрама. Была примитивная доска в Jira с тремя столбцами: «В очереди», «В работе», «Готово» и отдельный столбик с документацией.

• Не было единого канала поставки — входящих задач было много и они падали в работу хаотично. 

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

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

• Не было системного подхода к работе с приоритетами и декомпозицией задач. Всё держалось на опыте отдельных инженеров и разработчиков.

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

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

Выбор методологии

Мы выбрали классический Kanban, потому что:

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

• В бэклог попадает всё — от мелких доработок до проектов, которые длятся месяцами. Мы одновременно работаем над развитием инфраструктурных сервисов, внедрением новых технологий, и действуем как поддержка и центр экспертизы для команд разработки, постоянно реагируя на их запросы.

• Запросы поступают постоянно, и решить, какие из них попадут в текущий спринт, а какие в следующий невозможно — они все срочные. 

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

Kanban в этом плане подошёл нам больше: 

• Не требует жёсткой привязки к итерациям.

• Позволяет управлять непрерывным потоком задач и гибко реагировать на новые приоритетные задачи.

• Саму систему можно корректировать и подстраивать под требования или пожелания в любой момент.

• Благодаря визуализации команда видит, что происходит прямо сейчас. У всех участников есть доступ к информации о задачах в реальном времени.

Чтобы внедрить методологию и использовать Kanban максимально эффективно в интересах задач, которые стоят перед командой, мы решили использовать метод STATIK. Но не в том виде, как описано в гайде, а расширив его на несколько обязательных для нас шагов.

Как работает классический STATIK 

STATIK (Systems Thinking Approach to Introducing Kanban) — системный, итерационный подход к внедрению методологии Kanban. 

Классический S.T.A.T.I.K включает 7 шагов:

1. Обсуждение и поиск предназначения команды.

2. Выявление внутренних и внешних источников неудовлетворенности.

3. Анализ спроса и возможностей (составление списка задач).

4. Моделирование рабочего процесса / описание жизненного цикла (флоу команды).

5. Выявление классов обслуживания.

6. Проектирование / дизайн системы (создание доски).

7. Договорённости и запуск.

В целом такой подход работает хорошо и проверен многими командами. Но с учётом нашей специфики, мы решили добавить несколько дополнительных пунктов.

Как было реализовано у нас

Мы взяли за основу классический STATIK, но вместо одной марафонской сессии на 12 часов провели серию из 10 коротких, но очень продуктивных встреч по часу в течение двух месяцев. Это позволило лучше сохранять фокус и вовлечённость всех членов команды.

Двигались по этапам, добавляя собственные пункты (помечу их звездочкой*):

1. Обсуждение предназначения. Сформировали и зафиксировали общее понимание, зачем существует команда, какую ценность создаёт и для кого.

2. Выявление источников неудовлетворённости. Составили список внутренних проблем. У нас это были:

• нехватка рук и компетенций;

• некорректная оценка сроков;

• отсутствие единого окна ведения задач;

• много legacy и проблемы с передачей знаний;

• дефицит документации;

• нарушенные каналы взаимодействия с другими командами и т.д.

С внешними источниками проблем не обнаружили — большинство прямых клиентов (разработчики) оценили работу на 4 и 5 по пятибалльной шкале из опроса, дополнив ответы положительными комментариями. Но позже я всё-таки вернулся к ним, чтобы получить более детальную обратную связь (шаг 10*).

1. Анализ спроса. Составили список задач, с которыми сталкивается команда, и сделали классификацию по типам работ. Раскрыли каждый тип и дали подробное пояснение:

• Откуда приходит?

• Как часто появляется?

• Насколько обычно ясна формулировка запросов?

• Есть ли цикличность или паттерны появления?

• Есть ли дедлайн?

• Насколько у нас достаточно данных для решения подобных запросов?

• В каком формате нужен результат / ожидания заказчика?

• Какая сложность (по шкале от 1 до 10)?

2. Моделирование рабочего процесса: для каждого типа работ расписали цепочку шагов — от поступления ТЗ до результата. 

* Согласно классическому гайду STATIK, цепочку шагов (жизненный цикл) нужно писать в том виде, как есть сейчас, учитывая все нюансы. Мы же фиксировали текущее состояние, но при этом ещё отмечали зоны роста в конкретных шагах: как мы хотим, чтобы было на этом этапе.

3. Определение классов обслуживания. Классифицировали типы работ по четырём стандартным классам Kanban:

• срочные (Expedite);

• с фиксированной датой (Fixed Date);

• регулярные (Standard);

• нематериальные (Intangible).

К каждому классу добавили правила обработки и приоритеты.

4. Метрики системы*: определили, какая аналитика нам нужна и составили дашборд (расскажу об этом подробнее в следующем блоке).

5. Адаптация и применение элементов унифицированного подхода*: после того, как мы определились с метриками, важно было провести сверку с унифицированной моделью. На момент разработки и внедрения нового воркфлоу в Точка Банк шла работа по проекту унификации и созданию единого дашборда с процессными метриками для команд.

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

Мы были первыми, кто адаптировали унифицированный подход под инфраструктурную (сервисную) команду, чтобы собирать данные в общий дашборд Power BI.

8. Дизайн системы: на основе собранных данных спроектировали канбан-доску в Jira, добавили активные и буферные статусы. 

9. Социализация и запуск: провели финальные встречи и проговорили договорённости с командой. Для удобства сделали памятку, как правильно вести задачи на новой доске.

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

Можно сказать, что это расширенная версия шага №2. Но вместо массовых опросов в Google Forms, которые обычно дают низкую конверсию, провел личные беседы и встречи с наиболее опытными ребятами (роли TeamLead, TechLead, Архитектор), а те в свою очередь могли дополнительно собрать данные в своих командах. Результаты свёл в таблицу и обсудил с командой на отдельной ретро.

Наши метрики

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

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

Раньше при необходимости мы пользовались только стандартными отчётами Jira, среди которых есть:

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

• количество созданных задач за период;

• количество задач, решённых за тот же период; 

• количество времени, затраченное на решение задач. 

С командой мы сгенерировали метрики, которые помогают видеть, как изменения влияют на процесс.

Процессные метрики:

• Длительность нахождения задач в каждом статусе.

• Время нахождения задачи в блоке.

• Cycle Time.

• Lead Time.

• Time To Learn.

• Кумулятивная диаграмма потока.

• Процент незавершённых задач.

Командные метрики:

• Динамика количества рабочих элементов по типам: количество незавершённых рабочих элементов; количество завершённых элементов; количество неактивных рабочих элементов; отношение неактивных к активным; соотношение рабочих элементов в очереди и вне её; соотношение элементов в ожидании и в работе.

• Распределение рабочих элементов по времени выполнения.

• Длительность производственных этапов.

• Длительность статусов.

• Количество отменённых задач.

• Метрики по приоритетам: среднее время задач, проведённое в приоритете; средняя длительность приоритета; количество задач по приоритетам;

• Метрики возврата (например, из «Тестирования» в «Разработку»).

• Bus Factor: количество задач по сервисам и исполнителям.

Эти метрики — зеркало процесса. Благодаря им можно принимать решения на основе фактов, а не предположений, и прогнозировать загрузку команды.

Что поменялось после внедрения Kanban

На внедрение Kanban ушло около трёх месяцев: два — на проработку STATIK, ещё месяц — на проработку обратной связи и корректировки, фиксацию договоренностей, а также решение технических вопросов при подготовке нового воркфлоу в Jira и переходе. Сам переезд прошёл за один день.

Команда была готова к изменениям, но в первые недели возникали вопросы. Мы обсуждали их сразу, чтобы снять напряжение. И вообще вводили все нововведения под девизом «давайте попробуем». Ребята знали, если что-то пойдет не так, в любой момент можно откатиться обратно.

В результате мы получили:

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

• Визуализацию процесса. В реальном времени видим загрузку каждого участника и статусы задач.

• Контролируемый WIP. Видим отношение незавершённых задач к активным, что позволяет избежать перегрузок и оптимизировать процессы.

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

• Единый канал поступления задач. Всё фиксируется в Jira, что исключает потерю информации. Даже если кто-то пишет в личку, отправляем в общий канал.

На доске тоже произошли качественные изменения: 

• Появилось цветовое распределение элементов и разные типы: техдолг, ошибки, задачи, подзадачи, эпики, операционные задачи;

• Появились свимлайны для срочных задач, чтобы видеть их количество и статус;

• Каждая задача стала привязана к конкретному инфраструктурному сервису;

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

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

На что обращать внимание, когда меняешь сложные процессы

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

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

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

• Двигаться небольшими шагами. Не пытайтесь нырнуть с головой в масштабные изменения. Мы начинали с лёгких доработок: добавили несколько статусов в Jira, настроили WIP-лимиты, сделали цветовое кодирование элементов. Это был своего рода «мини-канбан», который помог оптимизировать процессы и понять, как команда реагирует на изменения.

• Чётко определить цель. Важно, чтобы все перемены были направлены на решение конкретных проблем, а не просто делались, чтобы попробовать что-то новое. 

• Дать время на адаптацию. Первые два месяца показатели могут скакать — это нормально. Команде нужно время, чтобы привыкнуть к новым правилам. В этот период важно собирать обратную связь и оперативно вносить изменения.

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

• Уважать команду. Слушайте мнение каждого и старайтесь подстроить процессы под команду, а не наоборот.

Сам Statik для внедрения Kanban показал себя хорошо. Но важно не бояться дорабатывать подход под себя. Не всегда стандартные методы будут работать, особенно, если речь идёт о специфических командах.

Как понять, что после твоих действий стало лучше, чем было

Это главный вопрос, который стоит задать себе спустя два–три месяца после внедрения изменений. Чтобы оценить результат:

• Проверьте, достигнуты ли поставленные цели и решены ли актуальные проблемы — это первый и самый объективный критерий успеха.

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

• Посмотрите метрики. Когда процессы устаканятся, можно проанализировать количественные показатели — например, объём незавершённой работы, время решения задач и т.д.

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

Ещё регулярно обращаются коллеги из других направлений, которые видели наш результат в Devexp и теперь хотят масштабировать его на свою команду. Мы уже используем этот опыт у Linux-администраторов, сетевых инженеров. Это тоже признак того, что изменения были положительными.