Елена прошла путь от специалиста в банковском ИТ до управления сложными технологическими инициативами в одной из крупнейших технологических компаний России. За плечами — успешная реализация проектов в области рекламных технологий с применением машинного обучения и участие в создании распределенных систем хранения и передачи данных.

Сегодня Елена выступает одновременно как  Project manager и Product owner системы потоковой передачи данных в крупной отечественной технологической компании. Работая с распределенной отказоустойчивой СУБД с открытым исходным кодом, она накопила большой опыт управления сложными техническими проектами. В нашем интервью Елена рассказывает, как находить баланс между продуктовым и проектным подходами и сохранять фокус на бизнес-ценности, не теряясь в технических деталях.

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

— Я бы сказала, что сегодня я работаю в пограничной зоне между Product и Project management, и именно это сочетание особенно эффективно для сложных технических продуктов.

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

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

— Как ваш технический бэкграунд помогает в продуктовой работе?

— Техническая экспертиза — это настоящее преимущество в моей работе. Когда вы глубоко понимаете архитектуру системы и взаимодействие её компонентов, разработчикам гораздо сложнее отмахнуться фразами вроде «это невозможно реализовать» или «на это потребуется полгода».

Иногда я предлагаю команде рассмотреть быстрое прототипное решение как вариант MVP — не потому, что разработчики до этого не додумались бы сами (они, безусловно, технически сильнее меня), а чтобы ускорить получение обратной связи от пользователей. Конечно, в таких случаях приходится убеждать инженеров, которые естественным образом тяготеют к созданию технически совершенных систем, в целесообразности «быстрого и грязного» подхода для решения конкретных бизнес-задач здесь и сейчас. После обсуждения мы вместе оцениваем применимость такого решения, его плюсы, минусы и перспективы дальнейшего развития.

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

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

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

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

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

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

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

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

Что касается надежности, это независимое от «инновационности» требование. Любая система, независимо от применяемых технологий, должна соответствовать установленным требованиям по отказоустойчивости и производительности. Если система, использующая передовые алгоритмы, не отвечает базовым требованиям надежности — какая от неё польза?

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

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

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

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

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

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

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

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

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

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

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

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

— Довольно часто в технических продуктах возникает конфликт между желанием разработчиков сделать красивое техническое решение и бизнес-потребностями. Как находить правильный баланс?

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

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

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

— Какие навыки, помимо технической экспертизы, вы считаете критически важными для проект-менеджера, работающего с технологически сложными продуктами?

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

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

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

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