+17% к производительности: как отдел разработки Аспро.Cloud навел порядок в процессах

 Даже при использовании Scrum команда может терять темп. В Аспро.Cloud мы столкнулись со срывами релизов, неструктурированным бэклогом и неясными формулировками задач. Мы системно пересобрали процессы управления разработкой. В кейсе показываем, какие изменения дали измеримый результат.

Когда продукт развивается и команд становится больше, привычные процессы перестают справляться с нагрузкой. В разработке Аспро.Cloud шесть команд работали по Scrum, но фактически каждая жила в собственном ритме.

Спринты начинались в разные дни, длились по-разному, релизы переносились. Бэклог рос, задачи зависали на этапах, а сроки становились менее предсказуемыми. Мы поняли, что проблема не в людях и не в нагрузке — сбой произошел на уровне управления процессами.

Мы не стали кардинально менять методологию. Вместо этого пересобрали рабочую систему: синхронизировали команды, расширили рабочий процесс, усилили подготовку задач и ввели строгую приоритизацию.

Единый ритм вместо разрозненных спринтов

Первое, что создавало хаос, — отсутствие общего цикла работы. У одних команд спринт начинался в понедельник, у других — в среду. Где-то он длился неделю, где-то две, а иногда растягивался почти на месяц. Дедлайны сдвигались, задачи переносились, релизы не фиксировались как отдельный результат.

Мы ввели единый двухнедельный спринт для всех команд с четкими датами старта и завершения.

Теперь:

1. первый понедельник — начало спринта
2. третий понедельник — релиз и ретроспектива

Дополнительно закрепили промежуточные дедлайны для передачи задач в тестирование. Это позволило заранее понимать, что попадет в релиз, а что переносится.

Отдельно запустили кросскомандное демо. На него приглашаем маркетинг, поддержку, руководителей и собственников. Каждая команда показывает результат за две недели. Это усилило прозрачность и сняло постоянные вопросы о сроках.

Расширенный жизненный цикл задач

Следующая проблема скрывалась в самой Scrum-доске. Раньше этапы были стандартными: сделать, в работе, код ревью, тестируется, выпущено. Но доска не показывала реальное состояние задачи. Если карточка стояла в колонке «Код ревью», было непонятно — ее уже проверяют или она просто ждет очереди.

А если возникал блокер, задачу возвращали в «Сделать», и она визуально выглядела как новая. История терялась.

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

1. бэклог
2. готова к работе
3. ожидает код ревью
4. пройдено код ревью
5. ожидает тестирование
6. ожидает релиза
7. на паузе

Разделение позволило видеть, где именно задача застряла. Появилась возможность анализировать узкие места: например, если карточки долго стоят на этапе ожидания тестирования, это сигнал к перераспределению ресурсов.

Definition of Ready как фильтр качества

Одна из ключевых причин переделок — слабая подготовка задач. Формулировки вроде «Сделайте, чтобы было удобно» приводили к бесконечным уточнениям и возвратам.

Мы внедрили Definition of Ready — критерии, которым должна соответствовать задача перед тем, как попасть в работу.

Базовые принципы:

1. Четкое описание. Используем подход Jobs to Be Done. Вместо «Добавить кнопку экспорта» формулируем контекст и цель пользователя. Это помогает команде понимать ценность, а не просто выполнять действие.
2. Понятная бизнес-ценность. Каждая задача должна отвечать на вопрос, зачем она продукту и пользователю.
3. Достаточность ресурсов. Если не хватает компетенций или информации, задача уходит в исследование, а не блокирует спринт.
4. Реализация за один спринт. Крупные задачи декомпозируем. Это повысило предсказуемость планирования.

После внедрения сократилось количество возвратов и упростилось планирование.

Автоматизация межкомандной коммуникации

Разработчики активно взаимодействуют с тестировщиками, маркетингом и поддержкой. Раньше многие договоренности оставались устными или фиксировались в чатах. Это отвлекало и создавало лишние напоминания.

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

Переход к квартальному планированию

Мы заметили, что живем от спринта к спринту. Краткосрочные задачи вытесняли стратегические инициативы.

Чтобы вернуть фокус, внедрили квартальное планирование. Теперь:

1. согласовываем цели со стейкхолдерами
2. фиксируем ключевые инициативы
3. проводим квартальные ретроспективы
4. балансируем операционные и долгосрочные задачи

Это помогло связать ежедневную работу с продуктовой стратегией.

Приоритизация бэклога

Со временем бэклог вырос до 2000 задач. Приоритеты «высокий, средний, низкий» перестали работать: десятки задач имели одинаковый статус.

Мы внедрили приоритизацию по RICE:

1. reach —  охват
2. impact — влияние
3. confidence — уверенность
4. effort — трудозатраты

Такой подход дал числовую оценку задач и упростил планирование спринтов. Мы перестали ориентироваться на субъективные ощущения и перешли к системной оценке влияния.

Что изменилось в цифрах

1. Главной целью было сокращение Time-to-market — времени от статуса «Готова к работе» до «Выпущено».
2. Мы снизили этот показатель почти в два раза — с 23 до 11 дней. Тренд остается нисходящим.
3. Также удалось снизить медианный возраст задачи в бэклоге с 7 до 6 месяцев.
4. Команда стала быстрее принимать решения, релизы стали регулярными, а процессы — прозрачными для всех участников.

Динамика изменения времени цикла «Готово к работе» — «Выпущено»

Омоложение бэклога — cнижение медианного возраста задачи