Почему релизы в корпорациях буксуют и как ускорить их без потери качества

Корпорации тратят месяцы на запуск фич, но рынок ждать не будет. Как ускорить релизы? Команда Purrweb узнала у лидеров рынка

Эту статью написал автор Блогов компаний

Александр Шульгин

Управляющий партнер Purrweb

Purrweb

Студия разработки мобильных и веб‑приложений для бизнеса

Это авторский текст — редакция ничего не меняла

Написать статью

Иногда про бигтех шутят, что это «пенсия для разработчиков»: одну фичу могут делать полгода, а бесконечные согласования превратились в айтишную городскую легенду. Но в 2025‑м скорость решает все, и такая роскошь уже недопустима. Именно здесь и возникает боль: зарелизить быстро почти никогда не получается.

В Purrweb мы регулярно сталкиваемся с таким запросом. Корпорации приходят к нам, когда нужно за несколько месяцев создать новый IT‑продукт. Переключать инхаус‑команду на непроверенные инициативы рискованно, а нанимать новых специалистов слишком долго и сложно.

В статье мы разбираемся, почему запуск новых решений в корпорациях буксует и какие подходы помогают ускориться. Своим опытом с нами поделились эксперты с опытом работы в Яндекс Практикуме, X5, Газпроме и других крупных компаниях. Материал будет полезен CPO, CIO и CDTO, которые хотят быстрее выводить продукты в релиз и разгружать бэклог задач.

4 причины, почему в корпорациях медленно создают новые продукты

Эксперты, с которыми мы поговорили, чаще всего называют эти причины:

Причины медленной разработки IT-продуктов в корпорациях по мнению экспертов

Детально разберем каждую из них.

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

В корпорациях процессы часто затягиваются: нужно собрать всех заказчиков, выслушать их требования, согласовать каждую деталь. В результате на обсуждения уходит столько же времени, сколько могло бы уйти на саму разработку, как заметил Сергей Пономарёв, CTO Purrweb.

Согласования — одно из основных препятствий быстрой разработки — Долгие согласования — один из главных барьеров на пути новых продуктов

Как подчеркивает Андрей Смирнов, руководитель разработки, ex.X5 Tech, в корпорациях слишком много людей и процессов, на которых завязан запуск продуктов, и каждое решение будет проходить через инвестиционные комитеты, безопасников, юристов, пиар, бренд‑комитеты, финансовые контроли и так далее.

«В итоге на любое стандартное MVP завязывают еще несколько новых этапов и требований. И простой продукт становится совершенно другим задолго до продакшна. В такой форме его не актуально выпускать — иногда от этого отказываются».

Андрей Смирнов

Руководитель разработки, ex.X5 Tech

По словам Владимира Лазарева, CPO в Яндекс Практикум, в больших компаниях те, кто глубоко погружен в задачу и владеет контекстом, оказываются слишком далеко от людей, принимающих решения. В итоге сотрудник, который разбирается в проекте и прицельно работает над ним, не может продвинуть его вперед — решение принимает «руководитель его руководителя» где‑то сверху. Такая система, отмечает спикер, приводит к двум ключевым проблемам.

«Первое — решения принимаются долго, потому что исследование рынка завершено сегодня, а что‑нибудь запускать можно только через две недели, когда у СЕО/СРО/С‑еще‑что‑нибудь‑О будет свободный слот.
Второе — решения принимаются плохо, потому что их принимают те, у кого контекст пусть и гораздо шире, но при этом очень поверхностный. Руководители, как правило, хорошо знают, что происходит вокруг и на всем рынке, но только «по верхам», без глубины».

Владимир Лазарев

CPO в Яндекс Практикум

Ошибки в работе команд. Они могут быть разными — от чрезмерной оптимизации процессов до перфекционизма и потери продуктовой автономии.

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

Команды в корпорациях нередко улучшают то, что и так хорошо работает, и тратят время на оптимизацию процессов. А задачи, связанные непосредственно с продуктом, отходят на второй план.

Скорость разработки страдает, когда каждый шаг требует согласования со стейкхолдерами. Как отмечает Шамиль Зигантдинов, директор продуктов в ИТ‑экосистеме «Лукоморье» (ex. CPO Газпром): «Команда может быть компетентной, но если она зависит от пяти внешних стейкхолдеров — скорость и креативность падают».

Другие типичные ошибки команд, по мнению эксперта, связаны с ориентацией на форму и перфекционизмом. Часто запускаются «платформы», «экосистемы» или «сервисы», у которых нет понятной ценности для пользователя. А стремление довести продукт до идеала приводит к тому, что MVP превращается в многомесячный релиз.

По словам Андрея Смирнова, руководитель разработки, ex.X5 Tech, в итоге команда может уйти в работу над чем‑то более сложным, чем планировалось изначально.

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

Андрей Смирнов

Руководитель разработки, ex.X5 Tech

Фокус на занятости, а не результатах. Во многих компаниях эффективность понимают как полную загрузку команды: все расписано на месяцы вперед, никто не простаивает без дела. Но в разработке такая модель убивает скорость. Чтобы быстро проверять гипотезы, нужны свободные ресурсы и возможность гибко менять курс.

Как замечает Владимир Лазарев, CPO в Яндекс Практикум, эту идею хорошо раскрывает аналогия со скорой помощью или пожарными. Машина должна быть готова выехать в любой момент, поэтому она не может быть занята постоянно.

Иллюстрация того, что разработчики должны быть наготове, когда новый продукт запустят — В разработке нужны свободные ресурсы, чтобы быстро проверять гипотезы и запускать новые продукты

В продуктовой разработке то же самое: «если бэклог расписан на три квартала вперед, любое изменение приоритетов превращается в титаническую задачу внутри организации».

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

Владимир Лазарев

CPO в Яндекс Практикум

По словам эксперта, важно отказаться от ложной эффективности: лучше не делать ничего, чем тратить время на потенциально ненужные задачи. Настоящая эффективность проявляется в способности команды быстро менять курс и проверять гипотезы.

Преобладание проектного управления над продуктовым. Скорость разработки зависит от фокуса — на продукте или результате, на удовлетворении потребностей пользователей или достижении целей.

Шамиль Зигантдинов, директор продуктов в ИТ‑экосистеме «Лукоморье» (ex. CPO Газпром), подчеркивает, что многие компании до сих пор мыслят категориями внедрения «решений», а не развития живых продуктов. И такой подход тормозит скорость итераций и получения обратной связи.

«Также часто акцент делается на соблюдение KPI‑процессов и регламентов вместо реальных метрик продукта (активация, удержание, ROI). Это снижает мотивацию команд и размывает приоритеты. В отличие от лучших практик, где гипотезы проверяются сотнями в неделю, в российских корпорациях любое изменение — это мини‑проект с документацией, согласованиями и рисками “срыва сроков”».

Шамиль Зигантдинов

Директор продуктов в ИТ‑экосистеме «Лукоморье» (ex. CPO Газпром)

Новости

Какие решения помогают ускориться

Если суммировать опыт крупных компаний, то чтобы двигаться быстрее, нужно:

отдавать часть задач и проектов на аутсорс;
стартовать с MVP и простых тестов;
мотивировать команду;
внедрить культуру быстрых релизов на уровне топ‑менеджмента;
собирать фидбек пользователей.

Разберем, как именно эти решения дают буст скорости.

Аутсорсинг IT‑разработки. Российские компании передают на аутсорс более 10% своих IT‑услуг. В 2024 году объем российского рынка IT‑аутсорсинга достиг 262 млрд рублей. Это на 22% больше по сравнению с 2023 годом.

Ключевые преимущества IT-аутсорсинга — Основные преимущества аутсорс‑разработки

Проект попадает к специалистам, которые быстро включаются в работу. Так компания получает готовый продукт в сжатые сроки и оперативно проверяет гипотезу, не тратя месяцы на внутренние согласования. Например, в Purrweb обращался крупный телеком‑оператор: нужно было создать прототип для СКУД‑приложения за месяц. Для инхаус‑команды это было невозможно — был риск того, что все время уйдет на поиск ресурсов.

Прототип СКУД-приложения, разработанного командой Purrweb — Прототип СКУД‑приложения

Аутсорс хорош не только для быстрых прототипов. Очень часто происходит ситуация, когда новый полноценный продукт нужен в сжатые сроки, а основная команда занимается флагманом. Чтобы не отвлекать ее и решить вопрос с нехваткой ресурсов и скоростью, можно нанять аутсорс‑команду.

Принцип «Fail fast, learn faster». Здесь действует та же логика, которую часто применяют в стартапах: надо тестировать идеи на ранних стадиях, а не полировать продукт.

Цикл разработки: каждая новая идея и ее тест ведет к изменениям в продукте — Цикл разработки — от идеи к MVP, а затем — у фидбеку и доработке продукта

Другой вариант — четко обозначить границы MVP и не выходить за них.

«Надо четко обозначить, что именно мы считаем минимальным продуктом, за какой срок планируем его сделать, какие у нас метрики успеха — чтобы не выходить за рамки и не усложнять.
Нужно спокойно принимать, что из множества MVP «выстрелит» лишь один. Неудачи — часть процесса: двигаясь итерациями, мы постепенно приходим к тому решению, которое действительно сработает».

Андрей Смирнов

Руководитель разработки, ex.X5 Tech

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

«Что помогает ускорить разработку:
Минимум процессов, максимум пользы. Например, мы упростили пайплайн фич: гипотеза — быстрая проверка — внедрение. Ни одного лишнего документа на команде развития. Результат — спринты по 2 недели с осязаемыми изменениями.
Меньше слов — больше delivery. В каждой команде должен быть зафиксирован минимальный «ритм успеха» — хотя бы одна релизная поставка в 2 недели.
Фокус на early adopters внутри компании. Даже внутри большого холдинга есть прогрессивные подразделения, которые готовы тестировать новое. С них и стоит начинать».

Шамиль Зигантдинов

Директор продуктов в ИТ‑экосистеме «Лукоморье» (ex.CPO Газпром)

Правильная мотивация команды. По мнению Владимира Лазарева, CPO в Яндекс Практикум, в крупных организациях часто оценивают сотрудников по количеству выполненной работы и закрытых задач. Однако, объясняет эксперт, «количество работы не имеет значения на рынке с высокой степенью неопределенности. Адаптивность подразумевает, что ты делаешь нужное, а не просто много».

Выставить линейным сотрудникам мотивацию за бизнес‑результат непросто, потому что:

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

Свобода и возможность решать творческие задачи повышают вовлеченность и мотивацию. Как отмечает Шамиль Зигантдинов, директор продуктов в ИТ‑экосистеме «Лукоморье» (ex. CPO Газпром), инхаус‑команды могут зациклиться на рутинных задачах, терять гибкость и становиться менее склонными к саморазвитию.

Примерно так чувствует себя сотрудник, когда его ограничивают рутинными задачами и не дают свободы — Как себя чувствует сотрудник без правильной мотивации и развития в команде

Хорошо работает мотивация через причастность: команда становится соавтором продукта, а не просто исполнителем. «В этом плане мы ближе к стартап‑культуре, чем к бюрократии», — добавляет эксперт.

Роль руководителей в ускорении разработки. Скорость релизов во многом зависит от уровня вовлеченности CPO, CIO и CDTO. Роль руководителей здесь не в контроле, а в том, чтобы создать условия, где команды могут быстро принимать решения и проверять гипотезы. Если скорость и гибкость становятся приоритетом для C‑level руководителей, команды перестают бояться ошибок и начинают двигаться к результату быстрее.

Шамиль Зигантдинов замечает если продукт не поддержан сверху — он станет жертвой оргструктуры. Мы встроили регулярные демо и митапы на уровне CPO/CTO и показываем движение через пользовательские метрики, а не статусы задач.

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

Владимир Лазарев, CPO в Яндекс Практикум, предлагает такой подход:

Как можно работать с командой, чтобы сроки проекта не срывались

Обратная связь пользователей. В корпорациях разработка часто буксует из‑за предположений о потребностях пользователей, которые не подкреплены реальными данными. Но чем быстрее команда получает фидбек от пользователей, тем проще ей принимать правильные решения по развитию продукта.

Вывод

В 2025 году скорость — ключ к успеху IT‑продукта. Чтобы команды двигались быстрее, важно:

убрать лишние шаги и бюрократию;
собрать команду с нужными компетенциями;
фокусироваться на бизнес‑результате, а не на объеме работы;
быстро получать фидбек от пользователей;
тестировать идеи через MVP и короткие итерации.

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

Актуальные статьи и свежие тренды