S.T.A.T.I.K.: как построить Kanban-систему с нуля

S.T.A.T.I.K. помогает спроектировать Kanban-систему с нуля, опираясь не на чужой шаблон, а на реальную работу команды. Разберём контекст метода, его принципы и практики, а затем последовательно пройдём путь от назначения сервиса и ожиданий заказчиков до структуры доски, классов обслуживания, метрик и встреч.

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

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

Kanban не задаёт единственно правильный способ организации работы — его удаётся настроить под любой текущий способ выполнения задач.

В каких сферах может применяться Канбан-метод :

У Kanban, как у и Scrum , есть свои ценности, принципы и практики.

Принципы Kanban можно разделить на две большие группы.

Когда мы пытаемся что-то изменить в наших процессах, люди сопротивляются. Поэтому главный принцип в этой группе — начните с того, что есть сейчас. Это даёт возможность не ломать то, что уже работает.

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

Почему нужно начинать с того, что работает уже сейчас:

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

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

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

Разберем практики Kanban-метода. Их всего 6: визуализация, Ограничение незавершённой работы , управление потоком, прозрачные правила работы, циклы обратной связи, постоянные улучшения и эволюция.

Главный принцип Kanban — сделать поток работы максимально прозрачным. Визуализация рабочего потока даёт возможность увидеть весь поток задач: от момента поступления до завершения.

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

Согласно исследованию Джеральда Вайнберга , при переключении между 2 проектами или заданиями, мы теряем 20% времени, которое тратим на работу. Если проектов 3 — теряем уже 40% времени.

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

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

Как выстроена работа с WIP-лимитами в NUBL : цифры в правом верхнем углу — установленный WIP-лимит и число задач, которые сейчас находятся в колонке. К примеру, сейчас в колонке установлен лимит в три рабочие элементы. Сейчас в ней уже находится две карточки с поручениями:

Когда появится третья рабочий элемент в колонке, значение WIP-лимита изменится на «3/3» и станет оранжевым. При четвертой задаче NUBL покажет, что превышен WIP-лимит, и значение станет красным.

Момент, когда команда берет на себя обязательства по исполнению запроса, называется точкой принятия обязательств. А момент, когда команда выполнила свои обязательства, — точкой отдачи обязательств.

Метрика между двумя этими моментами называется Lead time , или время производства. Это время, которое проходит с момента принятия обязательств какой-то команды на себя до момента выпуска результата по этим обязательствам.

Цель этой практики — обеспечить стабильный и предсказуемый поток задач. Этому помогают:

Чтобы работа оставалась управляемой участникам стоит заранее договориться о правилах:

Они нужно сделать закреплены на доске, чтобы все участники процесса видели их и не забывали. Пример таких правил:

Обратная связь — обязательный элемент любой системы управления. Если у нас нет обратной связи, мы не можем управлять каким-то объектом.

Варианты обратной связи:

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

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

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

К примеру, в команде стоит рабочий элемент улучшить определенный процесс работы. С чего начать? Лучшее, что можно внедрить — S.T.A.T.I.K. Этот инструмент поможет вам визуализировать поток поставки ценности, создать первую доску для работы по Kanban и написать первое правило.

S.T.A.T.I.K. учитывает особенности текущего рабочего процесса, позволяя сразу повысить эффективность. Как это сделать:

Теперь рассмотрим конкретные шаги на примере инструмента NUBL.

Вначале определяем, кого можно считать заказчиками процесса:

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

После определения заказчиков процесса мы определяем источники неудовлетворенности. Их можно разделить на 2 типа:

Эти запросы мы можем типизировать, чтобы понять природу выполнения и источник возникновения. Для этого можно использовать понятие WiT (Тип рабочего элемента) — разделение рабочих элементов по источнику возникновения запросов и/или особенностям реализации.

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

В работе с любой задачей есть разделение на классы обслуживания:

В NUBL это всё реализуется и поддерживается через дорожки — свимлайны.

В каждой Kanban-системе можно найти следующее рабочие элементы:

Пример классической Kanban-доски в NUBL, которая состоит из колонок «To do», «In progress» «Done». Есть и более сложные доски, к которым добавляются дорожки-свимлайны.

Иногда на досках создают колонки-буферы. Зачем нужны такие колонки:

Для этого и нужен WIP-лимит на 2 колонки одной стадии.

Горизонтальное деление доски на дорожки можно использовать для распределения задач по:

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

При создании карточка, нужно на старте определить, какие данные нужно вывести на лицевую сторону. Много всего добавлять не нужно — иначе карточка будет перегружена. Часть данных должна быть внутри карточки, часть — на лицевой стороне.

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

В Kanban 6 ключевых метрик:

Lead time

Время от взятия запроса в работу до передачи его заказчику

Throughput

Количество запросов, реализованных в единицу времени

Touch Time

Суммарное время, которое кто-то касался карточки — брался за реализацию запроса (не равно сумме трудозатрат)

Flow Efficienty

Процент от времени производства, когда кто-то работал над запросом

Resource Efficienty

Процент рабочего времени, в которое ресурсы реально работают

WIP

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

Кроме того в Kanban-системе есть две важные составляющие: стадия Discovery , когда происходит какое-то исследование перед стартом работы, и стадия Delivery , когда происходит реализация.

В этом методе есть 2 обязательные роли.

Первая — Service Request Manager , который формирует работу на стадии Discovery. Он организует заказчиков, чтобы они договаривались между собой и перетягивали самые важные рабочие элементы из своего бэклога в Delivery.

Вторая роль — Delivery Manager , который отвечает за поставку ценности продукта с момента взятия рабочие элементы в работу до выпуска результата.

Кроме того в Kanban-методе есть совещания, но, в отличие от Scrum, они не обязательные. Их можно разделить на 2 типа:

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

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

Запустить Kanban-метод в работу с нуля — сложная, но выполнимая рабочий элемент. С этим команде поможет справиться метод S.T.A.T.I.K, который мы разобрали в этой статье.

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