Привет, Хабр! Меня зовут Денис Улизко, я CPO CRM-системы Automation of Sales (AoS) в B2B-блоке МТС. Это тот самый продукт, вокруг которого крутится большая часть моего дня. Я уже не первый год в этой роли, но каждый раз убеждаюсь: она про баланс между хаосом и структурой, а не про красивые концепции. В один день — архитектура, в другой — инцидент на проде, вечером — охота за фокусом. Сегодня расскажу, как эта роль выглядит изнутри на примере AoS, как проходит мой рабочий день, какие решения приходится принимать и как удерживать баланс между операционкой и фокусом на ценность для бизнеса и пользователей. Погнали!
Пару слов о том, что мы строим и почему это непросто
Automation of Sales (AoS) — внутренняя CRM-система для B2B-направления МТС, через которую проходят продажи, лиды, партнерские сделки и аналитика. Она появилась, когда стало ясно, что западная CRM больше мешает, чем помогает: она дорогая, сложная и плохо вписывается в реальности российского рынка. Мы захотели сделать свое решение — гибкое, ма��штабируемое и «человечное».
Путь был непростым. Первые полтора года AoS несколько раз пытались запустить, но выбранное решение не закрывало потребности бизнеса. Ситуация изменилась, когда мы пересобрали команду, процессы и стратегию — и только после этого AoS вышла на промышленный контур.
Сейчас в AoS три продуктовые команды по доменам клиентского цикла:
Team #1 — отвечает за начало и завершение пути клиента: лиды, коммуникации до покупки, мотивацию и отчетность после сделки.
Team #2 и Team #3 — фокус на процессе продаж: от предпродажи до оформления сделки.
Но главное — AoS стала ядром B2B МТС. А это значит, что мой день разбит на разные типы задач — от операционки и приоритизации до стратегических развилок.
Коммуникации — это основной инкремент работы CPO
Через эту роль проходит все — от операционки до приоритизации и стратегических развилок.
Операционное управление
Это про постоянное движение: держать процессы в тонусе, вовремя реагировать и не терять темп. К операционным задачам относятся регулярные дейлики и статус-встречи. Обычно я подключаюсь к ним раз в два цикла — чтобы убедиться, что процессы не буксуют и команда двигается в ритме.
Пропустишь важный сигнал — потом придется включать «ручное управление»: чинить, разбираться, перепроверять. Поэтому я регулярно заглядываю на дейлики: сегодня в одну команду, завтра в другую, послезавтра — в третью. Это помогает держать руку на пульсе: следить, что договоренности выполняются, сроки не плывут, а фокусы не теряются.
Если вижу отклонения — реагирую заранее, еще до того, как они превращаются в проблемы, влияющие на продукт, бизнес и дедлайны.
Приоритизация и работа с бэклогом
Это один из самых активных блоков моей работы как CPO. Здесь проходят два ключевых типа встреч:
Backlog Prioritization — выставление приоритетов и согласование фокуса. Это сессия, где вместе с продактами оцениваем бэклог с точки зрения влияния на цели продукта. Здесь мы решаем, что пойдет в ближайшие спринты, а что стоит отложить. Иногда достаем идеи из «долгого» бэклога, если они могут сильнее повлиять на метрики. Если уже на этом этапе видно, что часть задач не помещается в спринт, проводим реприоритизацию — корректируем фокус, чтобы не терять темп.
PBR (Product Backlog Refinement) — уточнение и детализация выбранных задач. Это следующий шаг, где мы вместе с командой детализируем отобранные задачи: уточняем требования, формулируем value и dependencies, проверяем связь с другими фичами. Мне важно, чтобы команда не просто понимала, что делаем, но и осознавала зачем.
Такой порядок позволяет сохранять прозрачность приоритизации и качество проработки задач — без потери скорости.
Ключевые развилки развития продукта
Те самые моменты, когда команда принимает решения, способные повлиять на архитектуру и пользовательский опыт. Именно поэтому CPO должен быть рядом — на таких встречах закладывается фундамент продукта.
Если у команды появляются сомнения или несколько вариантов реализации, задача CPO — указать вектор мышления и помочь выбрать направление. Одно решение на этом этапе может сэкономить месяцы работы. Или обернуться дорогим рефакторингом. Чем позже корректируешь курс, тем выше цена: команда теряет спринты, ресурсы и доверие бизнеса.
Пример из практики AoS. Один из таких случаев — задача по доступу в личный кабинет. В системе есть две ключевые сущности: клиент и представитель. Казалось бы, мелочь — решить, где хранить данные ЛК: в клиенте, в представителе или вынести в отдельную сущность. Но именно от этого зависели архитектура, агрегация данных и будущие сценарии масштабирования.
После обсуждения мы решили: личный кабинет должен быть автономной сущностью. Он связан и с клиентом, и с представителем, а значит, не должен «принадлежать» ни одной из сторон. Выбери мы другой путь — через пару релизов пришлось бы городить костыли, чтобы обеспечить доступ обеим ролям. А дальше вырастали бы проблемы с интерфейсом: контексты клиента и представителя разные, и поддерживать их стало бы все сложнее.
Так выглядят типичные развилки, где от одного решения зависит не просто архитектура, а устойчивость всего продукта. В сложных системах таких точек много, и задача CPO — вовремя их распознать.
Коммуникация со стейкхолдерами
Еще один ключевой элемент роли CPO. Коммуникация со стейкхолдерами — это не просто отчетность, а постоянное выравнивание контекста между бизнесом и продуктовой командой.
На регулярных встречах мы обсуждаем:
как продвигается реализация планов;
какие бизнес-потребности уже закрыты, а какие требуют внимания;
когда ждать следующих улучшений;
где могут быть риски или отклонения от целей.
Чем ближе продукт к бизнесу, чем прозрачнее коммуникация, тем проще принимать решения, не теряя фокус. Поэтому моя цель на таких встречах — перевести язык технологий на язык ценности: объяснить не только что мы делаем, но и почему это важно для бизнеса. Это помогает выстраивать доверие и получать поддержку в нужные моменты.
Когда стейкхолдеры видят понятную картину, они становятся союзниками продукта. Профит для всех: команда получает ресурсы и ясность, бизнес — результат и прогнозируемость.
Решение сложных кейсов
В работе CPO кризисные ситуации неизбежны — как бы идеально ни был выстроен процесс, однажды что-то обязательно пойдет не по плану.
Это могут быть:
проблемные кейсы — когда нужно быстро найти решение между командами или пересоб��ать приоритеты или когда процесс буксует из-за коммуникаций либо ответственности;
инциденты — поломки, влияющие на пользователей и бизнес.
И здесь моя задача — контролировать работу с каждым случаем, помогать командам договориться и разбирать причины, чтобы инциденты не повторялись.
Вот пример проблемных кейсов из практики. Перед запуском нового сегмента бизнеса появилось дополнительное требование по отчетности — без него переход на новую платформу могли просто заблокировать. Проблема в том, что команда, отвечающая за отчеты, не успевала: срок реализации — несколько месяцев, а запуск должен был состояться через две недели. Приоритеты уже распределены, и никто не хотел влезать в чужую зону ответственности.
Я собрал обе команды, чтобы быстро найти выход. Вместо того чтобы перекраивать дорожную карту, предложил альтернативное решение:
команда компании берет на себя разработку отчета (у них подходящая экспертиза и свободные ресурсы);
наша команда оперативно формирует и поставляет данные, чтобы не дублировать работу аналитиков.
Такое разделение позволило обойти бюрократические барьеры, сохранить сроки и не создавать технический долг. Итог — запуск состоялся вовремя, бизнес получил нужную отчетность, а команды — четкое понимание, как можно быстро договариваться без потери качества.
Работа с инцидентами
Инциденты напрямую влияют на пользователей, поэтому важно анализировать их категории и повторяемость. Если они возникают по одной и той же причине — значит, нужно чинить систе��но, а не затыкать дыру. Еще важно смотреть на качество реакции техподдержки: если бизнес или пользователи недовольны скоростью, нужно разбираться не только с техникой, но и с процессом коммуникации.
Отдельное внимание уделяется финансовым последствиям инцидентов. CPO должен понимать, куда уходят деньги продукта при решении критических кейсов: какие категории списаний наиболее частые, где расходы можно оптимизировать, а где стоит усилить контроль, чтобы не платить дважды за одну и ту же ошибку.
Встречи с командой
Даже при высокой загрузке нельзя терять связь с командой. Коммуникация — основа доверия, особенно когда продукт сложный и долгосрочный.
Встречи 1:1 помогают понять индивидуальный контекст: кто устал, кому нужна поддержка, где назревают недопонимания. Это место, где можно обсудить то, что не поднимается на общих встречах.
Общие командные встречи (Pulse) — наш регулярный ритуал, где мы с лидами держим команду в одном контексте: что сделали, что улучшили и куда движемся дальше. Обычно обсуждаем три вещи:
как чувствует себя команда и где можно усилить процессы;
что изменилось в продукте и какие результаты уже видны;
какие приоритеты и цели стоят на ближайший горизонт.
В основе Pulse — презентация, которую мы используем как инструмент донесения информации и визуализации прогресса. Это помогает команде видеть общую картину и понимать, как меняется продукт.
Такие встречи позволяют команде чувствовать, что ее работа видна, а цели — общие.
Это мощный инструмент вовлеченности и внут��енней устойчивости команды.
Офлайн-работа: когда встречи закончились
Когда день из встреч заканчивается, начинается вторая часть моей работы — офлайн-операционка. Это тот самый момент, когда календарь наконец молчит, но мозг все еще на стендапе. В это время я систематизирую информацию, готовлю материалы, гаю писать мэппингпроверяю процессы и принимаю решения, требующие концентрации.
Подготовка к встречам — отдельный пласт работы. Сюда входят создание презентаций и материалов для команды и стейкхолдеров, вычитка артефактов, сбор данных для отчетов. Я часто использую Figma, диаграммы и мэппинги — они помогают визуализировать сложные зависимости и донести идею быстрее, чем текст.
В презентациях для меня важна не визуальная «красота», а ясная структура: чтобы любой участник встречи сразу понял, о чем речь. Поэтому материалы получаются подробными — с буллитами, схемами и тезисами.
Работа с данными. Еще одно направление — анализ метрик и финансовой отчетности.
Я смотрю, как изменяются ключевые показатели продукта, какие метрики проседают и почему.
Это помогает вовремя заметить отклонения и скорректировать приоритеты.
Работа с процессами. Иногда во время анализа вижу, что процесс не работает так, как задумывалось. Тогда я пересобираю его с нуля или переформатирую текущий, чтобы убрать лишние шаги и ускорить взаимодействие между командами.
Такие изменения часто не видны извне, но именно они влияют на то, как быстро и стабильно работает продукт.
Работа с почтой. Тут у нас постоянный поток писем, вопросов и уточнений. Не все можно автоматизировать, поэтому важно быстро определять, какие сообщения требуют моего участия, а какие можно делегировать. Это не самая зрелищная часть дня, но без нее все остальное просто не будет двигаться.
Обучение и развитие команды
Среди всех задач в роли CPO меня особенно вдохновляет обучение людей. Мой путь в ИТ был непростым, и в нем было очень много самодеятельности и ошибок. Когда я начинал, рядом не было человека, который мог бы что-то подсказа��ь и направить. Поэтому теперь я стараюсь быть таким человеком для других — помогать ребятам пройти путь быстрее и с меньшими ошибками, не тратить время на изобретение велосипеда.
В свободное от операционки время я разрабатываю внутренние курсы и программы обучения. Они помогают команде выровнять уровень знаний — ведь у всех разный бэкграунд и опыт. Обычно это онлайн-программы, позволяющие подружить теорию и практику. Например, разобраться, как сегментировать клиентскую базу, проводить качественные и количественные исследования, строить CJM и находить инсайты в данных.
Такие сессии прокачивают не только специалистов, но и команду в целом. Ребята начинают говорить на одном языке, быстрее понимать друг друга и принимать решения осознанно. В результате мы можем делать больше и лучше — и для бизнеса, и для пользователей.
Что в итоге
Примерно так строится мой рабочий день в роли CPO продукта AoS в МТС — от встреч и приоритизации до операционки и обучения команды. Работа многослойная: где-то нужно включаться стратегически, где-то — тактически, а иногда просто быть рядом и поддержать команду.
Главные выводы, которые хочется подсветить:
Работа CPO — это не только стратегия, но и постоянные коммуникации. Через встречи проходят почти все решения — от архитектуры до приоритетов.
Продукт двигается быстро только тогда, когда выстроены процессы и понятны роли. Иначе хаос неизбежен.
Чем раньше CPO включается в ключевые развилки (архитектурные, продуктовые, UX), тем меньше переделок и техдолга.
Команда — основной актив. Регулярные встречи, прозрачная коммуникация и обучение дают энергию и устойчивость.
Баланс между стратегией и операционкой — навык, без которого продукт не растет. Важно уметь вовремя переключаться между «делать» и «думать».
CPO — это должность не про контроль, а про осознанное направление движения. Твоя главная задача — сделать так, чтобы продукт и люди шли в одном ритме.
А теперь вы расскажите, с какими задачами чаще всего сталкиваетесь в роли продактов или CPO. На что уходит больше всего времени — на людей, процессы или продукт? Делитесь опытом в комментариях — обсудим, сравним, и, возможно, кто-то найдет для себя пару инсайтов!