Python conf in Kharkiv, Nov 16 with Intel, Elastic engineering leaders. Prices go up 21.10

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. Исследуйте, анализируйте и думайте о долгосрочной перспективе.
  • Помните о том, что продукты создаются командами, а не частными лицами. Выстраивайте коммуникацию.
  • И забудьте выражение «это не моя работа». Можете что-то улучшить? Делайте. Коммуницируйте. Обсуждайте идеи. И неважно, кто вы — менеджер или начинающий инженер. Вы можете генерировать отличные идеи, которые могут сэкономить месяцы ненужной работы.

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

LinkedIn

10 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

А зачем Product Engineer’у работодатель?

В некоторых случаях он ему и вправду не нужен. Много примеров когда люди с таким мышлением стартовали успешные продукты.

Product Engineer — это не должность, как, например, Product Manager. Должности наших инженеров звучат как Full-Stack или Front-еnd Engineer

Изумительная манипуляция менеджеров. Product Manager это должность, а Product Engineer — это подход. Яркий пример творчества гуманитариев без технического бекграунда. Если уже говорить в терминах инжиниринга, то есть две четкие специализации — Business Engineer, которые отвечает за то, что бизнес процессы выстроены максимально эффективно с учетом возможностей доступных технологий и людей, и Software Engineer, который отвечает за то, что реализованы наиболее эффективные алгоритмы обработки данных на каждом уровне обработки информации. При этом в обоих случаях эффективность измеряется в деньгах, а более конкретно считаются LTV и ROI. При этом каждая специализации требует своего набора технических знаний, хотя управление проектами и софт скилы одинаковы. Суть в том, что большинство менеджеров не разбираются в технологиях от слова совсем, поэтому и рождаются вот такие шедевры )))

Яркий пример творчества гуманитариев без технического бекграунда.

Яркий пример формирования выводов без предварительного анализа. Я программирую с 14 лет сейчас мне 36.

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

а более конкретно считаются LTV

Емм... а причем здесь Life Time Value метрика к оценки эффективности программиста? Не ну можно конечно попытаться найти корреляцию, но в продуктах обычно еще множество других факторов. Например у CRM систем обычно высокий LTV, так как с них сложно переезжать на конкурентные продуты а вот у обычного iOS/Android app LTV $0.99-$2.99 — человек раз заплатил и больше никогда не принесет бизнесу ни цента. И как мы понимаем от инженерной работы эти метрики вообще не зависят.

Хорошего дня.

Спасибо за статью! Я называл это как уровень зрелости и ответсвенности, как уровень «сеньерити», как «не быть просто кодером» — а теперь буду подкован теоретически.
Могу сказать от себя что работать с разработчиками кто придерживатся такого подхода — одно удовольствие, жаль что это скорее «редкая птица».

Дякую за статтю. Раніше не перетинався з концепцією Product Engineer. Насправді звучить як ідеальний консультант, що не тільки програмує, але й цікавиться результатом своєї роботи та впливом цього результату на користувача.
Вивчення результатів пошук «consultant vs product engineer» наводить на думку, що це досить схожі ролі/моделі мислення. Проте ці ролі існують в проекті та в продуті.

Який, на думку автора статті, є аналог ролі «product engineer» в типових T&M/fixed price проектах?

Привет, Саш
Ко мне можно обращаться Сергей, мне так будет комфортнее. ;)
>

«consultant vs product engineer» наводить на думку, що це досить схожі ролі/моделі мислення

Так и есть, мы только оперируем термином «consultancy» описывая не отдельную роль а в целом модель бизнеса. Вот тут статья dou.ua/...​mns/software-consultancy

Який, на думку автора статті, є аналог ролі «product engineer» в типових T&M/fixed price проектах?

Тут абсолютно не имеет значение какой тип проекта, product engineer это не роль а способ мышления.

Сергію, все так :-) Особливо популярно в Європі мати команду з консультантів. Варто тільки приймати до уваги розмір проектів. На великих проектах 20+ людей потрібна чітка спеціалізація. А який у вас розмір команд (орієнтовно)?

У нас есть как маленькие проекты на 2 человека так и на 25+ людей. Концепция product engineer не противоречит специализациям.

Инженер здорового человека

Подписаться на комментарии