Один руководитель продуктового и технологического развития: временный компромисс или новая управленческая норма?

24.08.26

Саморазвитие - Компетенции и навыки

Почему компании объединяют управление продуктом и технологиями в одной роли – и когда такое решение действительно оправдано? Разбираем на практическом опыте команды 1С, какие преимущества дает роль CPTO, почему она ускоряет принятие решений и упрощает взаимодействие с бизнесом, но одновременно повышает когнитивную нагрузку и создает риск перекоса между продуктом и технологическим развитием. Показываем, почему для крупного бизнеса такое совмещение может оказаться лишь временным компромиссом, в каких условиях модель работает устойчиво и какие механизмы – от квот на техдолг до независимого архитектурного контроля – помогают сохранить баланс.

В этой статье хотелось бы поговорить о совмещении двух ролей. CPO и CTO – это временный компромисс или новая управленческая норма?

 

 

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

 

Что такое CPO, CTO и CPTO

 

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

Это актуально даже для внутренних продуктов. Мы в компании применяем эти метрики как для внешних, так и для внутренних продуктов. Наши пользователи 1С – это наши же клиенты.

Важно отметить, что CPO также управляет рисками, маркетинговой стратегией и в целом работает со всей командой – как IT, так и с управленцами продуктами.

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

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

Есть исследование Gartner от 2025 года, Leadership Vision, где эта должность называется продолжением карьерного развития CPO либо CTO.

 

Почему мы объединили эти роли

 

Перейдем к нашему примеру. Мы большой телеком-оператор и довольно крупная экосистема. У нас в компании больше тысячи продуктов и тысячи сотрудников.

Почему важно об этом сказать? Мы прошли продуктовую трансформацию, перешли от проектного подхода к продуктовому, сформировали IT-команды, ввели роли CPO, CTO, техлидов, архитекторов.

В целом все это позволило нам улучшить понимание того, как мы можем выводить продукты на рынок. Мы синхронизируемся между продуктами и командами по SAFe, так как у нас очень много продуктов и нам нужно правильно выстраивать метрики. У нас есть PI-планирование, QBR – все, что касается Agile и управления продуктами.

Что касается нашей команды и того, почему мы пришли к решению объединить эти роли. Команда 1С в нашей компании – это относительно новое направление. За последние пять лет мы выросли практически в пять раз, сформировали продуктовые команды. У нас работает больше 50 человек, а также у нас много компаний на поддержке.

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

Изменилась роль 1С в компании. В связи со всеми событиями к нам стало больше внимания и стало больше потребности в нас. Изменилась стратегия ERP в целом в компании. Сильно увеличились сроки найма специалистов из-за внешней среды.

Все эти вызовы и предпосылки заставили нас объединить две роли в одном человеке. Это позволило команде понимать, что у нее есть единый лидер, а бизнесу – независимо от направления и специфики – к кому обращаться.

 

Почему другие компании объединяют CPO и CTO

 

Давайте посмотрим, как другие компании справляются с ролью CPTO и зачем они ее у себя вводят.

 

 

В целом у всех компаний есть четыре основных пункта. Первый – экономия ресурса как ФОТа, так и CAPEX, OPEX за счет того, что эти роли объединены.

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

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

И еще один фактор – давление бизнеса. Под давлением бизнеса я имею в виду то, что, думаю, совсем не секрет: бизнесу часто неинтересно, как устроено IT, на что мы разделены и как работаем. Им важно единое входное окно. И эта роль помогает и помогала нам разговаривать с бизнесом на одном языке и учитывать технологическую стратегию.

 

Что происходит при объединении ролей

 

 

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

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

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

Также хотелось бы отдельно проговорить конфликт между CPO и CTO. Мы в компании все-таки не считаем, что это конфликт. Это переговоры, и мы стараемся вести эту позицию как win-win, находить решение.

Когда человек один, ему сложно справляться и смотреть на развитие продукта с обеих сторон. Когда эти роли разделены, CPO имеет возможность развивать продукт, CTO – развивать технологическую стратегию и находить не компромисс, а именно позицию, когда оба в этом направлении выигрывают.

 

Что произошло у нас в команде?

 

Мы совмещали эти роли примерно год. К чему мы пришли и как это у нас происходило?

 

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

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

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

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

Но на продолжительный период времени и для дальнейшего развития мы все-таки отказались от такой должности. Последние полгода искали CTO в команду, успешно его вывели и действительно видим сейчас положительный результат.

 

Когда модель возможна?

 

 

Однако я не считаю, что эта модель совсем невозможна. В том же исследовании указано, что в среднем и малом бизнесе, где в целом часто объединены не только роли CPO и CTO, но и другие роли, это возможно.

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

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

 

Если роли уже объединены – что спасает

 

Мы выработали стратегию, по которой работали этот год.

Мы формализовали правила баланса: с какими вопросами и к кому все-таки можно приходить.

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

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

Мы разделили KPI. Даже у одного человека в объединенной роли были выделены квоты на разные направления. Это помогало понимать на год, какие задачи все-таки стоят перед продуктом.

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

 

Вывод

 

Личный вывод из такого совмещения: в малом бизнесе модель работает, в крупном бизнесе мы бы не рекомендовали объединять эти роли.

Однако, когда меня спрашивают: «А лично для тебя или для сотрудника, который находится в этой роли, стоит ли на нее соглашаться?», я отвечаю: «Да, стоит».

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

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

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.

Инфостарт Tech Event 2026

Инфостарт A&PM Event 2026

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

Обучение и наставничество Компетенции и навыки Подбор персонала и собеседования Бесплатно (free)

Разбираем, почему привычная модель найма перестает работать и как компаниям выстраивать развитие специалистов в условиях дефицита кадров и новых ожиданий сотрудников. Показываем, как связка HR и тимлида помогает превращать новичков без проектного опыта в самостоятельных специалистов без перегрузок и потери качества. Объясняем, как сетка грейдов, ABC-классификация задач, индивидуальные планы развития и регулярная обратная связь делают рост прозрачным, помогают вовремя выявлять зоны развития и повышают мотивацию. Материал будет полезен тимлидам, HR-специалистам и руководителям IT-направлений, которые хотят сократить текучесть, сформировать кадровый резерв и не допустить кадрового голода в ближайшие годы.

17.08.2026    266    0    user2135145    3    

0

Компетенции и навыки Мотивация Бесплатно (free)

Рассказываем, чем оценка руководителя ИТ-проекта отличается от оценки других участников команды и почему для РП важны не только профессиональные знания, но и системное мышление, переговоры, управление рисками и ожиданиями. Разбираем, как выстроить сбалансированную систему мотивации, которая учитывает продуктовые метрики, сроки, качество, удовлетворенность клиента и рентабельность проекта. Объясняем, когда уместны оценка 360 градусов и обратная связь от заказчика, а также всегда ли ошибки команды находятся в зоне ответственности руководителя. Также продемонстрируем, какие косвенные показатели – от текучести и переработок до повторных контрактов и характера эскалаций – помогают оценить реальную эффективность РП.

04.08.2026    442    0    user2136222    0    

0

Компетенции и навыки Бесплатно (free)

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

04.08.2026    524    0    YA_826532418    0    

4

Продуктовый подход Бесплатно (free)

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

03.08.2026    3153    0    user596192_shiiisha    0    

2

Лидерство Компетенции и навыки Управление ИТ-департаментом Бесплатно (free)

Главная иллюзия ИТ-управления – вера в то, что правильные процессы, модные технологии и подробные регламенты сами приведут к результату. Показываем, как эта иллюзия разбивается о реальность. Результат создают мотивированные и компетентные люди, которым процессы помогают работать, а технологии решают конкретные бизнес-задачи, а не просто выглядят современно. Объясняем, почему ИТ-руководитель – это прежде всего лидер, который синхронизирует людей, процессы и инструменты в условиях ограниченных ресурсов, давления бизнеса и постоянных изменений. В статье разбираем типичные ловушки найма, мотивации, контроля, Agile, сервисности, планирования, внедрения ИИ, работы с вендорами и техническим долгом – и показываем, как сохранять романтику управления без розовых очков.

28.07.2026    483    0    GSoft    0    

4

Компетенции и навыки Россия Бесплатно (free)

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

24.07.2026    399    0    NikolayMaerov    1    

4

Компетенции и навыки Бесплатно (free)

В 1С прижилась странная штука - архитектор бывает «функциональный» и «технический», как будто это две разные профессии. У программистов такого раскола нет, у тестировщиков нет, а у архитекторов - есть. Откуда он взялся именно в таком виде и почему именно сейчас становится только актуальнее? Можно конечно сказать - «так сложилось», но мне интересно, почему все-таки сложилось именно так. За этим стоит конкретная логика, ее корни - вообще не в мире разработки.

23.07.2026    1156    0    ardn    12    

17

Компетенции и навыки Руководитель проекта Россия Бесплатно (free)

Руководитель отвечает за результат, но не обязан лично вести каждое техническое или предметное решение.

16.07.2026    392    0    NikolayMaerov    8    

3
Для отправки сообщения требуется регистрация/авторизация