Команда Аспро.Cloud
+17% к производительности: системные изменения в Аспро.Cloud
Когда продукт развивается и команд становится больше, привычные процессы перестают справляться с нагрузкой. В разработке Аспро.Cloud шесть команд работали по Scrum, но фактически каждая жила в собственном ритме.
Спринты начинались в разные дни, длились по-разному, релизы переносились. Бэклог рос, задачи зависали на этапах, а сроки становились менее предсказуемыми. Мы поняли, что проблема не в людях и не в нагрузке — сбой произошел на уровне управления процессами.
Мы не стали кардинально менять методологию. Вместо этого пересобрали рабочую систему: синхронизировали команды, расширили рабочий процесс, усилили подготовку задач и ввели строгую приоритизацию.
Единый ритм вместо разрозненных спринтов
Первое, что создавало хаос, — отсутствие общего цикла работы. У одних команд спринт начинался в понедельник, у других — в среду. Где-то он длился неделю, где-то две, а иногда растягивался почти на месяц. Дедлайны сдвигались, задачи переносились, релизы не фиксировались как отдельный результат. Мы ввели единый двухнедельный спринт для всех команд с четкими датами старта и завершения. Теперь: Дополнительно закрепили промежуточные дедлайны для передачи задач в тестирование. Это позволило заранее понимать, что попадет в релиз, а что переносится. Отдельно запустили кросскомандное демо. На него приглашаем маркетинг, поддержку, руководителей и собственников. Каждая команда показывает результат за две недели. Это усилило прозрачность и сняло постоянные вопросы о сроках. Следующая проблема скрывалась в самой Scrum-доске. Раньше этапы были стандартными: сделать, в работе, код ревью, тестируется, выпущено. Но доска не показывала реальное состояние задачи. Если карточка стояла в колонке «Код ревью», было непонятно — ее уже проверяют или она просто ждет очереди. А если возникал блокер, задачу возвращали в «Сделать», и она визуально выглядела как новая. История терялась. Мы расширили рабочий процесс и добавили промежуточные этапы: Разделение позволило видеть, где именно задача застряла. Появилась возможность анализировать узкие места: например, если карточки долго стоят на этапе ожидания тестирования, это сигнал к перераспределению ресурсов. Одна из ключевых причин переделок — слабая подготовка задач. Формулировки вроде «Сделайте, чтобы было удобно» приводили к бесконечным уточнениям и возвратам. Мы внедрили Definition of Ready — критерии, которым должна соответствовать задача перед тем, как попасть в работу. Базовые принципы: После внедрения сократилось количество возвратов и упростилось планирование. Разработчики активно взаимодействуют с тестировщиками, маркетингом и поддержкой. Раньше многие договоренности оставались устными или фиксировались в чатах. Это отвлекало и создавало лишние напоминания. Мы добавили пользовательские поля-триггеры в задачах. Например, при включении поля «Нужен маркетинг» маркетологи получают автоматическое уведомление. Это не исключило общение полностью, но избавило от рутинных напоминаний и ручных сообщений. Мы заметили, что живем от спринта к спринту. Краткосрочные задачи вытесняли стратегические инициативы. Чтобы вернуть фокус, внедрили квартальное планирование. Теперь: Это помогло связать ежедневную работу с продуктовой стратегией. Со временем бэклог вырос до 2000 задач. Приоритеты «высокий, средний, низкий» перестали работать: десятки задач имели одинаковый статус. Мы внедрили приоритизацию по RICE: Такой подход дал числовую оценку задач и упростил планирование спринтов. Мы перестали ориентироваться на субъективные ощущения и перешли к системной оценке влияния.
Расширенный жизненный цикл задач
Definition of Ready как фильтр качества
Автоматизация межкомандной коммуникации
Переход к квартальному планированию
Приоритизация бэклога
Что изменилось в цифрах
