Привет, меня зовут Михаил Горбуля, product owner Polymatica BI. За два года работы над данным продуктом я смог из набора разрозненных договоренностей выстроить устойчивую систему работы, состоящую из пяти практик. Они позволяют одновременно справляться с потоком поддержки, который требует гибкости и мгновенной реакции, и сохранять предсказуемость разработки, без которой не бывает релизов и довольных заказчиков.
Если на один из пунктов ниже вы ответите да — статья будет вам полезна.
Вы — заказчик или внедренец: вы не можете чётко сказать клиенту, в какой версии будет выпущенная нужная ему фича или исправление, и вынуждены отвечать «скоро».
Вы — разработчик: вас постоянно дёргают срочными задачами, которые рушат все планы и убивают фокус.
Вы — поддержка: живёте в режиме тушения пожаров, а действительно важные баги тонут в очереди.
Вы — руководитель: у вас есть иллюзия «забитого спринта», которая разрушается в первый же день.
Наш Scrumban в трёх пунктах
Внешний мир (заказчики, внедренцы, смежные команды) получает чёткие релизы с версиями и датами (Scrum‑обёртка). Мы говорим: «В версии 5.12 будет X, и выйдет она 25 числа».
Внутренняя команда (разработка, тестирование) работает в едином приоритетном потоке (Kanban‑внутренность). Они не привязаны к спринтам, но у них есть жёсткое правило — брать следующую задачу только из топа очереди.
Релиз‑менеджер — не надсмотрщик, а хранитель очереди. Следит, чтобы приоритеты были расставлены адекватно, срочный кризис не ломал весь поток, а встраивался в него по правилам.
Ключевой принцип: мы заменили иллюзию «идеального спринта» на честность «реалистичного релиза». Не обещаем сделать всё и сразу — гарантируем только то, что действительно сделаем.
Я, в общем‑то, по этой шутливой схеме бобр‑менеджер. Я не внедрял Scrumban, а строил его вместе с командой. Так у нас появилось пять ключевых практик, которые, надеюсь, будут полезны и вам. Они не требуют одобрения руководства, тренингов или новых инструментов.
На мой взгляд, их можно применять и по отдельности — использование даже всего одной уже снизит хаос. Начните с той, которая актуальнее всего для вашей ситуации сегодня, и вы почувствуете, как поток задач становится управляемым.
Практика 1. Поймите, кому нужны дедлайны и зачем
Не все люди в компании живут в одном ритме — это нормально. Первый шаг — поделить ключевых участников на две группы в зависимости от их потребностей. Для этого спросите, что для них важнее — чёткая дата или гибкость? Запишите ответы без оценки, даже если они противоречат друг другу.
В итоге вы сможете определить две группы:
Те, кто нуждается в дедлайнах (для планирования, согласований, документации);
Те, кто нуждается в стабильности (чей фокус трясет больше всего из‑за срочных запросов).
Договоритесь с ними, что версия — это обещание внешнему миру. План на неделю — это стабильность для команды.
Почему это сработало у нас. Раньше все говорили «нам нужно планировать», но имели в виду разное. Приведу в качестве примера некоторые ответы коллег. Я не точно цитирую, а лишь передаю ключевые тезисы.
Департамент внедрения и поддержки: мы не можем вечно отвечать «скоро». Партнёры и заказчики теряют доверие. Нам нужно знать, в какой версии будет исправление, чтобы заранее согласовать обновление с клиентом.
То есть им важны даты и содержание релизов — это их способ управлять ожиданиями внешних сторон.
Технические писатели: если мы не знаем, что точно войдёт в версию 5.12, мы не можем подготовить релиз‑ноуты и обновить руководства. А если что‑то «почти сделано», но не попало в релиз — оно не должно попадать в документацию.
Им важна чёткая граница релиза: что входит, что откладывается, что отменяется.
Разработка: если вы каждый день будете менять приоритеты, мы ничего не сделаем качественно.
Им важна стабильность на ближайшую неделю и свобода реагировать на срочное без чувства вины
Одного этого разговора и последовавшей за ним договорённости хватило, чтобы снять 80% конфликтов. Этот подход не требует изменений в проджект‑трекере и одобрения руководства. Мы в своей команде стартовали именно с этой практики.
Практика 2. Введите дисциплину в поток: очередь — это не хаос, а порядок без иллюзий
Приоритеты работают только тогда, когда им следуют, иначе это просто список желаний.
Что делать:
Скройте основной бэклог от команды — пусть там остаются все 400+ задач, но они не мешают фокусу и не искушают взять тикет полегче.
Создайте видимый спринт‑бэклог «Selected» — 80–100 задач на месяц, отобранных вами как Product Owner и Project‑менеджером.
Расставьте задачи в Selected строго по приоритету: самое важное — сверху, «когда будет время» — внизу.
Внедрите правило: «Кто освободился — берёт первую задачу в очереди. Никаких исключений».
Запретите брать в работу задачи без оценки — если нет оценки, задача возвращается в основной бэклог до уточнения. Не как наказание, а чтобы сохранить прозрачность прогноза в Selected.
У нас нет «идеализированных спринтов», где команда сама решает, в каком порядке делать задачи. И это не недостаток — это сознательный выбор. На схеме ниже я отрисовал, как это живёт у нас.
Разработка видит только то, что вошло в Selected, и движется строго сверху вниз.
Если пришёл критичный баг — он встаёт в начало очереди, вытесняя менее важное. Также это не требует бросать задачу из прогресса — потому что брошенная задача создаёт больше шума, чем решённая.
Если пришёл обычный баг из поддержки, а в очереди Selected нечем пожертвовать (всё важное) — он определяется на следующую версию.
Если тимлид взял задачу, которая не в топе — это повод проверить приоритеты в очереди.
Если создана внутренняя задача и остается без оценки и ясной ценности — она не допускается в Selected, чтобы не нарушать баланс между срочным и важным.
Проектировщики работают с двумя типами задач:
срочные, от которых зависит следующий релиз;
перспективные: описание фичи на будущее — возьмём, когда освободится бэкенд (это осознанное откладывание за горизонт планирования, а не «забытая задача»).
Такой подход снимает «трясучку» у команд, потому что теперь все знают, что делать, в каком порядке и зачем.
Практика 3. Измеряйте то, что важно — и только это
Вы наверняка слышали фразу: «Невозможно управлять тем, что нельзя измерить». Мы проверили это на практике. Всё началось с того, мне надо было ответить на вопрос, как обещать заказчикам сроки, если не знаем, сколько «прилетит» из поддержки завтра. Для этого мы с командой решили проанализировать прошлые периоды данных и собрали простую статистику. Я приведу условный пример:
бэкенд‑команда в среднем закрывает X тикетов поддержки в месяц,
фронтенд — Y,
внутренние баги и техдолг — ещё Z.
Выявленные цифры не были идеальны, но они честны. Так я смог точно понять, какое число проблем и каких ролей могу запланировать на период.
И на полученных данных я построил реалистичный прогноз: «Мы можем взять в версию 5.9.2 условно (X+Y) – 20% тикетов из списка. Остальные — в 5.9.3 или 5.9.4.»
И да — если прилетит критичный баг, он встанет в начало очереди. Почему я не обещаю 100% загрузки — потому что хаос неизбежен, а 80% — это то, что мы гарантируем даже в условиях хаоса.
Этот подход снял давление с команды и повысил доверие заказчиков. Теперь они слышат не «когда‑нибудь», а список того, что мы точно успеваем.
Что делать, если вам требуется внедрить эту практику:
Выберите 2–3 метрики, которые отражают реальную нагрузку:
Количество тикетов из поддержки, закрытых в версию,
Количество внутренних багов, исправленных в версию,
Объём «перспективных» задач (тех, что «сделаем, когда будет время»).
Не измеряйте «скорость спринта» или «velocity» — они обманчивы в условиях потока.
Используйте метрики только для прогноза, а не для давления: «Мы в среднем закрываем 20 тикетов поддержки в месяц, значит в следующем релизе возьмём 16 (80%) + буфер на срочное».
Публикуйте метрики прозрачно — чтобы все (внедренцы, dev, PO, PM) видели: «Вот сколько мы реально можем сделать, поэтому не берём всё сразу».
Практика 4. Встройте правила в ритуалы, а не в инструкции
Раньше у нас была иллюзия процесса: «спринт‑планинг» заканчивался списком задач, который ломался на второй день, «дейли» превращались в отчёт «что я делал», «ретро» — в общие фразы о том, что надо лучше планировать. Поэтому мы перестали делать вид, что живём по Scrum. Вместо этого ввели ритуалы, которые решают реальные боли и не требуют новых инструментов. Для этого нужно перестать делать вид, что всё под контролем, и начать управлять тем, что реально происходит.
Что делать:
Замените «спринт‑планинг» на «груминг‑день»:
раз в месяц собирайте PO, тимлидов, релиз‑менеджера,
не «забивайте спринт», а отберите 80% от реальной пропускной способности в Selected‑бэклог.
Проводите недельную планёрку по понедельникам не для отчёта, а для проверки соответствия: «Вы взяли задачу из топа? Где оценка по этой хотелке? Почему в работе не тот баг, что в очереди?»
Делайте ретроспективы по конкретной теме, а не «как прошёл спринт». Например: «Почему 3 бага из поддержки пролежали неделю в Waiting?»
Собирайте от внешних команд раз‑два в месяц обновленный список топ-20 среди всех тикетов поддержки клиентов с приоритезацией. Всё и сразу собирать не нужно.
Используйте в коммуникации не обещания («сделаем 25-го»), а прогнозы на основе метрик («с вероятностью 80% успеем к 25-му»).
Практика 5. Закрывайте цикл и стройте доверие через выполненные обещания
Раньше релиз был технической формальностью: когда выпускалась версия, никто не знал, что именно в ней, так как документация была готова через сутки, а в проджект‑трекере встречались неточности в fixversion. Фраза «фича готова» могла означать, что баги остались — отдавали со статусом «Готово с дефектом» и поддержка снова получала обращения.
Теперь релиз — это момент закрытия цикла: заказчики видят — их топ-20 в RN решены, поддержка — обращений по новым фичам стало меньше, разработка — работа не растворяется в хаосе, а даёт измеримый эффект. Мы перестали говорить «мы работаем над этим», теперь мы отвечаем «Это сделано, вот доказательства. Следующее будет в релизе 5.11.0».
Что делать:
Публикуйте релиз‑ноуты с чётким списком того, что вошло.
Не обещайте фичи, которые не прошли багфиксинг: если доработка не протестирована — она не в релизе, даже если «код готов».
Сообщайте о релизе не как о «техническом событии», а как о «выполнении договора».
Используйте успешные релизы как основу для следующих прогнозов.
Заключение
Если ваша реальность — это поддержка + развитие, срочные баги + долгие фичи, внутренние заказчики + внешние ожидания — не бойтесь создавать свой гибрид. Методологии — для людей, а не наоборот.
Самый сложный шаг — первый. Не пытайтесь внедрить всё сразу, просто возьмите одну практику, которая ближе к вашей сегодняшней боли. Успехов!
