Обратитесь к инженерам по продуктам

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

Недавно я прочитал несколько статей о «10x Developers», и все, что я прочитал, было очень познавательным; в любом случае, то, что я читал, в основном взято из инженерного POV — они часто говорят о младшем и старшем, инструментах, удалении кода, компетенциях и т. д. — все это важные моменты, но я хотел бы дать немного другой ракурс.

Инженер по продукту

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

Инженеров по продукту (отныне PE) легко узнать в процессе собеседования, позже мы обсудим некоторые общие черты.

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

Скорее всего, во время собеседования вы оценили, хорошо ли кто-то использует Scala, если это язык программирования вашей компании, или знает ли он Kafka, Redisи Cassandra если вы их используете; оказывается, что очень часто вы нанимаете кого-то, у кого есть навыки, необходимые технологической команде. Поздравляю, вы, скорее всего, наняли в свою команду отличного инженера-программиста, но, возможно, стоило бы проверить, есть ли у него черты PE.

Так что же такое PE? Речь идет не о младших или старших должностях, и это не имеет ничего общего с технологиями: все дело в разработке продукта и владении им. Настоящий PE понимает, что его основное внимание должно быть сосредоточено на улучшении продукта, поэтому он сосредоточится на предметной области, пытаясь понять динамику, процессы и основные концепции.

Доставить ценность!

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

PE на самом деле не будет заботиться о переходе с одной технологии на другую, если за этим не стоит ценность для бизнеса.

PE не мыслят изолированно, им нужна полная картина, чтобы понять, что можно улучшить. Они пойдут и поговорят со всеми остальными подразделениями компании: от маркетинга до службы поддержки клиентов, чтобы собрать полную информацию о продукте (да, они будут это делать, даже если они работают в DDD с ограниченными контекстами).

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

PE любят принцип Парето:

Задавать много вопросов

Представьте себе такую ​​запись в бэклоге, помеченную как технический долг:

«Сократить время выполнения функции X на треть за счет индексации K»

Это важно? Является ли это «настоящим» техническим долгом? Любой инженер, скорее всего, скажет вам, что это важно исправить, потому что мы, инженеры, помешаны на улучшениях, рефакторинге и т. д.

Инженер по продукту, скорее всего, попытается понять, обеспечивает ли это ценность
«Оказывает ли это сокращение времени положительное влияние на кого-либо из заинтересованных сторон?»
«Улучшит ли это жизнь наших клиентов, сократив время их ожидания?» «Существенно ли это снизит стоимость платформы?»

Если оптимизация чисто техническая, то это минимальный приоритет

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

«Является ли это изменение стимулом?»
«Если мы перейдем к этому шаблону, сможем ли мы быстрее приспособиться к другим бизнес-требованиям?»

Мои 2 цента: 2 строки кода

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

if (text.trim().length() <= 2) 
    text = ""

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

Я работал в туристическом онлайн-агентстве (OTA), и в команде мы занимались этапом оформления билетов на рейс. Однажды я организовал звонок команде обслуживания клиентов, пытаясь понять их болевые точки, и начальник отдела обслуживания клиентов подготовил слайд со всеми проблемами, с которыми они столкнулись: одна из записей была «заказы вручную».

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

«Напишите здесь любой особый запрос о вашем рейсе».

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

Сразу после встречи я подошел к своему ноутбуку, добавил 2 строчки кода, ввел пару тестов для проверки и запустил в производство. Месяц спустя меня пригласили на руководящую встречу, где я был награжден за то, что эффективно решил огромную проблему компании, сэкономив много денег и обеспечив лучшее качество обслуживания клиентов.
Да, эти 2 строки делали следующее:

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

Это не моя проблема, это чья-то проблема

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

Проблема компании существовала в течение нескольких месяцев, и никто не решил ее.

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

«нажмите здесь, если у вас есть особые требования к рейсу»

Если установить флажок, появится текстовое поле.

Разница между областями и границами

Вышеупомянутый пример устанавливает пространство для различия между областями и границами.

Находится ли решение проблемы за пределами чисто инженерной сферы? Да нет сомнений.

Является ли «правильное» решение приемлемым с точки зрения компании?
Лично я так не думаю. Ждать еще несколько месяцев, пока UX решит эту проблему, стоило бы дорого со всех точек зрения, но с точки зрения инженеров, одному человеку потребовалось 30 минут, чтобы исправить это. Границы человека намного больше, чем объем роли, в которой он участвует, не имеет значения, занимается ли он разработкой программного обеспечения, данными или тестированием, или разработкой платформы. Это образ мышления, при котором вы всегда сосредотачиваетесь на своем продукте и своих клиентах, а не на технологии и масштабах. Эта концепция действительна для каждой функции в компании, а не только для технологии.

10 инженеров

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

Я встречал замечательных инженеров, некоторые из них были превосходны в техническом отношении и были намного более способными, чем любой PE, но ни один из них никогда не был близок к тому, чтобы приносить такую ​​же пользу, как PE.

Я думаю, что PE — инженеры в 10 раз больше.

Должны ли мы действительно прекратить нанимать инженеров-программистов?

Это зависит: все должно быть контекстуализировано.

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

Во многих реальностях эти инженеры-программисты работают либо в пространстве платформы, либо в «опыте разработки», выполняя чисто техническую работу, пытаясь улучшить жизнь разработчиков.

Как мы изменили наш процесс собеседования

Найти PE очень сложно, поэтому не стоит уменьшать начальную воронку.

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

  • Мы не запрашиваем каких-либо конкретных технических знаний (никаких Spring Boot, DynamoDB, Redis и т. д., хотя мы и работаем с этим стеком).
  • Мы принимаем разработчиков с любого языка программирования, даже если наша кодовая база написана на Kotlin (мы проводим тест по кодированию, прося человека решить его на его любимом языке программирования)
  • Мы оцениваем общие навыки решения проблем
  • Ищем черты человека, неравнодушного к продукту, задающего вопросы вне технологического пространства

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