Источник: Kanban Podcast
Гость выпуска: Даулет Нигметов, Agile Delivery Manager и управляющий партнер Agile-школы The4School.
Тема: Реальный кейс масштабирования Канбан-метода в казахстанской компании, название которой, увы, под NDA. Но суть — куда важнее названия.
Кто такой Даулет?
Даулет — человек с данными в крови. Начинал карьеру как аналитик: Excel, Power BI, цифры, графики, всё строго по делу. Потом перешёл в проектный офис, где впервые столкнулся с Agile-подходами. Там и случился первый контакт со Scrum и Kanban. С тех пор Даулет не просто в теме — он прокладывает путь другим: помогал трансформировать команды и целые организации, работал как внутри компаний, так и в консалтинге, а теперь развивает Agile-экспертизу на рынке Казахстана через The4School.
Кейс: масштабирование Канбан-метода
Исходная точка:
Компания уже «варилась» в Agile — Scrum-фреймворки были внедрены, Agile-майндсет формировался. Но до полного счастья не хватало прозрачности. Особенно в сервисных функциях, где множество команд обслуживали сразу несколько внутренних заказчиков.
Главная боль:
— Где моя задача?
— Кто за это отвечает?
— Когда мы это получим?
Знакомо, правда? Не хватало общей картины. Бизнес жаловался на скорость, команды — на перегруз, а все вместе — на непрозрачность. Было понятно: нужно не просто «внедрить Канбан в команду», а выйти на уровень масштабирования процессов между несколькими функциями.
Что послужило триггером?
Даулет называет это «недовольством бизнеса». Классика жанра. Когда time-to-market начинает буксовать, а ожидания не совпадают с результатом — компании начинают двигаться. Или паниковать. В этом случае — двигаться.
Команды уже использовали Канбан по отдельности, но оказалось, что этого мало. Когда над одной задачей работают сразу несколько подразделений, всё превращается в разрозненный пазл. Не хватает ответственного, не хватает визуализации, не хватает взаимопонимания.
И тогда пришла мысль: пора смотреть шире, выстраивать систему не на уровне отдельных команд, а на уровне всего сервиса.
Почему не SAFe?
Логичный вопрос — если масштабы растут, может пора переходить на SAFe? Даулет объясняет, почему нет:
- Команды были не «фичевые», а сервисные. То есть они не создавали продукты, а выполняли запросы от бизнеса. Поэтому сложно было выстроить value stream’ы под одного пользователя или направление.
- Дорого и долго. Полноценная SAFe-трансформация требует подготовленных людей (SPC, RTE, скрам-мастера), долгой подготовки и бюджета. А бизнес хотел изменений уже вчера.
- Не тот тип задач. SAFe хорош для продуктовой разработки. Здесь был постоянный поток задач от разных заказчиков.
Рассматривали ли другие фреймворки?
Да. В ход пошли все масштабируемые фреймворки: LeSS, Nexus и так далее. Но у каждого из них — свои ограничения. Например, LeSS хорош, если у команд есть высокая автономия, чего здесь не было: корпоративная структура, вертикальные связи, кросс-функциональные зависимости — всё как положено в большой организации.
Так родилась идея собственного масштабируемого решения на базе Канбан.
Канбан как связующее звено
Когда мы начали настраивать Канбан для команд, стало понятно: нужно не просто доску нарисовать, а выстроить рабочую систему. Тут и появился ключевой инструмент — STATIK (Systems Thinking Approach To Introducing Kanban). Именно с его помощью мы:
- анализировали контекст каждой команды;
- помогали сформулировать ожидания и потребности;
- строили рабочий процесс, основанный на реальных потоках работы;
- задавали правила, лимиты, роли, встречи, и все остальные важные аспекты.
Короче говоря, не просто «перетащи карточку», а цельная система работы.
Каждая команда получила свой канбан уровня ML2 — командного уровня зрелости (в терминах Kanban Maturity Model). У них появились внутренние каденции, расписание ретро, правила взаимодействия. Всё это — не «по принуждению», а в формате помощи и развития.
Как связать команды, если доски разные?
Вот тут началось веселое. Очевидное решение — просто «отразить» задачу между досками. То есть одна команда создала задачу, другая ее видит у себя. Это называется reflection.
Но на практике — сложно:
- У всех разный workflow.
- Кто-то привык работать через пять этапов, у кого-то их десять.
- У каждой команды своя специфика, свои смыслы.
Если всё унифицировать до «To Do – In Progress – Done», то получится мёртвая доска, которая не несет ценности. Поэтому мы отказались от прямой синхронизации досок.
Вместо этого — материнская доска
Всё взаимодействие пошло через одну основную доску, которая жила в Jira Service Desk. Это и был тот самый «клей», скрепляющий всю систему. Команды продолжали работать в своих привычных пространствах, но данные с их досок агрегировались и отображались на материнской доске.
Что это дало?
- Прозрачность на всех уровнях.
- Возможность не дергать команды по статусу задач.
- Контроль за всем процессом, включая ожидания, задержки, узкие места.
А как же системное внедрение?
Да, STATIK помог нам не просто «натянуть Канбан», а встроить его в реальную жизнь команд. Мы провели анализ запросов, построили карты потоков, определили источники входящей работы, ограничили WIP (Work In Progress), сформировали каденции и роли.
Причём всё это не выглядело как «доска на стене», а было полноценной управленческой системой:
- понятной;
- прозрачной;
- адаптивной.
Каждая команда видела смысл в том, что делает, и как она связана с другими.
Что дальше?
Ну, во-первых, у нас появилась реальная метрика производительности, о которой расскажу в следующей части. Но уже на этом этапе бизнес увидел:
- сколько времени реально проходит от запроса до результата;
- где происходят задержки;
- какие команды загружены больше других;
- и самое главное — что вообще происходит без лишних писем и звонков.
И это уже был огромный шаг вперёд.
Если вы когда-то пытались выстроить end-to-end процесс в большой организации — знаете, насколько это может быть больно. Но с правильными подходами и немного упрямства — реально всё собрать в систему, которая не просто работает, а помогает всем участникам.
Лидерство, культура и зрелость: завершаем настройку масштабируемого Канбана
Раньше в команде всё было «по старинке»: задачи попадали к исполнителям сверху, кто-то просто «впихивал» их в работу, не особо задумываясь о потоке и приоритетах. Но после внедрения Канбана всё поменялось. Люди начали брать задачи осознанно, вытягивать их по мере готовности, а не ждать, пока кто-то спустит сверху. Это был важный знак зрелости и… да, лидерства.
Как говорил один из участников команды:
«Я не начну задачу, пока мне её реально не поставят. Не впихну сам — вытяну, когда всё будет готово».
Такой подход показал, что лидерство проявляется не в тайтле, а в поведении. Даже аналитики и разработчики стали управлять своим рабочим процессом — видеть цель, контролировать загрузку и принимать решения. Именно это и стало переломным моментом — не просто внедрение инструментов, а изменение культуры на всех уровнях.
К слову о культуре — это тоже важный элемент. Компания изначально декларировала ценности вроде Agility и клиентоцентричности, но они оставались на уровне «плакатов на стенах». После внедрения Канбана всё стало иначе. Ценности стали неотъемлемой частью принятия решений, ребята реально начали ими жить. Канбан помог встроить ценности в процессы — и это дало мощный буст для всей организации.
«Ценности — это не лозунги, это курсоры в принятии решений», — отметил Даулет.
Дальше — больше: благодаря практике визуализации, ограничению WIP, метрикам и потоку задач в JIRA, команды начали не просто видеть, где что застряло, но и улучшать процессы эволюционно. А ведь это и есть суть Канбана — двигаться от текущего состояния к лучшему без революций.
Финальный аккорд
Этот кейс — не просто история про JIRA, доски и метрики. Это история про то, как через настройку сервиса, развитие культуры и осознанное лидерство можно не только навести порядок в рабочих процессах, но и создать команду, которая реально тащит.
Хочется верить, что кейс станет полезным тем, кто только ищет свой путь в масштабировании Канбан. А если вы уже на этом пути — не останавливайтесь. Потому что как сказал Даулет:
«Самое худшее — это остановиться и сказать: у нас Канбан. Всё. Приехали».
Нет. Канбан — это путь. И он продолжается.
