Product engineering — способ повысить свою ценность как инженера

Product Engineer — понятие, которое наряду с software engineer все чаще встречается как на Западе, так и у нас. Ориентированность на продукт — одно из перспективных направлений, в которых может развиваться инженер, повышая свою ценность для продукта и, соответственно, свой уровень дохода.

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

Кто такой Product Engineer

Изначально термин Product Engineer пришел из промышленности. В производственном цикле это отдельный специалист, который управляет процессами дизайна и разработки продукта, контролирует его качество и отслеживает соответствие ожиданиям потребителей. Таким образом, он выступает связующим звеном между пользователем и производством. В IТ эту роль чаще всего выполняет связка Business Analyst и Project/Product/Delivery Manager.

Применимо к software engineering термин Product Engineer появился на форумах и блогах в последние несколько лет. Так, в 2017 году в Forbes вышла статья How Is A Product Engineer Different From A Full-Stack Engineer?, как результат дискуссии на Quora. В ней говорится о том, что product engineering — это, скорее, подход к разработке, где инженеры ориентируются не на набор фич, которые необходимо реализовать, а на свойства продукта, которые нужны пользователю.

Следовательно, Product Engineer, помимо расширения технических навыков и оттачивания своих ключевых компетенций (непосредственно software development), сосредотачивается на смежных областях: продакт-менеджменте, бизнес-аналитике и пользовательских интерфейсах. Это не значит, что Product Engineer должен уметь все и сразу и один заменять полноценную команду. Эта роль — классический пример концепции T-shape.

В основе навыков лежит software engineering — главная экспертная компетенция. Горизонталь — это так называемые кросс-дисциплинарные знания. В нашем случае это основы product management и design, необходимые для того, чтобы инженер мог видеть целостную картину и не просто реализовывать техзадание, а предлагать технические решения с учетом «интересов» конечного продукта.

Таким образом, Product Engineer, вместо того чтобы ждать от Product/Project-менеджеров подготовленные задачи из бэклога, сам является активным участником его формирования и при этом глубоко понимает потребности и ограничения бизнеса.

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

Product Engineer вовлекается в создание продукта на максимально ранних стадиях. Мы, например, начинаем работу над любым продуктом (или новыми большими фичами) с такого процесса, как inception, в котором задействованы основные участники проекта: менеджеры продукта, инженеры и дизайнеры. Если мы работаем над реализацией идеи клиента, то inception проходит с участием как клиентской, так и нашей команд.

Процесс включает в себя изучение и валидацию идеи продукта, определение портретов пользователей, их проблем и существующих решений на рынке. Его цель — определить соответствие продукта требованиям рынка (product/market fit) и обозначить минимальный жизнеспособный продукт (MVP), который будет ему соответствовать. И только после этого мы переходим к технической детализации. Подробнее о процессе и его этапах можно почитать в статье Agile Product Inception в нашем блоге.

При таком подходе Product Engineer видит целостную картину проекта, над которым он работает, может оценивать целесообразность того или иного функционала, генерировать идеи и презентовать их команде.

В Railsware мы отдали предпочтение продуктовости, потому что в основном работаем со стартапами и корпорациями, которые хотят построить новые продукты в рамках своей организации. О нашей модели бизнеса, трансформации и работе с продуктами вы можете прочесть в моих статьях «Product Studio как способ выйти из тупика аутсорсинга» и «Outsourcing vs software consultancy: как поднять рейты до 75 USD/час». В этой статье я хочу акцентировать внимание на особенностях и преимуществах такого подхода к инжинирингу, а не на том, как это все работает у нас.

Несомненно, легче реализовываться как Product Engineer в компаниях с плоской структурой, которых сейчас становится все больше. Тем не менее применять продукто-ориентированный подход можно и в других, более консервативных структурах. Данная концепция взаимовыгодна и для вас, как инженера, и для product owner.

Какие преимущества получает Product Engineer

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

Как это работает на практике, наш инженер Артур Терменжи описывал в статье «Что такое Implementation Plan, или Как планировать реализацию при разработке». Хочу еще раз подчеркнуть, что Product Engineer — это не должность, как, например, Product Manager. Это роль, это подход к разработке. Должности наших инженеров звучат как Full-Stack или Front-еnd Engineer, и при этом они развиваются как Product Engineers.

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

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

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

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

Ценность Product Engineer в том, что он предлагает продуктовые решения. Инженер владеет инструментарием — алгоритмами и технологиями — и с его помощью реализует функционал. Понимание того, как функционал позволит решить проблемы пользователя, — это та самая added value, которую предлагает Product Engineer.

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

Product Engineer: навыки и качества

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

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

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

Применение здесь и сейчас

Универсальной формулы успеха не существует. Product engineering — лишь одно из направлений, в которых может двигаться инженер.

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

  • Посмотрите на то, над чем вы работаете, под несколько иным углом. Успех продукта зависит от решения пользовательских проблем (помимо кода, в продукте множество других важных составляющих).
  • Стремитесь создавать то, что нужно продукту, а не только то, что хочет Product Owner. Исследуйте, анализируйте и думайте о долгосрочной перспективе.
  • Помните о том, что продукты создаются командами, а не частными лицами. Выстраивайте коммуникацию.
  • И забудьте выражение «это не моя работа». Можете что-то улучшить? Делайте. Коммуницируйте. Обсуждайте идеи. И неважно, кто вы — менеджер или начинающий инженер. Вы можете генерировать отличные идеи, которые могут сэкономить месяцы ненужной работы.

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

Похожие статьи:
В выпуске: введение в ASP.NET Core 2.0, решение сложности в CQRS, валидация команд, Rider будет поддерживать F#, про распределенные системы...
Стартап Choice QR, що розвиває рішення для HoReCa, провів новий Seed раунд та залучив €1,5 млн від п’яти європейських фондів. Choice...
Привет, меня зовут Андрей Товстоног, я DevOps-инженер в команде GMEM компании Genesis. Данная статья поможет выполнить...
В выпуске: учимся репортить баги в Apple, ускоряем сборку проекта и почему каждая строчка кода на самом деле...
Знайомтесь — Тарас, Пані Анонім та Олег (всі імена змінено). Вони — невелика ініціативна група, яка...
Яндекс.Метрика