Kanban-система с нуля с помощью S.T.A.T.I.K.
Как внедрить Kanban-метод в работу, если команда с ним еще не знакома? Легко! С помощью метода S.T.A.T.I.K
Чтобы разобраться с методологией Kanban и построить систему организации задач с нуля, погрузимся в контекст Kanban-метода вместе с Максимом Якубовичем, экспертом по Agile и продуктовому подходу, партнером Product Lab. Разберемся, что такое S.T.A.T.I.K. и как с его помощью строить систему, а также рассмотрим конкретный кейс внедрения метода на примере Kaiten.
Что такое Kanban-метод: принципы и область применения
Kanban-метод — управленческий подход, который позволяет управлять и улучшать производственные системы. Его главная цель — сделать работу команды понятной и управляемой, а процессы — предсказуемыми.
Благодаря этому методу команда видит и контролирует, на каком этапе находится работа, кто за нее отвечает и где могут возникнуть узкие места. На одной доске отражены все задачи команды: от идеи до финальной реализации.
Kanban не навязывает единственно правильный способ организации работы — его можно адаптировать под любой текущий способ выполнения задач.
В каких сферах может применяться Канбан-метод:
- работа компаний из IT-отрасли,
- работа отдела маркетинга и продаж,
- издательская деятельность,
- работа HR-специалистов,
- организация работы дизайнеров и иллюстраторов.
У Kanban, как у и Scrum, есть свои ценности, принципы и практики.
Принципы Kanban-метода
Принципы Kanban можно разделить на две большие группы.
Первая группа: управление изменениями
Когда мы пытаемся что-то изменить в наших процессах, люди сопротивляются. Поэтому главный принцип в этой группе — начните с того, что есть сейчас. Это позволяет не ломать то, что уже работает.
Перед внедрением метода договоритесь с командой об эволюционном развитии. Это позволит постепенно менять процессы. Никаких революций, никаких резких телодвижений — аккуратное, четкое движение вперед с точки зрения улучшения процесса.
Почему нужно начинать с того, что работает уже сейчас:
- Это сводит сопротивление к переменам к минимуму, ведь на первое время для команды сохраняются текущие правила и процедуры.
- Изменения лучше внедрять эволюционно — так у сотрудников будет больше понимания, для чего внедряют новые подходы.
Сначала смотрим, как работает команда, и только потом предлагаем изменения. Некоторые практики приживутся, а некоторые будут забыты — это нормальный процесс.
Вторая группа: сервисная парадигма
Сервисная парадигма — взгляд на любую деятельность, как на определенный вид сервисов. В этой парадигме команда всего лишь способ организации. Это помогает определить заказчиков, их ожидания, неудовлетворенности.
Например, важно разделять сервисы на внутренние и внешние. Во внутреннем сервисе заказчиком выступает внутреннее подразделение компании. А во внешнем — не относящийся к компании человек либо юридическое лицо.
Основные практики Kanban-метода
Разберем практики Kanban-метода. Их всего 6: визуализация, WIP-лимиты, управление потоком, прозрачные правила работы, циклы обратной связи, постоянные улучшения и эволюция.
Визуализация
Главный принцип Kanban — сделать рабочий процесс максимально прозрачным. Визуализация позволяет увидеть весь поток задач: от момента поступления до завершения.
Как это можно реализовать: используйте визуальные элементы, такие как метки, цвета и флажки, чтобы выделить приоритетные задачи или срочную работу. Например, Kaiten предлагает встроенные инструменты для этого.
WIP-лимиты
Согласно исследованию Джеральда Вайнберга, при переключении между 2 проектами или заданиями, мы теряем 20% времени, которое тратим на работу. Если проектов 3 — теряем уже 40% времени.
Чтобы избежать траты времени и ресурсов на подобное переключение между задачами, команда может использовать WIP-лимиты. Это максимальное количество задач, которое может находиться в работе одновременно.
В Kanban важно ограничивать это число, чтобы команда не бралась за задачи, которые не способна выполнить вовремя из-за перегрузки. Ограничение задач есть не на всех Kanban-досках, и это может быть серьезным минусом в работе таск-трекера.
Как выстроена работа с WIP-лимитами в Kaiten: цифры в правом верхнем углу — установленный WIP-лимит и число задач, которые сейчас находятся в колонке. Например, сейчас в колонке установлен лимит в три задачи. Сейчас в ней уже находится две карточки с поручениями:
Когда появится третья задача в колонке, значение WIP-лимита изменится на «3/3» и станет оранжевым. При четвертой задаче Kaiten покажет, что превышен WIP-лимит, и значение станет красным.
Обязательства в Kanban-системе
Момент, когда команда берет на себя обязательства по исполнению запроса, называется точкой принятия обязательств. А момент, когда команда выполнила свои обязательства, — точкой отдачи обязательств.
- До точки принятия обязательств задачи анализируются, уточняются и приоритизируются.
- После точки принятия обязательств задача переходит в работу и команда несет ответственность за ее выполнение.
Метрика между двумя этими моментами называется Lead time, или время производства. Это время, которое проходит с момента принятия обязательств какой-то команды на себя до момента выпуска результата по этим обязательствам.
Управление потоком
Цель этой практики — обеспечить стабильный и предсказуемый поток задач. Это происходит за счет:
- уменьшения Lead Time;
- равномерного распределения нагрузки между членами команды;
- исключения простоев или перегрузки на отдельных этапах.
Ясная политика и правила
Для эффективной работы команде нужно заранее договориться о правилах:
- Какие задачи важнее — как их приоритизировать?
- Что делать, если возникает блокировка?
- Когда задача считается завершенной?
Они должны быть закреплены на доске, чтобы все участники процесса видели их и не забывали. Пример таких правил:
- рабочие элементы в колонке «Готово» не должны задерживаться более 5 дней;
- рабочие элементы не могут перемещаться в столбец «Тест», пока они не пройдут ревью и не будут продемонстрированы всей команде.
Циклы обратной связи
Обратная связь — обязательный элемент любой системы управления. Если у нас нет обратной связи, мы не можем управлять каким-то объектом.
Варианты обратной связи:
- устное общение двух людей, например, встреча один-на-один, где они обсуждают процесс;
- отправка отчетов о метриках процесса;
- визуально оформленные дашборды;
- собрания, где обсуждаются какие-то метрики процесса.
Как это может выглядеть в Kaiten: есть отчеты для аналитики, которые помогут оценить эффективность работы и предложить улучшения.
Руководитель проекта может на основе подобной отчетности давать обратную связь по работе сотрудникам.
Что такое S.T.A.T.I.K и как его построить
Когда вы знакомитесь с принципами Kanban-метода, всё выглядит просто: нужно визуализировать задачи, ограничить работу в процессе (WIP-лимиты) и проанализировать поток задач. Но всё равно возникают трудности при адаптации метода под реальные процессы команд.
Например, в команде стоит задача улучшить определенный процесс работы. С чего начать? Лучшее, что можно внедрить — S.T.A.T.I.K. Этот инструмент поможет вам визуализировать поток поставки ценности, создать первую доску для работы по Kanban и написать первое правило.
S.T.A.T.I.K. учитывает особенности текущего рабочего процесса, позволяя сразу повысить эффективность. Как это сделать:
- Определить предназначение сервиса (fit for purpose).
- Определить источники неудовлетворенности текущим сервисом поставки.
- Проанализировать источники и природу запросов.
- Проанализировать текущие возможности поставки.
- Смоделировать рабочий поток сервиса поставки.
- Идентифицировать и определить классы обслуживания.
- Спроектировать Kanban-систему.
- Найти инструмент для реализации дизайна системы и применить его.
Дальше разберем конкретные шаги на примере инструмента Kaiten.
Как внедрить Kanban-метод и S.T.A.T.I.K. в работу команды
Сначала определяем, кого можно считать заказчиками процесса:
- Кто наши заказчики?
- Как эти люди понимают, что работа сделана хорошо?
В Kaiten можно увидеть заказчика, который разместил очередную заявку для команды, а также — оценку работы. Ее ставит заказчик после завершения работы над задачей.
После определения заказчиков процесса мы определяем источники неудовлетворенности. Их можно разделить на 2 типа:
- внутренние — проблемы внутри нашей системы;
- внешние — недовольства внешних заказчиков и стейкхолдеров.
Эти запросы мы можем типизировать, чтобы понять природу выполнения и источник возникновения. Для этого можно использовать понятие WiT (Тип рабочего элемента) — разделение рабочих элементов по источнику возникновения запросов и/или особенностям реализации.
Пример типизации запросов: заказчики просят добавить новые функции продукта, а служба поддержки — исправить ошибки. Тогда можно разделить запросы на два типа рабочих элементов: новые функции и исправление ошибок.
Классы обслуживания
В работе с любой задачей есть разделение на классы обслуживания:
- Ускоренные — рабочие элементы, которые требуют немедленного внимания, вынуждая команду отложить другие задачи.
- Привязанные к срокам — такие задачи имеют жестко заданную дату выполнения, а их несвоевременная сдача приведет к потерям или штрафам.
- Стандартные — элементы, которые выполняются в порядке очереди, согласованной с заказчиком или внутренними процессами команды.
- Нематериальные — задачи, по которым трудно оценить бизнес-эффект количественно. Это низкоприоритетный класс обслуживания, и команда будет им заниматься тогда, когда останется время.
В Kaiten это всё реализуется и поддерживается через дорожки — свимлайны.
Какие элементы должны быть в любой Kanban-системе
В любой Kanban-системе можно найти следующее рабочие элементы:
- типы работ,
- классы обслуживания,
- жизненные циклы запросов,
- дизайны стикеров,
- дизайн доски,
- первичные договоренности.
Пример классической Kanban-доски в Kaiten, которая состоит из колонок «To do», «In progress» «Done». Есть и более сложные доски, к которым добавляются дорожки-свимлайны.
Иногда на досках создают колонки-буферы. Зачем нужны такие колонки:
- Если на одной стадии, которая находится справа от колонки с буфером, специалист освободился, то он видит, какие задачи из колонки «Готово» можно перетянуть на свой этап.
- Если использовать доску без буферов, то невозможно передвинуть задачу, если на стадии справа нет свободного слота. Это нельзя сделать, даже если на одной стадии задача готова.
Для этого и нужен WIP-лимит на 2 колонки одной стадии.
Горизонтальное деление доски на дорожки можно использовать для распределения задач по:
- типу работы;
- классу обслуживания;
- заказчикам;
- проектам.
Важен и дизайн карточки: если информация не помещается на доску, ее можно поместить на карточку. Она может быть сложной и включать в себя много разных элементов: название, тип, участников, дедлайн, метку приоритетности, оценку, чек-лист с прогрессом, файлы и другую информацию.
Когда создается карточка, нужно на старте определить, какие данные нужно вывести на лицевую сторону. Много всего добавлять не нужно — иначе карточка будет перегружена. Часть данных должна быть внутри карточки, часть — на лицевой стороне.
Доска должна отображать то, как устроен процесс сегодня в той команде, где улучшаются эти процессы.
Метрики в Kanban-методе
В Kanban 6 ключевых метрик:
Также в Kanban-системе есть две важные составляющие: стадия Discovery, когда происходит какое-то исследование перед стартом работы, и стадия Delivery, когда происходит реализация.
В этом методе есть 2 обязательные роли.
Первая — Service Request Manager, который формирует работу на стадии Discovery. Он организует заказчиков, чтобы они договаривались между собой и перетягивали самые важные задачи из своего бэклога в Delivery.
Вторая роль — Delivery Manager, который отвечает за поставку ценности продукта с момента взятия задачи в работу до выпуска результата.
Совещания в Kanban и анализ метрик
Также в Kanban-методе есть совещания, но, в отличие от Scrum, они не обязательные. Их можно разделить на 2 типа:
- для функционирования сервиса — Kanban-митинг, обзор сервиса поставки, собрания по пополнению;
- для развития сервиса — обзор поставки, рисков и операционный обзор.
Для проведения совещаний и анализа данных по сервису компании используют диаграммы и отчеты. Например, накопительная диаграмма потока позволяет быстро понять, где и на каком этапе оказания сервиса возникают в данный момент проблемы.
По толщине зоны разработки здесь можно понять, что по сервису всё в порядке, очередь уменьшается, в разработке всё меньше задач. Если в бэклог не поступают новые задачи из реализации проекта по Kanban-методу, то с помощью накопительной диаграммы можно спрогнозировать, когда мы закончим задачи из нашего бэклога.
Заключение и кейс применения S.T.A.T.I.K
Внедрить Kanban-метод в работу с нуля — сложная, но выполнимая задача. С этим команде поможет справиться метод S.T.A.T.I.K, который мы разобрали в этой статье.
