Да кто вообще такой этот продуктовый разработчик?
Сегодня в названиях вакансий всё чаще появляются приставки «продуктовый» — дизайнер, аналитик, разработчик… Компании, придерживающиеся продуктового подхода, ожидают от кандидатов определённого образа мышления, хороших технических скиллов бывает недостаточно. Меня зовут Михаил Мазеин, я тот самый продуктовый разработчик в ManyChat, занимаюсь бекэндом и участвую в процессе найма. Давайте расскажу, как это выглядит изнутри.
Помните известную байку про двух программистов-одногруппников? Один из них был троечником, второй — заядлым отличником. Троечник сделал небольшой прототип, за несколько месяцев открыл компанию, вышел на рынок. А отличник работал над очень продуманной и красивой архитектурой. В итоге через два года у троечника была компания и ниша на рынке, а отличник пришёл к нему на собеседование. История ироничная, но под капотом лежит довольно много правдивых фактов.
@innubis
Продуктовая разработка и MVP
Для начала давайте обсудим, чем продуктовая разработка отличается от проектной. Приведу пример — у проектной разработки путь такой же, как при ремонте квартиры: заказали дизайн-проект, пришли рабочие, реализовали всё по нему — готово. Схема рабочая и стара как мир. Но продукт — меняющаяся и живая сущность: в квартире вам могут разонравиться обои, потом нужно будет переделать гостиную под комнату для детей, вы заведёте кота и так далее. Поэтому подход «сначала делаем немного, потом смотрим, что с этим будет на рынке, затем доделываем» выгоднее экономически: меньше time to market, больше шанс не делать полгода работу, которая никому не будет нужна. Работа над продуктом — это бесконечный процесс, когда вы его улучшаете через небольшие итерации при помощи небольших проектов.
Создавая продукт мы чаще всего работаем по принципу проверки гипотезы на прототипе (MVP), который отдаём реальным юзерам. MVP — это минимально рабочий продукт, который даёт возможность продакту что-то протестировать, а разработчику — реализовать функционал минимальным количеством ресурсов, чтобы не аффектить архитектуру (ладно, не аффектить архитектуру слишком сильно). Это на тот случай, если гипотеза не оправдает ожиданий, и код будет выпилен, чтобы не поддерживать. Да, хоронить проекты никто не любит, но MVP тут как раз и помогает — сократить боль от невыполненных проектов. То есть прототип электромобиля — это не шасси или самокат с габаритной моделью, а «Запорожец» на аккумуляторе. Кондиционер и прочее повесим после.
Кажется, что продуктового разработчика (ПР) совершенно не заботит, какого качества код он пишет и что вообще делает, главное выпускать огромное количество фичей. Почти так, но не совсем. Работая над продуктом, нам важно достичь нужного результата минимальными средствами, через простые и надёжные решения, не усложняя систему. На мой взгляд, самый правильный подход — не пытаться на стадии разработки MVP закладывать слишком много архитектуры, так как, даже если гипотеза выстрелит и вы начнете развивать функционал и кодовую базу в дальнейшем, то, скорее всего, придут тысячи, десятки или сотни тысяч клиентов, которые в итоге будут пользоваться разработанной фичей совсем не так, как вы изначально закладывали, потому что они придут со своими уникальными проблемами и хотелками. Поэтому на ранних этапах очень тяжело предугадать вектор непосредственного развития вашего кода. И если пытаться закладывать архитектуру на ранних этапах и потом надстраивать что-то новое по изменяющимся требованиям, то мы просто будем стрелять себе в ногу. Правильно сделаем потом, когда заработает. Да, переделаем. Да, стоит заложить время на рефакторинг переписыванием с нуля. Но из 10 фич в бизнесе выстреливает одна-две. А это значит, что проще потратить на каждую меньше времени, чем сэкономить потом на этих одной-двух за счёт overengineering на раннем этапе.
Баланс между техникой и продуктом
Итак, я разговариваю на эльфийском, постоянно сыплю какими-то непонятными гипотезами, метриками и идеями, не давая спокойно пилить код. Хуже, я регулярно мешаю работать, прося что-то перестать делать, а что-то вообще выкинуть из прода. То есть веду себя как типичный продакт — какой-то опасный гиперобщительный чувак, попивающий смузи. При этом я же разработчик.
Опасная пересоциализация в образе ПР — это оттого, что идёт постоянное общение: с пользователями, коллегами, представителями бизнеса. Но нам необязательно это делать в таком же активном режиме, как это делают продакт-менеджеры, устраивая созвоны. Можно почитать тикеты в саппорте, посмотреть форум, ознакомиться с feature requests, попросить аналитика прислать какие-нибудь исследования — главное, это попытаться понять, какие именно проблемы решают при помощи вашего продукта другие люди и какие у них есть потребности.
Продуктовый разработчик находится посередине между программистом и продакт-менеджером, соединяя в себе лучшее от двух ролей, он озабочен технологиями и пользовательским опытом в равной мере. Ему нужно понимать продукт настолько, чтобы с технической точки зрения помогать продактам достигать целей и предлагать варианты, как проверить гипотезу минимальными средствами. Например, вместо того, чтобы делать сложную валидацию формы сбора номеров телефонов, можно начать с простой валидации длины и символов в номере, постепенно улучшая по фидбеку пользователей и добавляя дополнительные этапы валидации, включая определение страны и региона через внешние библиотеки/апи, добавляя в следующих итерациях определение оператора, обслуживающего номер телефона.
Не бойтесь быстрых экспериментов для проверки реакции. Сутки на фичу — и вот уже люди пишут, что и как нужно. А вы понимаете, как вашу архитектуру и вашу кодовую базу нужно будет поменять для того, чтобы в дальнейшем это было проще расширяемо и поддерживаемо. Так что ПР — это своего рода учёный, который через цепочку опытов открывает что-то новое.
Что мерить, если не длину кода
ПР ориентируется на продукт в глазах пользователя. Чем больше ценности у продукта — тем лучше работает ПР. Если говорить конкретно о ManyChat, то продуктовый разработчик — это человек, который начинает думать не только о том, как писать код, но и о том, какую ценность его код несёт.
Каждый раз, когда ты пишешь какую-то строчку кода, ты принимаешь решение о том, как твой пользователь воспользуется этим функционалом, который ты только что написал. И поэтому стоит думать в этот момент о том, будет такой кейс или не будет такого кейса, если будет, то сколько людей из сотен тысяч им воспользуются, стоит ли один пользователь из миллиона поддержки этого функционала в будущем и так далее.
Когда у нас продакт-менеджер приносит фичу, продуктовый разработчик вполне может почелленджить его на предмет, действительно ли эту гипотезу нужно делать. И когда они оба находят точки синхронизации, то это идёт в реализацию. После этого, когда видно, как заработал продукт, все вместе смотрят на фидбек и проблемы и находят решения.
Функция разработчика меняется с обеспечительной в духе «Напишите нам тут ещё кода» на стратегическую. То есть решения начинают приниматься там, где быстрее их реализовать. Чтобы стать ПР, на самом деле достаточно болеть за свой продукт или компанию и разбираться в деньгах. Полезно будет изучить, как бизнес монетизирует создаваемую ценность в софте, разобраться в ключевых метриках: что для вашего продукта и бизнеса важно (MAU, DAU, другие показатели), как эти метрики влияют, на чём сейчас фокусируется бизнес для того, чтобы стать успешнее. Стоит следить за трендами рынка, где позиционируется бизнес, погружаться в бизнес-контекст, но при этом не забывать о технической составляющей. Моя задача, как продуктового разработчика, объяснять бизнесу, как всё работает и находить компромисс, в том числе, чтобы закладывать время на архитектурные улучшения и поддержку, чтобы не копить техдолг.
Для разработчика в момент, когда он перестаёт решать какие-то конкретные узкие задачи, и начинает мыслить категориями бизнеса, — профессиональный и, наверное, в том числе, материальный рост. Не стоит забывать, что бизнес платит не за количество строк, а за решение проблем пользователей. А пользователи платят за это бизнесу.
С чего начать
Если желания самостоятельно выходить из зоны «я пишу код по задаче, и всё хорошо» нет — то не надо, кому-то важнее уровень определённости и ближе проектная разработка. Если человек не вылезает за пределы спеки и не спрашивает, как лучше писать фичу, — скорее всего, не в его характере мыслить «за ту сторону». А тем, кому хочется расширить кругозор и быстро видеть результат работы, я могу посоветовать следующее:
- Разобраться с продуктом, пользователями и ценностью. Что является вашим продуктом, кто конечный пользователь, что является ценностью, которую пользователь получает.
- Стоит начать задавать вопросы по поводу того, куда движется компания: на какой стадии развития компания находится сейчас, миссия, видение, стратегия, планы на ближайший квартал, год, возможно, три–пять лет. Понятно, что это всё не всегда есть, либо оно размыто, но попробовать составить картину для себя стоит. Начните думать о том, как вы идёте к своей цели, какой у вас road map.
- Разобраться в процессах. Какую функцию берёт на себя разработчик, какую функцию берёт на себя ваша команда, что находится вне зоны ответственности вашей команды и почему.
- Разобраться в метриках успеха для вас, когда вы что-то делаете, что для вашего менеджмента или для тех, кто ставит вам цели, будет успехом вашей работы. И самое главное, научиться оценивать свой результат. И если что-то пошло не так, проводить ретроспективу и разбираться, что привело к успеху или что к успеху не привело.
- С перспектив. Стоит договориться с руководителем, что вы потратите часть времени не на код, а на анализ рынка и продукта, что будете участвовать в дополнительных инициативах.
- Начать брать ответственность и выходить с идеями: будущий ПР на планировании активно участвует, а не молчит и кивает. Предлагает пути реализации с учетом понимания продукта и ресурсов. Когда разработчик лезет в бизнес — это не странно, а очень хорошо, потому что часто можно сделать очень многое довольно просто. Вообще, появление роли ПР, как правило, неизбежно, начиная с определённого объёма компании. Нужен кто-то, кто будет делать такие вещи. Часто это делает частично кто-то из разработчиков вместе с продакт-менеджером. По крайней мере, по опыту других коллег из Долины, каждый так или иначе берёт на себя часть разработки в роли своего рода владельца фичи, то есть как раз продуктового разработчика.
А дальше самое страшное — взять ответственность за результат, а не только за тот процесс, в котором вы работаете.
Почитать
Эрик Рис — «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели»
Экономичный стартап — это целый подход, который позволяет разрабатывать действительно нужные для пользователя продукты. Из названия может сложиться впечатление, что подход применим только к стартапам. Но сам автор утверждает, что это нет так: стартап для него — это любой проект, даже если он реализуется внутри крупной компании. На примерах историй различных бизнесов книга рассказывает о важности быстрого тестирования гипотез на реальных пользователях, сборе обратной связи, её анализе и последующих корректировках. В этой книге автор определяет такие понятия, как MVP, гипотеза роста, гипотеза ценности, прыжок веры и многое другое.
Cindy Alvarez — «Lean Customer Development»
Если вы уже готовы пообщаться с пользователями и провести свой первый CustDev, но не знаете, с чего стоит начать, это книга может вам помочь. Здесь вы легко сможете найти информацию о том, как правильно выбирать пользователей для интервью, как правильно проводить интервью, чтобы найти настоящую боль пользователя, почему полезно показать даже минимально жизнеспособный макет, чтобы получить первый фидбек и проверить свою гипотезу.
Richard Banfield, Martin Eriksson, Nate Walkingshaw — «Product Leadership»
В этой книге представлены интервью с ведущими менеджерами по продукту со всего мира, в которых они делятся подходами, стилями, идеями и методами успешного управления продуктовой командой и разработки продуктов. В этой книге можно найти ответы на вопросы:
- Какие лучшие подходы для руководства продуктовой командой в зависимости от стадии развития компании?
- Что отличаются успешные лидеры продуктовых команд и сильные продуктовые команды?
- Какие существуют способы работы с клиентами, агенствами и партнерами?
Майк Кон — «Пользовательские истории. Гибкая разработка программного обеспечения»
В этой книге подробно описан процесс подготовки требований к разработке на основании исследования пользователей продукта и выявления пользовательских историй — коротких и понятных кейсов, которые принесут ценность для конечного юзера продукта. Если вы решите прочитать книгу, то найдете практические методы сбора историй; как действовать в тех ситуациях, когда нет возможности непосредственно пообщаться с пользователями; объяснения, что делает истории хорошими или плохими и многое другое, что поможет эффективно применять данный подход для постановки задач и планирования.
