Менеджер технических продуктов — вариант роста для разработчика
Марина Арефьева, консультант по цифровой трансформации, занимающийся развитием платформы цифровизации банка, бывший руководитель направления "Видеоплатформа" МТС, а также преподаватель курса Product manager, рассказывает про роль технического менеджера продукта
От разработки к управлению продуктом
Если вы разрабатываете сложные технические решения, вы, возможно, сталкивались с тем, что некоторым менеджерам не хватает глубины, чтобы корректно формулировать задачи и расставлять их в правильной очередности.
Происхождение роли продакт-менеджера
Исторически менеджеры продукта появились как люди, определяющие товарные характеристики предметов, продающихся в супермаркетах: ведущие переговоры об их расположении на полке, а также отвечающие за цену и внешний вид с целью увеличения продаж.
Этой профессии более ста лет, но большую часть этого времени она была востребована преимущественно в крупных компаниях, ежедневно сражающихся с конкурентами на полках супермаркетов, — например, в Unilever с его каталогом более чем из тысячи различных товаров.
Когда классический продакт перестает работать
В случае если сам предмет менеджмента является глубоко техническим, компания может внедрить роль технического менеджера продукта. Эта роль существенно отличается от классической, так как сложные технические продукты важно не только и не столько «завернуть» в красивый лендинг, сколько определить, создать и донести их смысл до потребителя, зачастую еще и внутреннего: менее технических менеджеров, которым нужны определенные возможности этого решения для собственных продуктов.
Ответственность и зона влияния технического менеджера
Технический менеджер может отвечать, например, за само существование и бесперебойную работу решения, а также за стратегию его развития и очередность работ. Это означает, что он создает и защищает концепции, получает бюджеты и делает все возможное для развития продукта, решения или платформы с целью достижения требуемых показателей.
От технического менеджера обычно ожидают частичного выполнения функций CTO — организации бесперебойной работы ИТ не всей компании, а в рамках конкретного продукта. Чаще всего таким продуктом является платформа, заказчиками которой выступают другие, менее технические коллеги.
Отличия от классического продакт-менеджера
Технический менеджер продукта, так же как и обычный, отвечает на вопросы о жизни продукта, но в меньшей степени сталкивается с маркетингом и продажами. Исключением, пожалуй, являются SaaS-платформы, однако и там возможно разделение ролей — например, с привлечением менеджера с фокусом на маркетинг в пару к техническому.
Стратегия технического продукта
Если говорить формально, технический менеджер продукта определяет стратегию развития вверенного продукта, а также организует ее исполнение таким образом, чтобы были достигнуты необходимые показатели. Именно здесь особенно важен технический бэкграунд.
У технических решений сама стратегия часто состоит из внедрения новых подходов, принципов и решений. Например, в случае задачи поиска текста по сканам архивных документов стратегию необходимо грамотно сформировать, защитить, организовать ее реализацию, включая контроль договоров с техническими подрядчиками и интеграцию с решениями других команд.
Архитектура и интеграции
Около 30 % работы технического менеджера может быть схоже с работой Enterprise Solution Architect, особенно если такой роли в команде нет. Ставить задачи системным архитекторам и аналитикам можно с разной глубиной, однако без понимания того, что такое API и как его интегрировать, постановка задач зачастую выглядит весьма неубедительно.
Релизы и взаимодействие с DevOps
Дополнительно на роль технического менеджера продукта могут ложиться задачи релиз-менеджмента: будь то управление публикациями в сторах или, что встречается чаще, обеспечение нового функционала всем необходимым для запуска в кластере.
Хотя это, как правило, не является основной задачей, DevOps-инженеры и системные администраторы, видя наличие такого руководителя, действуют значительно увереннее, чем в ситуации, когда задачи им пытается объяснить продакт с маркетинговым бэкграундом. Во многом это снимает ключевой конфликт между dev и ops, поэтому некоторые коллеги неформально называют такую роль DevOps-менеджером.
Данные, безопасность и контроль работы платформы
У технических решений существуют и юридические аспекты, связанные с данными: пользовательские соглашения, требования законодательства о персональных данных, GDPR и другие нормативы. Кроме того, остаются актуальными задачи построения observability-стека, работы с аудитом и комплаенсом, а также понимания того, что происходит на платформе в реальном времени.
Операционная модель и автоматизация
У любых продуктов, запущенных в реальную эксплуатацию, появляется операционная составляющая, а значит — сопутствующие расходы либо на персонал, либо на автоматизацию, его заменяющую.
Концепция нулевого операционного обслуживания предполагает, что после запуска решения для его повседневной работы не требуются люди, за исключением, разве что, обслуживания аварий на уровне дата-центров.
Если этой концепции придерживаться, автоматизируется буквально все — даже то, что другим менеджерам может казаться невозможным. Например, 1С может принимать документы по API, а также поддерживает RabbitMQ, что нередко оказывается неожиданностью для коллег.
Организационные аспекты внедрения
Безусловно, остаются и базовые организационные вопросы: приказы о внедрении, создание доменных имен, контроль сроков подписания соглашений и оплаты выбранных технических сервисов. Подобных задач может быть достаточно много.
Код как управленческий инструмент
В итоге у технического менеджера продукта формируется значительный объем работы по определению технического ландшафта и созданию новых решений. При этом даже спустя годы после ухода с позиции разработчика он может продолжать писать код в ограниченном объеме — скорее как инструмент управления, самостоятельно определяя, что именно требует внимания.
В управлении техническими решениями менеджер нередко определяет не только «как делать», но и может брать на себя «право первой строки» и писать начальные фрагменты кода. Например, спецификация может быть передана коллегам в виде примерных скриптов для разворачивания в кластере или шаблонов Vue SFC для служебных страниц админки — вместо объемных текстовых пояснений от бизнес-аналитиков.
Работа с командами и распределение ответственности
В рамках этой роли в функциональном подчинении могут находиться несколько команд: бэкенд ядра решения, DevOps, системные администраторы и, возможно, в меньшей степени — дизайн, маркетинг и фронтенд, хотя они также не исключены. Как правило, у этих специалистов есть собственные тимлиды, поэтому управление осуществляется через взаимодействие с ними, а также через заказ работ смежным командам.
Продукт как платформа
При этом основным объектом управления для технического продакт-менеджера остается не команда, как у тимлида, а сам продукт. Технологическое решение развивается как платформа: расширяются возможности, увеличивается масштаб, осуществляется выход на новые рынки с учетом регуляторных требований, продукт представляется на профильных мероприятиях, чтобы другие команды могли создавать фичи уже на его базе
Где и почему возникает эта роль
Технические менеджеры продуктов востребованы в разных сферах, однако прежде всего там, где технологическая сложность делает продукт непригодным для управления менеджерами, вышедшими из маркетинга или бизнес-анализа. Например, в финансовых технологиях, стриминговых сервисах и SaaS-решениях для разработчиков, таких как IDE.
Переход в роль и развитие
Менеджеры продуктов, технические или нет, часто подхватывают любую работу над продуктом, для которой еще не выделена отдельная штатная единица. В этом смысле роль технического продакт-менеджера может стать шагом к более широкой управленческой позиции, не только технической.
Для перехода в эту роль могут подойти курсы по управлению продуктом и смежным направлениям, таким как маркетинг. Они позволяют разобраться в различных аспектах работы продакт-менеджера, получить базовые шаблоны и, дополнив их собственной доменной экспертизой, заняться развитием технического решения как продукта.
Чтобы эффективно выполнять эту роль, важно понимать полный цикл работы менеджеров продуктов — от генерации идей и защиты стратегии и бюджета до вывода продукта на рынок и его масштабирования.
Перейти в эту роль можно и внутри компании: нередко бывает так, что она просто не формализована, и тогда остается возможность «продать» эту идею руководству.
Хотите развиваться в управлении продуктами и проектами?