Быстро не значит некачественно. Как ускорить релиз и не поймать техдолг
В IT есть мнение, что если гнаться за скоростью, на выходе будет кривой код, баги и техдолг. Но это не аксиома, а следствие плохой организации процесса. В Purrweb мы создаем сложные продукты с высокими требованиями к стабильности. При этом от нас ждут скорости.
Мы научились искать баланс: где можно ускориться без потерь, а где экономия времени обернется долгосрочными проблемами. В этой статье поделимся рабочими принципами, практиками и инструментами, которые позволяют выпускать продукт быстро и без перевеса техдолга. А еще покажем, как с этим справляются другие команды в индустрии.
Своим опытом поделились представители МТС Юрент, «Лиги Ставок», Rambler&Co и других компаний. Материал будет полезен продуктовым менеджерам, деливери‑менеджерам, владельцам продукта, CDTO и CTO.
Почему «быстро = плохо» — это не всегда правда
Мнение, что «быстро значит плохо», появилось не на пустом месте: нередко спешка действительно приводила к ошибкам, росту техдолга, падению качества продукта и недовольству пользователей. Но корень проблемы обычно не в скорости, а в том, как команды организуют работу под давлением сроков.
Даже при высоком темпе можно избежать накопления техдолга и сохранить качество, если продакт‑менеджер или тимлид осознанно управляет скоростью, оптимизируя процессы разработки и тестирования.
«В быстрых проектах полностью избежать технического долга сложно, особенно если нужно оперативно проверить гипотезу или успеть к дедлайну. В таких случаях мы сразу договариваемся с заказчиком: можем собрать работающий прототип быстро, но если он «выстрелит», скорее всего, его нужно будет переписать с нуля.
Когда речь о более крупных и длительных проектах — например, с горизонтом в полгода — у нас уже подключаются архитекторы и тимлиды, следящие за качеством и структурой кода. В таких проектах можно ускоряться за счет грамотного проектирования и оптимизации процессов, а не за счет костылей. Например, мы можем начать разработку параллельно с дизайном или заранее определить архитектуру. Это позволяет двигаться быстро, но без «грязи» в коде».
Сергей Пономарев
CTO Purrweb
Тут есть два пути:
- БПЛА впервые атаковали склад Ozon — в Самарской области
- Кофейне пришлось переименоваться из Love в Олега из‑за закона о русском языке
- Российские фермеры опасаются разорения из‑за обвала цен на зерно
- Россияне отказываются от крупных трат ради покупок «для настроения»
- ИИ заменит или изменит каждое третье рабочее место в России
- С 1 сентября Яндекс Маркет изменит условия работы для FBS- и FBY‑продавцов
Какие риски возникают, если торопить релиз
Спешка может привести к появлению ошибок в продакшене или созданию технически слабого продукта. Эксперты, с которыми мы поговорили, перечисляют следующие риски высокой скорости разработки:
По словам Сергея Колоскова, CEO Product market Lab, главный риск ускоренных релизов — потеря управляемости продуктом.
«Когда команда жертвует архитектурой и тестами ради скорости, это приводит к замедлению уже через пару релизов. Другой риск — демотивация команды: разработчики видят, что их работа превращается в «латание дыр», а не в создание продукта. Еще один риск — потеря качества пользовательского опыта: баги и неустойчивый сервис бьют по доверию клиентов быстрее, чем задержки на 1–2 недели».
Как отмечает Шахрияр Солтанов, директор по продукту «Рамблер/почта» (входит в медиахолдинг Rambler&Co), демотивация команды — это самый частый риск, когда бизнес просит ускориться любой ценой.
«Когда случается «влет» или необходимо ускорение, какими‑то задачами всегда приходится жертвовать и это может вызывать негатив. Нужно менять контекст, оставлять что‑то недоделанным.
Я работаю с этим риском через поддержание прозрачности. Даю контекст, делюсь, что произошло, почему нужно ускориться, что можем сделать».
Шахрияр Солтанов
Директор по продукту «Рамблер/почта» (входит в медиахолдинг Rambler&Co)
Андрей Калинин, сооснователь и ИТ‑директор МТС Юрент, говорит о следующих рисках ускоренной разработки:
- снижение качества: на тестовых средах все хорошо, а на проде — падения сразу или спустя время;
- рост багов и технического долга: костыли, хардкод, сломанная архитектура;
- нестабильные или немасштабируемые решения: «длинный хвост» поддержки;
- срыв планов и потеря фокуса: спринты разваливаются, приоритеты постоянно меняются.
Как отмечает Александр Капустин, CEO Unirest IT, ex. Авито финтех, ускорение разработки «любой ценой» создает угрозы дальнейшему масштабированию.
«Качество решения страдает первым: пропуск этапов проектирования и ревью ведет к архитектурным допущениям, которые затрудняют дальнейший рост продукта. Возрастает риск «промахнуться» с продуктом: фокус на скорости смещает внимание с валидации гипотез у целевой аудитории.
Информационная безопасность и стабильность тоже часто становятся жертвами оптимизации. Итог — выпуск продукта нерелевантного рынку или технически неспособного к развитию и масштабированию. Попытки «докрутить» продукт требуют уже значительно больших ресурсов, съедая всю выгоду от ускорения, которую мы получили на старте».
Александр Капустин
CEO Unirest IT, ex. Авито финтех
По словам Дениса Теплова, CPO «Лига Ставок», скорость сама по себе не является риском. Риск в том, как построена система.
«Если компания выбирает модель, где главная цель — time‑to‑market одной задачи, то выигрывает скорость «здесь и сейчас», но сильно проседает планирование и управляемость. Другой путь — строить систему так, чтобы выпускать объем задач стабильно и предсказуемо. Эта система выглядит медленнее, но по факту эффективнее в долгосрочной перспективе».
Денис Теплов
CPO «Лига Ставок»
Что вредит качеству и порождает техдолг
Разработчики вынуждены принимать компромиссные решения, чтобы уложиться в срок. Они могут пропускать этап тестирования или допускать ошибки в архитектуре, а это увеличивает техдолг и впоследствии приводит к замедлению работы.
По словам Александра Капустина, CEO Unirest IT, ex. Авито финтех, в разработке категорически недопустимы: игнорирование подходов к тестированию, нарушение принципов проектирования, отказ от документирования критических решений, экономия на инфраструктуре надежности.
Как отмечает эксперт, эти шаги гарантированно породят неуправляемый техдолг, который замедлит команду в будущем. Отсутствие юнит‑тестов или даже базового ручного тестирования приводит к тому, что баги попадают в продакшн, подрывая доверие пользователей.
Как замечает Денис Теплов, CPO «Лига Ставок», важна постоянная работа с легаси продукта.
«У нас продукту уже больше 15 лет, и мы хорошо понимаем: если не инвестировать в работу с легаси постоянно, то рано или поздно все встанет. Поэтому стабильно в каждом спринте забираем задачи по техдолгу и архитектуре. В среднем около 40% ресурсов команд уходит именно на технику — это сознательное решение, чтобы продукт оставался живым и масштабируемым».
Денис Теплов
CPO «Лига Ставок»
Андрей Калинин, сооснователь и ИТ‑директор МТС Юрент, акцентирует внимание на том, что при попытках ускориться нельзя допускать трех вещей.
Сергей Колосков, CEO Product market Lab, также говорит о том, что опасно экономить на тестах, «зашивать» временные костыли в архитектуру и откладывать документацию. Эти решения почти всегда превращаются в техдолг и замедляют команду уже через квартал.
Любые ошибки можно минимизировать, если правильно выстроить процессы. Успех быстрого релиза зависит не от скорости самой по себе, а от подхода команды и инструментов, которые она использует.
Как ускориться без ущерба качеству
Некоторые компромиссы ради ускорения могут привести к росту техдолга. Другие при правильном подходе оправданы: они позволяют сохранять качество с одновременным ростом скорости. Эксперты выделяют такие способы безопасного ускорения разработки:
Шахрияр Солтанов, директор по продукту «Рамблер/почта», отмечает, что ключевое значение в вопросе компромиссов по техдолгу играет процесс его оценки.
Если мы ускоряемся и получаем огромный буст в выручке, аудитории, любой другой критичной метрики — это одна планка к объему техдолга. В таких случаях я, вероятно, пойду на компромисс.
Если ускорившись на 2 недели мы получаем техдолг на 3 месяца — это совершенно другой разговор, где компромисс вряд ли возможен. В итоге вопрос не в том, чтобы избежать техдолга, а в том, знаете ли вы его реальную цену и готовы ли ее платить.
Шахрияр Солтанов
Директор по продукту «Рамблер/почта» (входит в медиахолдинг Rambler&Co)
Андрей Калинин, сооснователь и ИТ‑директор МТС Юрент, отмечает: «Когда важно
выпустить продукт быстро, допустимы такие компромиссы:
- Сужение объема фич (MVP‑подход).
- Временный отказ от полного набора тестов, но с пометкой и последующим покрытием.
- Откладывание рефакторинга некритичных модулей.
- Временный обход без CRUD/админки».
Денис Теплов, CPO «Лига Ставок» отмечает, что перед тем как поставить задачу в разработку, команда проверяет ее ценность: готовят макеты, проводят коридорные тесты, показывают их пользователям.
Далее работа строится в трехнедельных спринтах: у каждой из команд свой цикл, но в конце все они вливаются в общую релизную ветку. В процессе применяются код‑ревью, автотесты, нагрузочное тестирование и максимальная автоматизация пайплайна. Цель такого подхода — снизить транзакционные издержки и выпускать быстрые релизы без потери качества.
По словам Сергея Колоскова, CEO Product market Lab, для быстрого релиза без техдолга допустимо сократить проработку второстепенных функций, отложить автоматизацию редких сценариев, временно использовать готовые SaaS или no‑code решения.
Александр Капустин, CEO Unirest IT, ex. Авито финтех, говорит о том, что базово для ускорения подходит подрезка non‑core фич, либо временные решения с явной фиксацией техдолга в бэклоге и с его оценкой.
Реальные кейсы: буст скорости разработки без техдолга
Разработку можно ускорить, если автоматизировать тестирование, проводить код‑ревью и выделять время на управление техническим долгом.
«Чтобы сохранять качество даже при сжатых сроках мы проводим автоматизированное тестирование: unit, интеграционные, e2e. Используем CI/CD‑конвейеры с «воротами качества», канареечные релизы и feature‑flags: постепенная выкладка и быстрый откат. Ловим ошибки до продакшена с помощью код‑ревью и проектирования изменений. Ограничиваем область изменений и упрощаем поддержку за счет модульной архитектуры и стандартизации стилей.
Нашей команде удается сохранять фокус на ключевых задачах и не скатываться в «быстрые решения» благодаря:
- регулярному приоритезированию бэклога с продактом, менеджментом;
- буферам в спринтах для «ремонта» и технических работ;
- ежедневным стендапам и ретроспективам: фиксируем случаи, когда спешка навредила, и корректируем процесс;
- ограничению контекста: не дробим проекты на много срочных эпиков;
- прозрачной коммуникации с бизнесом о последствиях «быстрых правок».
Андрей Калинин
Сооснователь и ИТ‑директор МТС Юрент
По словам Сергея Колоскова, CEO Product market Lab, чтобы ускориться без ущерба качеству, его команда фиксирует техдолг так, как и новые фичи: в бэклоге, с приоритетами и сроками. Спикер отмечает, что «хорошая практика — выделять 10–20% времени каждого спринта на возврат к этим задачам. Еще один способ — привязывать часть техдолга к бизнес‑метрикам. Например: оптимизация базы данных напрямую влияет на скорость заказов, значит это не «долг», а реальная доработка для бизнеса».
Еще один вариант — не релизить новые фичи во время работы над проектом.
«Недавно мы прошли через редизайн мобильного приложения — заняло около девяти месяцев. Мы сознательно ввели фриз на все новые фичи и сосредоточились только на этом проекте. Раскатывали постепенно: сначала на 1% пользователей, фиксили баги, потом на 5%, 10% и так до 100%. Такой подход позволил нам сохранить качество и не потерять доверие аудитории, которая очень консервативна к изменениям».
Денис Теплов
CPO «Лига Ставок»
Шахрияр Солтанов, директор по продукту «Рамблер/почта», также акцентирует внимание на том, что в рамках планирования спринтов команды закладывают процент времени для техдолга. По словам эксперта, это может быть и 10%, и 40% спринта. Цифра зависит от стадии развития, на которой находится продукт.
Если это сервис, который давно развивается и в нем накопилось достаточное количество легаси — квота на техдолг будет выше. Если это новый продукт, перекос будет в сторону бизнес‑задач.
По словам Шахрияра, к проценту техдолга в спринте в каждом продукте мы приходим эмпирическим путем: проводим несколько спринтов и смотрим, какой баланс техдолга и бизнес‑задач подходит нам на текущем этапе.
«Сохранять качество при сжатых сроках нам помогают юнит‑тесты на критические функции, CI/CD, автоматические проверки качества кода, базовый мониторинг и алерты. Даже при жестких сроках такие практики экономят время на ручном тестировании и отлове багов. Еще один инструмент — модульная архитектура: если продукт разбит на независимые блоки, его легче дорабатывать без риска сломать соседние части».
Александр Капустин, CEO Unirest IT, ex. Авито финтех, подчеркивает: техдолг, возникший при ускорении, требует системного контроля, а не игнорирования. Такие долги надо вести так же аккуратно, как и основной бэклог, и принимать решение о обязательном включении «выплаты» в спринты, когда уже проблема начинает явно стрелять по продукту.
«Архитектурная дисциплина критична: даже в спешке нужно закладывать базовую масштабируемость — «наращивание» монолита «сбоку» создаст долгосрочные проблемы.
Автоматизация, если она у нас уже есть, тоже важна: минимальный, но стабильный CI/CD pipeline (сборка, линтинг, юнит‑тесты, деплой) защищает от регрессий и завязывания в багах. Обязательное покрытие core‑логики автотестами (unit, интеграционными) снижает риск катастрофических багов.
Выделяйте задачи, которые влияют на долгосрочную архитектурную целостность и P&L команды. Quick wins допустимы только если они не создают долгосрочных препятствий для core‑функционала или не требуют немедленного рефакторинга».
Александр Капустин
CEO Unirest IT, ex. Авито финтех
Как объяснить бизнесу, что агрессивное ускорение может привести к замедлению
Руководители часто настаивают на увеличении скорости разработки, но буст скорости без учета качества может привести к обратному эффекту. Чтобы убедить бизнес в важности баланса, нужно объяснять: слепая гонка за сроками в итоге замедляет работу, приводит к росту расходов.
По словам Сергея Колоскова, CEO Product market Lab, самый понятный аргумент — деньги. Спикер отмечает, что бизнесу важно знать, к каким расходам приводит техдолг. Поэтому самый простой способ — посчитать убытки. Быстрый релиз без тестов может обойтись в X багов, которые придется чинить за N человеко‑часов.
«Следующий аргумент — репутация: один провал с пользователями отбрасывает продукт назад сильнее, чем задержка релиза. Я часто показываю бизнесу реальные кейсы из отрасли или даже наши прошлые ошибки: это снижает эмоциональность спора и переводит его в плоскость фактов».
Андрей Калинин, сооснователь и ИТ‑директор МТС Юрент, также подчеркивает, что в качестве аргумента важно приводить реальные кейсы из практики: рассказывать про сбои, простои, потери клиентов.
По его словам, есть и другие методы:
- Визуализировать кривую техдолга: рост долга прямо коррелирует с удлинением цикла разработки новых фич.
- Ставить акцент на эффективности, а не на «быстрой скорости»: стабильный процесс позволяет масштабироваться без риска.
- Демонстрировать ROI: каждый сэкономленный сегодня час оборачивается дополнительными часами на исправления завтра.
Как замечает Шахрияр Солтанов, директор по продукту «Рамблер/почта», самый эффективный способ взаимодействия с бизнесом, это разъяснить, что может сделать команда и что это даст.
«Проработанная стратегия вкупе с качественно оцененными и приоритезированными бэклогом и роадмапом — основа управления продуктом в целом и коммуникации с бизнесом в частности».
Шахрияр Солтанов
Директор по продукту «Рамблер/почта» (входит в медиахолдинг Rambler&Co)
Александр Капустин, CEO Unirest IT, ex. Авито финтех, считает, что объяснение строится на демонстрации долгосрочных экономических последствий.
«Визуализируйте метрики: графики снижения скорости разработки (например, story points за спринт). Свяжите качество с P&L: стоимость экстренных фиксов, отток клиентов из‑за сбоев, невозможность быстро реагировать на рынок из‑за «закостеневшей» архитектуры. Предложите осознанный выбор: «Быстрый релиз Х сейчас с техдолгом Y, который замедлит нас на Z% через N месяцев, ИЛИ релиз на K дней позже, но без тормозов в будущем».
Александр Капустин
CEO Unirest IT, ex. Авито финтех
Вывод
Скорость в разработке не обязательно означает низкое качество, костыли и технический долг. Чтобы делать быстро и без техдолга, нужно правильно выстроить процессы, использовать автоматизацию, продумывать архитектуру. А вот пропуск ревью, тестирования, нарушение архитектурных принципов, костыли на продакшене создают проблемы, которые замедляют разработку в будущем и увеличивают расходы.
Полностью избежать технического долга, скорее всего, невозможно, но его можно минимизировать. Для этого эксперты советуют использовать проверенные методы:
- регулярно приоритизировать бэклог;
- автоматизировать тестирование;
- проводить код‑ревью;
- использовать модульную архитектуру;
- создавать буферы в спринтах для технических работ;
- проводить ежедневные стендапы и ретроспективы.
В итоге успех зависит от осознанного подхода: некоторые компромиссы приводят к росту техдолга, другие — нет. Если инхаус‑команде сложно найти этот баланс, можно обратиться за разработкой на аутсорс.
'%20fill='none'/%3e%3cpath%20fill='%23ffdd2d'%20d='%20M%20104.72%200.00%20L%20112.15%200.00%20Q%20106.48%207.74%20100.12%2014.37%20C%2091.89%2022.97%2081.81%2029.47%2071.49%2035.26%20Q%2061.95%2040.62%2051.54%2043.77%20C%2044.52%2045.90%2036.57%2046.85%2028.99%2047.67%20Q%2027.29%2047.86%2025.66%2047.43%20Q%2025.42%2047.37%2025.35%2047.61%20L%2025.26%2047.91%20A%200.45%200.44%2017.2%200%200%2025.56%2048.47%20C%2028.12%2049.22%2035.16%2050.72%2036.90%2052.43%20Q%2038.92%2054.39%2036.21%2054.48%20Q%2033.33%2054.58%2029.50%2053.79%20Q%2019.39%2051.71%209.25%2049.83%20C%207.27%2049.47%205.11%2048.66%203.49%2047.83%20Q%200.61%2046.36%203.73%2045.50%20Q%204.67%2045.25%206.46%2044.38%20Q%2010.76%2042.31%2026.76%2034.35%20C%2030.51%2032.48%2037.88%2029.46%2041.00%2033.59%20A%200.92%200.91%20-35.3%200%201%2040.77%2034.91%20L%2029.13%2042.42%20Q%2027.57%2043.42%2029.42%2043.22%20C%2053.59%2040.61%2073.35%2028.09%2091.94%2013.14%20Q%2099.20%207.31%20104.72%200.00%20Z'%20/%3e%3c/svg%3e)
