Как меняются компании изнутри и что помогает им двигаться вперед: честные истории с форума «Трансформания»

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

О том, как проходит этот путь эволюции, лидеры рынка рассказали 30 октября на форуме «Трансформания» в Минске. Опытом глубинных изменений со сцены делились эксперты Приорбанка, Сбер Банка, Т-Банка, 21vek.by, ActiveCloud, Onde, Product Lab, «Акселератора ФРИИ» и других организаций.

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

Некоторые из идей и выводов раскрыты в этой статье.

Организация in-house разработки и трансформация IT-подразделений в Приорбанке

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

Модель in-house позволяет оперативнее реагировать на потребности клиентов, формировать внутреннюю экспертизу, а также обеспечивать контроль над качеством, безопасностью и скоростью внедрения цифровых продуктов. Кроме того, самостоятельный выбор технологий и архитектуры дает компании возможность комплексно управлять своим IT -ландшафтом.

Когда Приорбанк решил перейти на in-house разработку некоторых решений, стало понятно, что процесс потребует глубокой структурной трансформации. О новых принципах организации IT и результатах, которые получил банк, рассказал исполнительный директор Приорбанка Виталий Поживилко.

Ранее IT-функция в Приорбанке строилась по классической схеме:

• подразделение управления информационными технологиями;
• департамент развития банковских информационных систем;
• департамент эксплуатации информационных систем.

Такая модель давала высокий уровень управляемости и контроля, но ограничивала команды в гибкости и самостоятельности.

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

Инсорсинг функций разработки программного обеспечения позволил сосредоточить внутри компании все ключевые компетенции для создания и сопровождения IT-решений. Это стало отправной точкой для переосмысления роли IT-блока и перехода к полноценной продуктовой модели.

В ходе трансформации банк перестроил организационную структуру: для каждого потока создания ценности теперь сформирован отдельный департамент, который отвечает и за развитие, и за эксплуатацию информационных систем. Внутри департаментов созданы собственные платформы, позволяющие разрабатывать и поддерживать IT‑компоненты бизнес‑продуктов преимущественно своими силами. Кроме того, за каждым потоком закрепили не только технического лидера, но и Service Responsible Manager, который следит за операционной эффективностью и качеством предоставляемых IT‑сервисов.

Такой организационный дизайн позволил командам мыслить ценностью для клиентов, брать полную ответственность за свои платформы, минимизировать взаимозависимости с другими системами, а бизнес-лидерам трайбов и владельцам продуктов — четко понимать доступный IT-ресурс и его стоимость.

 В результате инсорсинга и внутренних организационных изменений численность IT‑специалистов в Приорбанке выросла на 60%, а работа с персоналом стала важным направлением трансформации. Банк привел уровень зарплат к рыночному, запустил профессиональные сообщества, внедрил индивидуальные планы развития и систему непрерывного повышения квалификации. Эти шаги сделали Приорбанк более привлекательным работодателем и повысили индекс вовлеченности сотрудников до 88%.

В других сферах за год также произошли значительные улучшения: скорость вывода продуктов на рынок выросла на 40%, а 80% систем теперь выпускают релизы не реже одного раза в месяц. Более 40% сотрудников освоили современные  интеграционные технологии, свыше 20% данных хранилища стали доступны пользователям через платформу самообслуживания. Переход на in-house разработку обеспечил более 25% экономии затрат, а время найма специалистов существенно сократилось.

Масштаб без хаоса: как Сбер Банк переработал процессы и перестраивает команды под новую продуктовую модель

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

Анна Макаревич — исполнительный директор и лидер трайба «Розничный бизнес» Сбер Банка, и Мария Савина — руководитель проектов и IT-лидер команды трайба «Розничный бизнес» компании Водород, поделились своим опытом трансформации без революции — через постепенный и управляемый переход к перестройке «продуктового конвейера» с учетом контекста, рисков и культуры компании.

За последний год команды разработки Сбер Банка выросли более чем в два с половиной раза, что затруднило планирование, управление и взаимодействие. Для того чтобы справиться с этими вызовами, банк разработал и внедрил новый процесс препланирования на уровне трайба — кросс-функционального блока, который объединяет несколько команд и отвечает за развитие определенного продукта или системы.

Теперь работа с инициативами строится следующим образом: когда у продакт-менеджеров и бизнес-аналитиков появляются идеи, требующие технической экспертизы, они выносятся на регулярную встречу с участием ИТ-специалистов. Только после прояснения нюансов и доработки формируются детальные бизнес-требования по стандартизированному шаблону, которые затем передаются Product Owner. Далее задачи проходят ревью и попадают в единый бэклог трайба. Эти встречи фактически выполняют роль внутреннего архитектурного совета трайба, где архитекторы и другие ИТ-специалисты помогают бизнесу быстро прояснять технические вопросы.

Затем начинается подготовка к квартальному P&I-планированию (Program & Iteration Planning), где трайб согласует объём работ и ресурсы на ближайший квартал:

• за три недели до мероприятия закрывается прием новых инициатив;
• на две недели все углубляются в преданализ: задачи разбиваются на части и проводится оценка, бизнес-лидеры выставляют приоритеты, IT-лидеры оценивают ресурсы;
• за неделю до P&I-планирования назначается финальная встреча трайба, где согласовываются планы, и предварительный бэклог выносится на согласование куратору блока;
• после утверждения задачи попадают на общее планирование с другими трайбами.

Спикеры также анонсировали следующий шаг трансформации Сбер Банка — переход от «команд вокруг систем» к «командам вокруг продуктов». Банк планирует сформировать продуктовые линии (value stream) — сквозные направления, отвечающие за полный жизненный цикл продукта, и ввести новые роли в трайбе.

Как перейти к продуктовому дизайну

Находясь на новом витке изменений, Сбер Банк поделился кратким планом того, как подготовиться к переходу на продуктовый дизайн команд:

1. составьте каталог продуктов и объедините их в команды или стримы, сохраняя привязку к бизнес-центрам;
2. проведите ретроспективный анализ затрат и компетенций по каждому продукту и стриму;
3. сформируйте долгосрочный бэклог и перечень систем для доработки;
4. определите оптимальный количественный состав команд в разрезе необходимых навыков с учетом ретроспективного анализа и планов по бэклогу;
5. составьте карту компетенций персонала и распределите сотрудников по командам;
6. определите лидеров: Рroduct Оwner и IT-лидера для команд, а также Lead Product Owner и Delivery Lead для стримов (при необходимости один сотрудник может совмещать несколько ролей).

Ничто не догма: как МТС адаптировала Scrum под себя

МТС стремилась создать единую операционную CRM, в которой были бы все клиенты, процессы и полная картина взаимодействия. Первый вариант такой системы оказался нежизнеспособным. Проект долго разрабатывался, включал тысячи страниц ТЗ и документации, но на момент запуска решение уже не соответствовало новым требованиям бизнеса. Этот кейс запустил процесс перехода к Agile. Стало очевидно, что разработка должна идти небольшими шагами, с постоянной проверкой гипотез и учетом того, что потребности меняются быстрее, чем пишется регламент.

Начальник IT-управления бизнес-решений МТС Андрей Малахов рассказал, как строгая иерархическая компания перешла от каскадной модели к Agile.

Первая версия OCRM, которая должна была объединить разрозненные системы из B2B, ритейла и других направлений, не соответствовала насущным задачам бизнеса. Для того чтобы превратить ее в эффективный инструмент, который позволяет видеть и анализировать все процессы и синхронизировать цели, мобильный оператор привлек сторонних разработчиков из команды внедрения. Специалисты работали по Scrum, и, наблюдая за ними, МТС начала заимствовать опыт и постепенно формировать собственную культуру Agile.

Спикер выделил несколько практик, без которых трансформация не состоялась бы:

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

Кейс МТС подтвердил, что гибкость — это не набор предписаний, а способ мышления. Настоящий Agile появляется там, где правила работают на компанию, а не наоборот.

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

Как внедрение стримов превратило отдел разработки 21vek.by в фабрику фич

Когда у крупных e-commerce-проектов появляется сразу несколько точек входа для клиентов, продуктовая логика начинает расходиться: один и тот же сценарий работает по-разному, обновления выходят несогласованно, а бизнес теряет целостную картину развития. В итоге вместо единого продукта получаются фрагменты, собранные усилиями отдельных команд.

Именно с такой проблемой столкнулся 21vek.by, когда вел параллельную разработку сайта и собственного мобильного приложения. Для того чтобы вернуть продукту целостность и выстроить единые принципы развития, компания перешла на модель стримов. Этот шаг позволил ускорить разработку, повысить качество продукта и наладить процесс ранжирования задач. Историей перехода с участниками «Трансформании» поделилась Ольга Кублицкая, начальник отдела веб-разработки 21vek.by.

Для онлайн-гипермаркета это был новый опыт — ранее в компании не было полноценной мобильной разработки. Работы по сайту и приложению шли обособленно и без единой логики. Шесть команд занимались web‑направлением, три — mobile, но за весь бэкенд несли ответственность «сайтовые» команды. Такая структура порождала зависимости, вызывала конфликты приоритизации и приводила к срывам сроков. В итоге бизнесу было сложно понять, кто именно отвечает за конечный результат.

«Если проводить аналогию, то наши команды напоминали не оркестр, а группу солистов, где каждый играл свою партию. Бизнес, в свою очередь, получал не слаженную мелодию, а какофонию звуков», — отметила спикер.

Для того чтобы превратить хаос в гармоничную систему, компания внедрила стримы. Продукт разделили на три ключевых направления: «Аккаунт», «Покупка» и «Товар». Каждый стрим стал автономной бизнес-единицей со своим Product Owner, delivery-менеджером и объединенными командами разработки. Теперь сайт, мобильное приложение и бэкенд работают вместе, а зона ответственности стрима охватывает не только функциональность, но и бизнес-метрики, техническое развитие и качество продукта.

За полгода 21vek.by  сократил зависимости: сейчас почти 90% задач закрываются внутри одного стрима. Бизнес получил четкие дорожные карты, что позволяет получать результат в ожидаемые сроки. Кроме того, постепенно сформировалась культура владения: команды начали воспринимать свои зоны как полноценные продукты, предлагать идеи и улучшения.

Рекомендации от 21vek.by для успешной трансформации:

• адаптируйте процессы под себя, а не под учебники;
• вовлекайте команды в изменения — это снижает сопротивление;
• фокусируйтесь на бизнес-целях, а не на жесткой структуре;
• запасайтесь терпением: трансформация не бывает мгновенной.

Как измерить выгоду фич до их запуска: опыт компании Onde

Если предыдущие выступления форума подсветили, как перестраивать команды и процессы, то кейс Onde показал другую сторону продуктовой зрелости — умение принимать решения, опираясь на экономику, а не только на интуицию или ожидания. Компании выпускают десятки фич, но лишь единицы оказывают реальное влияние на прибыль, конверсию или удержание. Если бизнес не умеет считать ROI изменений до начала разработки, он теряет деньги, время и фокус.

Вадим Станкевич, Head of Growth компании Onde, на примерах разобрал, почему даже нужные фичи могут не окупиться, и рассказал о подходе, который позволяет заранее просчитать экономику их разработки.

Компания выстроила процесс, который помогает оценить рентабельность (ROI) фичи, устранения бага или UX-улучшения до старта разработки. Он состоит из двух этапов:

• MVP-эксперименты: проверка эффективности идеи с минимальными затратами. Команда добавляет имитацию или упрощенную функцию в приложение и смотрит, насколько она востребована у клиентов;
• Planning Poker: оценка стоимости разработки исходя из результата эксперимента.

У прибыли от продуктовых изменений есть два компонента:

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

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

Рекомендации, которые помогут правильно оценить потенциал продуктовых изменений и расставить приоритеты:

• примите за аксиому, что аналитика, эксперименты и discovery-процессы — это не дополнительная опция, а основа зрелой продуктовой разработки;
• учитывайте, что первые результаты внедрения новых фич почти всегда завышены — смотрите на эффект в динамике;
• сосредоточьтесь на тех изменениях, которые по оценкам дадут максимальный выхлоп, чтобы собрать «низко висящие фрукты»;
• концентрируйтесь на главном — генерации и проверке гипотез для улучшения показателей. Построение дерева метрик, поиск и выявление самых проблемных мест в продукте можно зааутсорсить внешним консультантам;
• не бойтесь отказываться от идей, даже если они кажутся «красивыми», но не дают ценности.

Формула запуска востребованных продуктов от «Акселератора ФРИИ»

Выступление Центра корпоративных инноваций и продуктового развития «Акселератора ФРИИ» фактически раскрыло главную идею форума: трансформация — это не набор инструментов, а способность компании синхронизировать стратегию, процессы и людей вокруг общего результата. Представленная формула 3P стала концентратом всего, о чем говорили спикеры на протяжении дня: изменения должны происходить одновременно на трех уровнях — организационный дизайн и процессы, продукты, люди и компетенции. Только в этой связке трансформация перестает быть формальностью и начинает приносить бизнесу реальную ценность.

Сегодня новые продукты выводятся на рынок с беспрецедентной скоростью: треть компаний России и стран СНГ еженедельно выпускает релизы, а 32% одновременно ведут разработку сотни инициатив. Однако за этим впечатляющим темпом скрывается тревожная статистика: более половины продуктов, уже выведенных на рынок, остаются невостребованными. Об этом говорят результаты исследования «Как устроены продуктовые команды в 2025 году: структура, процессы, зарплаты, карьерные треки», которыми с участниками форума поделилась Анна Русакова, директор Центра корпоративных инноваций и продуктового развития «Акселератора ФРИИ».

Опрос показал, что компании сталкиваются с целым рядом проблем: дефицитом ресурсов и бюджета, отсутствием единых процессов и фреймворков, слабым взаимодействие между CPO и бизнес-заказчиками. Что касается результативности команд, то лишь 47% продуктовых инициатив достигают своих целей. Остальные «сгорают» из-за нехватки системной аналитики, разрозненности подходов внутри компаний, слабой приоритизации и неспособности измерять реальный бизнес-эффект.

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

• products — рассчитывать бизнес-эффект от каждого продукта, определять метрики и приоритизировать гипотезы;
• processes — внедрять единые механизмы и циклы работы, которые сокращают споры и дают прозрачность на уровне всей компании;
• people — проводить регулярную диагностику продуктовых компетенций, прокачивать навыки и выстраивать персональные траектории развития сотрудников.

Ключевые эффекты, которые приносит работа по 3P-фреймворку

• Синхронизация стратегических приоритетов компании и метрики успешности продуктов: осознание командами степени своего влияния на бизнес-результат.
• Улучшение продуктовых метрик: сокращение time-to-market и time-to-value, рост конверсии гипотез, повышение соответствия планируемого действительному и окупаемости инвестиций в продукт.
• Отлаживание процессов product-discovery и product-delivery, что позволяет быстро проверять гипотезы и создавать востребованные рынком продукты.
• Наращивание внутренней экспертизы продактов, что способствует формированию и развитию продуктовой культуры в компании.

Форум показал, что трансформация — это индивидуальный, но неизбежный процесс.  Компании могут отходить от догм и учебников, адаптируя инструменты под собственные задачи и внутренние приоритеты. Однако сами изменения нельзя обойти стороной, если бизнес хочет быть быстрым, гибким и устойчивым.

Главное — не гнаться за модными трендами ради видимости прогресса, а четко понимать цели трансформации и уметь оценивать реальный бизнес‑эффект. Только тогда изменения превратятся из формальности в источник ценности для компании и ее клиентов.

Форум организовала команда Digital Line.

Партнеры мероприятия: Cotvec, ProFacilitation.

Поделиться в социальных сетях: