Scrumban в product management — это гибрид Scrum и Kanban: вы оставляете ритм (планирование, ретро, понятные роли), но управляете потоком задач через лимиты WIP и визуальную доску, чтобы ускорить поставку и снизить «пожары» без фанатизма с двухнедельными спринтами.

Если вы меняли профессию и попали в IT, почти наверняка видели два сценария. Первый: «у нас Scrum», но половина команды живёт в чатике, задачи прилетают как снег в апреле, а спринт заканчивается переносом переносов. Второй: «у нас Kanban», что часто означает «тут просто список задач, удачи». Scrumban управление — это попытка перестать выбирать между карго-культом Scrum и бесконечной очередью Kanban. И да: это реально можно внедрить без хаоса, если не пытаться лечить процессом отсутствие целей и ответственности.

Тренд в том, что scrumban product management все чаще берут продуктовые команды с непрогнозируемым потоком запросов: поддержка, интеграции, легаси, b2b-согласования, «срочно для продаж». В вакансиях по РФ (product/project/analyst) в требованиях регулярно мелькают Agile/Scrum/Kanban, а на собеседовании почти всегда проверяют одно: умеете ли вы управлять потоком и ожиданиями, а не просто «вести Jira». Scrumban — как раз про это.

Если вам близок такой разбор — на https://itokno.ru есть и другие статьи про процессы, роли (Product Owner, Project Manager, BA) и карьерные треки без сказок про «вкат за 2 месяца».

Почему Scrumban вообще появился (и кому он нужен)

Тезис: Scrum ломается там, где входящий поток сильнее планов

Scrum держится на стабильности: команда набирает в спринт объём, который примерно умеет делать. Но в реальном продукте в России часто побеждает входящий поток: поддержка 1С-интеграций, отвалившиеся платежи, «срочно от юристов», релизы под требования маркетплейсов, а ещё руководитель увидел конкурента и захотел «как у них». В результате спринт превращается в фикцию: план есть, фактически — непрерывная смена приоритетов.

Практический вывод: если у вас каждые 1–3 дня прилетает «критично», Scrum можно оставить как набор встреч, но управление работой лучше перевести на поток и лимиты.

Подводный камень: многие делают наоборот — отменяют планирование и ретро, оставляя только доску. И потом удивляются, что качество и фокус падают.

Тезис: Kanban без правил — это «бэклог на 900 задач»

Kanban в чистом виде требует дисциплины: явные политики, лимиты незавершёнки (WIP), классы обслуживания (expedite, fixed date), работа с временем цикла. Но в компаниях часто внедряют «канбан» как синоним «не планируем». Итог — задачи висят месяцами, приоритеты меняются по настроению, и никто не может честно ответить бизнесу: «когда будет готово?»

Практический вывод: Scrumban как внедрить — начинайте не с «доски», а с правил: какие типы задач бывают и как они проходят систему.

Подводный камень: если вы не договорились о критериях готовности (Definition of Done), WIP-лимиты превращаются в игру «перетолкай задачу в следующий столбец».

Scrum vs Kanban vs Scrumban: что меняется в продуктовой работе

Здесь важный нюанс для новичков: в scrumban product management «гибкость» не означает «делаем как получится». Это означает: у вас есть система, которая допускает изменения, но не превращается в базар.

Как внедрить Scrumban: пошагово, без религиозных войн

Шаг 1. Опишите классы работы и политику срочности

Первая причина хаоса — все задачи «срочные». В Scrumban это лечится не героизмом, а классификацией.

• Expedite — тушение пожара (инцидент, оплата не проходит, прод упал).
• Fixed date — задача с дедлайном (например, требования регулятора или интеграция под окно партнёра).
• Standard — обычные фичи/улучшения.
• Intangible — техдолг/рефакторинг/наблюдаемость (то, что «не видно», пока не больно).

Практический вывод: ограничьте expedite: допустим, одновременно не больше 1 задачи на команду. Да, звучит нагло. Зато правда показывает бизнесу цену «срочно».

Подводный камень: если expedite становится «нормой», у вас не процесс плохой — у вас управление продуктом и приоритизация отсутствуют.

Шаг 2. Нарисуйте доску под поток, а не под должности

Типичная ошибка — колонки «Аналитик / Дизайн / Разработка / Тест». Это превращает доску в контроль людей. В Scrumban доска должна отражать состояние работы: «Готово к разработке», «В работе», «Готово к тесту», «На проверке», «Готово к релизу».

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

Подводный камень: слишком детальная доска (15 колонок) — это Excel-аддикция, а не управление потоком.

Шаг 3. Поставьте WIP-лимиты и договоритесь, что их нарушать стыдно

WIP (Work In Progress) — лимит задач «в работе». Смысл: меньше начатого, больше законченного. Для продуктовой команды часто работает грубая настройка: WIP = численность команды минус 1 (оставляем «пространство» под помощь и разбор блокеров).

Практический вывод: когда WIP переполнен — не «впихивайте». Остановитесь и разгребите блокеры. Это и есть антихаос.

Подводный камень: WIP-лимиты бессмысленны без права сказать «нет» или хотя бы «не сейчас» стейкхолдерам.

Шаг 4. Замените спринт на «пополнение по триггеру», но оставьте ритм

Вместо планирования на 2 недели используйте replenishment (пополнение): например, 2 раза в неделю вы выбираете, что пойдёт в работу дальше, исходя из приоритета и доступной мощности. Ретро (ретроспектива) оставьте раз в 2 недели: улучшения процесса не происходят сами, даже если у вас доска красивая.

Практический вывод: scrumban управление — это когда у вас регулярные точки принятия решений, а не «как пойдёт».

Подводный камень: если вы убрали Scrum-ритуалы полностью, вы потеряете обучение команды и превратите процесс в операционку.

Шаг 5. Введите flow-метрики, чтобы не спорить «на ощущениях»

Минимальный набор:

• Cycle time (время цикла): от «взяли в работу» до «готово».
• Throughput (пропускная способность): сколько задач закрываете за неделю.
• WIP: сколько задач одновременно в работе.

Практический вывод: прогноз делайте от throughput: «обычно закрываем 12 задач в неделю, значит 24 задачи — это примерно 2 недели». Это честнее, чем гадать по story points.

Подводный камень: мерить time-to-start (время до начала) и игнорировать его — классика. Очередь важна так же, как и выполнение.

Два кейса из российской практики: один удачный, один поучительный

Кейс 1 (удачный): B2B-сервис с интеграциями и «срочно от продаж»

Команда: 7 человек, продукт в B2B, интеграции с 1С, запросы от ключевых клиентов. Scrum не выдерживал: в каждый спринт «влетали» 3–5 срочных задач. Перешли на Scrumban: ввели expedite=1, replenishment по вторникам/пятницам, WIP «в работе» = 6, ретро раз в 2 недели. Через месяц стало видно: узкое место — согласования и тест, а не разработка. Подключили аналитику к подготовке задач и автоматизировали часть регресса. Результат — меньше незавершёнки и более предсказуемые сроки для клиентов (не магия, просто очередь стала управляемой).

Кейс 2 (неудачный): «канбанизировали» хаос и назвали это Scrumban

Команда в финтехе (в духе «у нас свои процессы») убрала спринты, оставила доску в Jira и ежедневные стендапы. WIP не ввели, expedite не ограничили, DoD не определили. Через 2 месяца: 40 задач «в работе», релизы реже, люди выгорают, руководитель просит «вернуть Scrum». Проблема была не в методологии, а в отсутствии правил потока и ответственности за приоритет.

Коммерческие факторы: сколько стоит внедрение

Scrumban можно внедрить без платных курсов: нужны доска (Jira/YouTrack/Trello, у многих — Kaiten; в корпорациях бывает и Azure DevOps), 2–4 недели на настройку правил и 1–2 месяца на стабилизацию метрик. Если идти через обучение, по рынку РФ типовые цены: корпоративные воркшопы и тренинги по Agile/Канбану часто лежат в диапазоне 30–150 тыс. ₽ за короткий интенсив для группы, а длинные программы про управление продуктом — 60–200+ тыс. ₽ (и там Scrumban будет лишь кусочком).

Скрытая цена обычно не в обучении, а в том, что никто не выделил время на:

• описание Definition of Done и критериев готовности;
• разбор «что такое срочно» и кто это утверждает;
• регулярное replenishment (это встречи, да);
• сбор flow-метрик и разбор причин задержек.

Экспертный вердикт и инструмент: мини-чеклист внедрения Scrumban

Если коротко: scrumban product management работает, когда у вас смешанный поток (фичи + внезапные задачи) и вы готовы управлять очередью, а не героизмом.

1. Есть ли у нас явные классы задач (standard/expedite/fixed date/tech)? Если нет — начните с этого.
2. Ограничили ли мы expedite до 1 задачи одновременно? Если нет — вы сами выбираете хаос.
3. Есть ли WIP-лимиты хотя бы на «в работе» и «тест»? Если нет — ждите многозадачность и вечные хвосты.
4. Есть ли replenishment по расписанию (например, 2 раза в неделю)? Если нет — приоритеты будут определяться громкостью голоса.
5. Считаем ли мы cycle time и throughput хотя бы раз в неделю? Если нет — прогнозов не будет, будут обещания.
6. Определили ли DoD (что значит «готово»)? Если нет — «почти готово» станет вашим брендом.
7. Есть ли ретро раз в 2 недели? Если нет — процесс деградирует, даже если начинали красиво.

Частые вопросы