Меня зовут Василий Ферапонтов, я отвечаю за SaaS-направление в Аспро. Мы развиваем собственный продукт — облачную систему управления бизнесом. В команде несколько продуктовых и платформенных групп, всего больше двадцати человек в разработке.
Год назад у нас была ситуация, которая многим знакома. Команды заняты, задачи двигаются, релизы происходят… но предсказуемости нет. Сроки плавают, бэклог разрастается, внутри много устных договоренностей. Все работают, но система не работает.
За один квартал мы перестроили процессы и получили вполне измеримый результат:
срок прохождения задачи от «готова к работе» до «выпущено» сократился с 23 до 11 дней
производительность выросла на 17%
релизы стали регулярными, а не «как получится»
бэклог перестал быть черной дырой
Расскажу, что именно мы изменили и почему это сработало.
Проблема была не в людях, а в ритме
Формально мы работали по Scrum. Итерации, планирования, доски задач — все было. Но у каждой команды был свой ритм.
Одна начинала спринт в понедельник, другая в среду. Где-то итерация длилась неделю, где-то две. Где-то релиз совпадал с окончанием спринта, где-то нет.
В итоге возникала странная картина: команды живут в разных временных зонах внутри одного продукта.
Мы сделали простую, но жесткую вещь — синхронизировали всех.
Ввели единый двухнедельный спринт для всех команд:
первый понедельник — старт
третий понедельник — релиз и ретроспектива
Появились фиксированные точки:
до какого дня задача должна уйти в тестирование
когда формируется следующий план
С этого момента исчезли вопросы «а когда у вас релиз». Появился общий пульс продукта.
И это сильно снизило уровень хаоса.
Мы начали публично показывать результат
Следующий шаг — кросскомандное демо.
Раз в две недели все команды показывают, что сделали. Не в закрытом кругу, а публично. Приходят маркетологи, техподдержка, руководители.
Это оказалось важнее, чем мы ожидали.
Во-первых, демонстрация дисциплинирует. Если ты знаешь, что будешь показывать результат всей компании, задача доводится до рабочего состояния.
Во-вторых, исчезли сюрпризы. Новый функционал больше не «внезапно появился». Все видят, как продукт меняется.
И самое интересное — у команд появилось чувство завершенности. Итерация перестала быть просто набором задач. Она стала законченным циклом.
Мы перестали угадывать, что происходит с задачей
Раньше у нас была стандартная доска:
сделать
в работе
проверка кода
тестируется
выпущено
На бумаге красиво. В реальности — непонятно.
Задача в колонке «проверка кода». Ее уже проверяют или она просто лежит?
Задача «тестируется». Над ней работают или она ждет своей очереди?
Если возникал блокер, задача просто возвращалась в «сделать». История терялась.
Мы детализировали жизненный цикл задачи. Появились статусы:
бэклог
готова к работе
в работе
ожидает проверки
проверка пройдена
ожидает тестирования
ожидает релиза
на паузе
выпущено
Кто-то скажет: «Слишком много этапов».
Но это не усложнило работу. Это убрало иллюзию движения.
Мы начали видеть узкие места. Например, что задачи массово зависают в ожидании тестирования. Или что проверка кода занимает непропорционально много времени.
Когда статус перестает быть абстрактным, им можно управлять.
Самая большая проблема — плохой вход в разработку
Если говорить честно, главный источник потерь был не в тестировании и не в ревью. Он был в постановке задач.
Формулировки в духе:
Сделать удобнее
Добавить экспорт
Улучшить фильтр
Такая задача почти гарантированно возвращается на доработку.
Мы внедрили Definition of Ready — критерии готовности задачи к разработке. По-русски — «определение готовности».
Если задача не соответствует критериям, она не попадает в спринт.
Что обязательно должно быть:
Понятный пользовательский сценарий.
Описанная бизнес-ценность.
Четкий ожидаемый результат.
Возможность выполнить за один спринт.
Мы начали описывать задачи через сценарий.
Было:
Добавить экспорт отчета.Стало:
Когда пользователь завершает формирование финансового отчета, он хочет выгрузить его в Excel, чтобы передать бухгалтеру без ручного копирования.
Разница — в контексте.
Разработчик понимает не просто «кнопку», а задачу пользователя.
После внедрения этого подхода резко сократилось количество возвратов и «а что вы имели в виду?».
Мы автоматизировали мелкую коммуникацию
Отдел разработки постоянно взаимодействует с маркетингом, поддержкой, тестировщиками.
Раньше это выглядело так:
Напомни тестировщикам
Скажи маркетингу про релиз
Не забудь написать в поддержку
Это мелкие, но постоянные отвлечения.
Мы добавили в задачи поля-триггеры. Например:
Нужен маркетинг
Обновить документацию
Сообщить в поддержку
При активации триггера соответствующая команда получает уведомление автоматически.
Мы не убрали общение. Но убрали ручные напоминания.
И это неожиданно снизило уровень фонового шума.
Бэклог перестал быть кладбищем задач
Со временем бэклог разросся до двух тысяч задач.
Модель «высокий / средний / низкий приоритет» перестала работать. Пятьдесят задач с высоким приоритетом — это все равно не приоритет.
Мы перешли на метод RICE:
охват
влияние
уверенность
трудозатраты
Это заставило смотреть на задачу через цифры, а не через эмоции.
Иногда казалось, что задача «очень важная». После оценки выяснялось, что она затрагивает 2% пользователей.
Планировать спринты стало проще. Споров стало меньше.
Квартальное планирование вернуло стратегию
Раньше мы жили от спринта к спринту. Срочные задачи вытесняли стратегические.
Мы начали формировать квартальные цели:
крупные продуктовые изменения
технический долг
инфраструктурные задачи
Спринты стали инструментом достижения квартальных целей, а не самоцелью.
Это вернуло ощущение движения вперед, а не бесконечной реакции на входящие задачи.
Что в итоге изменилось и что оказалось действительно важным
Если смотреть сухо по цифрам, изменения заметны.
Время прохождения задачи от «готова к работе» до «выпущено» сократилось с 23 до 11 дней. Производительность выросла на 17%. Релизы стали предсказуемыми, а не «примерно в этом месяце». Бэклог перестал быть свалкой из тысяч задач.
Но важнее другое.
Изменилась управляемость. Мы перестали гадать, где зависла задача. Перестали спорить о приоритетах на уровне ощущений. Перестали начинать работу по задачам, которые на самом деле не готовы к разработке.
И самое главное — мы синхронизировали ритм.
Когда у всех команд единый цикл, единые точки релиза и понятные правила входа задачи в работу, продукт начинает двигаться системно. Не рывками. Не за счет героизма отдельных людей. А за счет процесса.
Комментарии (7)
Strazur
16.03.2026 12:05Спасибо за интересную статью.
Взял на себя смелость сделать небольшое резюме для практического применения может кому поможет:
Табличка (markdown от DeepSeek)
Вот таблица, обобщающая все практические рекомендации из статьи, сгруппированные по ключевым направлениям. | Название | Рекомендация | Практические действия | | :--- | :--- | :--- | | **Синхронизация ритма** | | | | 1. Единый спринт для всех | Синхронизировать работу всех команд в едином временном цикле. | Выбрать общую длительность спринта (например, 2 недели) и зафиксировать единые даты старта и окончания для всех команд (продуктовых, платформенных, бэкенда и фронтенда). | | 2. Фиксированные точки синхронизации | Установить четкие внутренние дедлайны внутри спринта, общие для всех. | Определить даты Code Freeze, крайний срок передачи задач в тестирование и день релиза. Например: «вторая среда спринта — deadline для сдачи задач на тестирование». | | **Прозрачность результатов** | | | | 3. Кросскомандное демо | Показывать результаты работы всем смежным отделам, а не только внутри команды. | Раз в две недели проводить общую встречу, где каждая команда демонстрирует реально работающий функционал маркетингу, поддержке и руководству. | | 4. Дисциплина через публичность | Использовать публичность демо как мотиватор для доведения задач до ума. | Заранее анонсировать список того, что будет показано на общем демо. Это стимулирует разработчиков не бросать задачи на полпути. | | **Детализация статусов задач** | | | | 5. Разделяйте ожидание и действие | Ввести статусы, которые четко показывают, выполняется ли над задачей работа или она ждет очереди. | Вместо общих колонок «Проверка кода» и «Тестирование» создать раздельные: «Ожидает проверки кода», «Код ревьюится», «Ожидает тестирования», «В тестировании». | | 6. Выявляйте узкие места аналитикой | Использовать новые статусы для сбора статистики простоя задач. | Настроить отчеты по времени нахождения задачи в каждом статусе. Если задачи подолгу зависают в «Ожидает проверки кода» — значит, узкое место в код-ревью. | | **Качество входа (Definition of Ready)** | | | | 7. DoR как закон | Не брать в спринт задачи, которые не соответствуют критериям готовности к разработке. | Внедрить Definition of Ready: задача должна содержать понятный пользовательский сценарий, бизнес-ценность, ожидаемый результат и быть выполнимой за один спринт. | | 8. Описывайте сценарии, а не функционал | Формулировать задачи через контекст и действия пользователя, а не через технические детали. | Вместо «Добавить экспорт отчета» писать: «Когда пользователь завершает формирование финансового отчета, он хочет выгрузить его в Excel, чтобы передать бухгалтеру без ручного копирования». | | **Автоматизация рутины** | | | | 9. Триггеры вместо напоминалок | Автоматизировать уведомления смежных отделов о событиях, связанных с задачей. | Добавить в тикеты поля-флаги («Нужен маркетинг», «Обновить документацию»). При их активации система автоматически отправляет уведомление соответствующей команде. | | **Приоритизация и стратегия** | | | | 10. RICE вместо интуиции | Принимать решения о приоритетах на основе объективных метрик, а не эмоций. | Оценивать каждую задачу по четырем параметрам: Reach (охват), Impact (влияние), Confidence (уверенность), Effort (трудозатраты). Сортить бэклог по убыванию итогового балла. | | 11. Квартальные цели | Увязать спринты с долгосрочными целями, чтобы не терять стратегию в текучке. | В начале квартала сформировать крупные цели (продуктовые изменения, техдолг, инфраструктура). Планировать спринты так, чтобы каждый приближал к этим целям. |
AiZen_13
16.03.2026 12:05Первый понедельник - старт, третий - релиз и ретро. А остаток недели, в которой третий понедельник, чем все занимаются?
В райсе охват и влияние на пользователей по каким метрикам считали?
Бэклог перестал быть кладбищем пары тысяч задач - а куда эти задачи делись? Их же все нужно было приоритизировать и разбить на спринты, а на это нужно прилично времени... Или просто все в мусорку и с чистого листа?
Перестали брать в работу не подготовленные задачи - чем занимались разработчики, пока аналитики доготавливали задачи?
По какому принципу формирует квартальные цели и на сколько кварталов вперёд?
Вопросов по выходу из хаоса/болота на самом деле очень много...
vasya_project Автор
16.03.2026 12:05Отвечу по пунктам.
1. В понедельник, когда завершается текущий спринт, сразу начинается новый, так как его планирование проходит ближе к концу второй недели. За счет этого нет паузы между спринтами.
2. Охват считаем по продуктовой аналитике - по количеству пользователей, вовлеченных в дорабатываемый или связанный функционал. Импакт - по сути субъективная метрика, оцениваем эмпирически.
3. Часть задач действительно удалили. Много дублей и связанных задач объединили. Остальное распределяем по спринтам при регулярной работе с бэклогом.
4. Всегда есть задачи, которые не требуют глубокой проработки: ошибки, техдолг и подобные вещи.
5. Квартальные цели согласуются со стратегией от стейкхолдеров. Планируем примерно на 2-3 квартала вперед, так как рынок и требования аудитории меняются достаточно быстро.
ekiyasheva
16.03.2026 12:05Спасибо за статью! Было очень интересно прочесть о вашем системном подходе к организации работы в эпоху AI-хайпа.
Отдельное спасибо за:
• RICE-метод — беру на вооружение; ссылки на стандартные фреймворки очень помогают в аргументации.
• Кейс с привлечением внешних участников на демо — отличный инструмент для правильной фокусировки команды, который редко встретишь на практике.Задалась вопросом, можно ли сломать ваш подход бездумным копированием. Выделила несколько уязвимых мест, характерных для крупных процессов.
Шаблон «Роль — Действие — Ценность» не гарантирует качества задач. Можно написать формальную пустышку вроде: «Я, как администратор, хочу сбросить пароль, чтобы сбрасывался пароль». За ней теряется истинная причина: например, уязвимости в системе или проблемы пользователей. Если менеджер оценивает только формат, задача попадает в бэклог. Она будет переделываться многократно до закрытия реальной потребности. Как вы такое обходили и считали ли нужным обходить?
Насколько я поняла, вы используете Kanban, в статье представлена статусная модель User Story. Стори обычно «рассыпаются» на множество задач реализации (Task): фронт, бэк, макеты, IaC. Заказчик следит за Story. Основные риски управления скрыты в Task’ах. Статус стори подсвечивает факт проблемы, но не ее причину. Используете ли вы дополнительный слой аналитики? В статье есть пример про несоразмерное время ревью, как вы поняли, почему это происходит?
Движение User Story между ролями формирует скрытый «водопад», он создает два риска тестирования:
Задержки на всех предыдущих этапах съедают время на выполнение тестов. Необходимо выбирать, выпускать продукт недопроверенным или сдвигать общие сроки.
Когда тестирование в конце, женить компоненты начинают непосредственно перед этим этапом. Как следствие, продукт заходит в тест в неприглядном виде: не билдится, забагован, имеет логические противоречия. Вместо тестирования QA занимаются не тестами, а оживлением продукта. Используете ли вы Shift-Left и контрактную разработку для решения этих проблем? Какие практики реально прижились?
Возможно, мои вопросы касаются "секретных ингридиентов" или же я неверно расчитала процесс, поэтому пойму, если промолчите. Но надеюсь на ответ, заранее спасибо :)
iliya2004
Полезно, спасибо
vasya_project Автор
Рад, что понравилось!