+17% к производительности: управленческие практики, которые ускорили релизы в Аспро.Cloud

Шесть команд разработки Аспро.Cloud работали по Scrum, но фактически каждая жила в собственном ритме. Спринты начинались в разные дни, длились от недели до месяца, а релизы постоянно переносились. Бэклог разросся до хаотичного состояния, задачи зависали на этапах код-ревью или тестирования без видимых причин, а сроки сдачи функционала стали непредсказуемыми.

Мы столкнулись с ситуацией, когда выросшая команда перестала укладываться в старые процессы. Проблема была не в лени людей и не в избыточной нагрузке — сбой произошел на уровне управления. Требовалось пересобрать рабочую систему так, чтобы синхронизировать команды, навести порядок в бэклоге и ускорить выход новых версий продукта (Time-to-market), не меняя кардинально методологию.

Мы не стали ломать Scrum, а доработали его под текущие реалии. Основной упор сделали на синхронизацию ритма, прозрачность этапов и жесткую приоритизацию. Работа была разбита на несколько логических этапов.

Первым делом мы устранили хаос в календарях. Для всех шести команд ввели единый двухнедельный цикл с четкими границами:

• Первый понедельник — старт спринта.

• Третий понедельник — релиз и ретроспектива.

Это позволило синхронизировать релизный поезд. Дополнительно мы запустили кросскомандное демо, куда приглашаем маркетинг, поддержку и руководителей. Теперь каждая команда публично показывает результаты за две недели, что сняло бесконечные вопросы «когда уже будет готово?» и повысило прозрачность.

Стандартная Scrum-доска скрывала реальное положение дел. Например, колонка «Код ревью» не показывала, проверяют ли задачу или она просто ждет очереди неделями. 

Мы детализировали процесс, добавив промежуточные статусы:

• Ожидает код ревью / Пройдено код ревью

• Ожидает тестирование

• Ожидает релиза

• На паузе

Это решило проблему «черной коробки». Теперь мы точно видим узкие места: если задачи скапливаются в «Ожидает тестирования», значит, пора перебрасывать ресурсы на тестировщиков.

Мы устали от переделок из-за размытых формулировок в духе «Сделайте удобно». 

Чтобы задачи не возвращались на доработку еще до начала разработки, мы внедрили жесткий чек-лист входа задачи в работу (Definition of Ready):

• Четкое описание. Используем подход Jobs to Be Done, чтобы команда понимала не «что кликнуть», а «какую проблему пользователя решаем».

• Бизнес-ценность. Задача отвечает на вопрос «зачем это продукту?».

• Реалистичность. Крупные задачи декомпозируются на подзадачи, которые можно закрыть за один спринт.

Это отсекло «мусорные» задачи на этапе бэклога и упростило планирование.

Чтобы разработчики не дергали маркетологов и тестировщиков в чатах каждые 5 минут, мы добавили пользовательские поля-триггеры. При отметке «Нужен маркетинг» система сама отправляет уведомление нужному отделу.

Параллельно мы навели порядок в гигантском бэклоге (2000+ задач). Простые приоритеты «высокий/средний/низкий» перестали работать. Мы внедрили систему RICE (Reach, Impact, Confidence, Effort), которая позволяет математически оценить ценность каждой задачи. Это убрало субъективщину и помогло фокусироваться на том, что действительно важно для продукта.

Системные изменения в процессах привели к измеримым улучшениям без увеличения штата или авралов.

1. Time-to-market сократился вдвое. Время прохождения задачи от статуса «Готова к работе» до «Выпущено» снизилось с 23 до 11 дней. Тренд остается нисходящим.

2. Бэклог «похудел» и стал прозрачнее. Медианный возраст задачи в бэклоге снизился с 7 до 6 месяцев. Мы перестали копить «мертвые» задачи и начали быстрее закрывать актуальные.

3. Предсказуемость и спокойствие. Релизы теперь выходят четко по расписанию (каждый третий понедельник), а не «когда допишут». Команды перестали жить в состоянии вечного цейтнота, а руководство получило прозрачную картину происходящего.