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