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

Но есть и компании, которые освоили концепцию продуктового разработчика. Такой человек сфокусирован не только на закрытии задач по ТЗ, а еще стремится донести дополнительную пользу и глубоко погрузиться в бизнес. Где-то говорят про T-shaped специалиста, где-то уже — про M-shaped. Мы решили разобраться в этой роли с точки зрения более-менее прикладного контекста через опыт людей, в чьих командах такие специалисты либо уже есть, либо внедряются. Дополнительным поводом стал общий тренд: бизнес хочет от разработки больше эффективности, а значит, роль продуктового разработчика становится все актуальнее.

Разговор об этом мы вели на круглом столе с представителями компаний с очень разной культурой: Антоном Сулаевым, руководителем направления Darkstore в Magnit OMNI; Антоном Бевзюком, инженерным менеджером в Mindbox; Глебом Лесниковым, Head of Architecture Dodo Brands; и Тимуром Хахалевым, консультантом по AI-трансформации разработки. У всех экспертов разный бэкграунд, но, как выяснилось по ходу разговора, весьма близкое понимание предмета обсуждения.

Кого вообще можно назвать продуктовым разработчиком

«Продуктовый разработчик — это разработчик, который не пишет код, а решает задачу клиента. Что бы он ни делал, он всегда держит в голове: а для чего я это делаю? Для какого клиента, какая у него проблема, и как то, что я делаю, помогает эту проблему решить. И это реально на подкорке. Даже если он делает, казалось бы, чисто техническую задачу — переезжает из одного хранилища в другое, масштабирует какой-то сервис, — он всё равно понимает, зачем это нужно клиенту, какую клиентскую проблему, текущую или будущую, он решает»

— Антон Бевзюк, инженерный менеджер Mindbox

Как иллюстрацию такого восприятия можно привести историю из Mindbox. Однажды продакт пришел с задачей встроить в продукт SMS-чат — компания выходит на американский рынок, а там это привычный канал взаимодействия с пользователем. Задачу оценили на месяц-два разработки. Но вместо того чтобы просто взять ее в работу, разработчик копнул контекст и выяснил, что продакту на самом деле нужна из этой фичи ровно одна функция: американское законодательство требует, чтобы при получении SMS-рассылки можно было от неё отписаться, отправив в ответ слово «стоп», и это должно происходить автоматически. Продакт в тот же вечер за час собрал это решение сам, на no-code вебхуках, без всякой разработки, экономя тем самым месяц работы.

Готовность не соглашаться с постановкой задачи «как есть» — пожалуй, ядро продуктовости. В индустрии для этого даже есть термин X-Y problem: когда к разработчику приходят с готовым решением, хотя нужно докапываться до реальной проблемы за ней, после чего, возможно, решать совсем другую задачу. Но одной дотошности мало — нужен еще язык, на котором можно этот вопрос задать, и умение услышать ответ от людей с разным бэкграундом. И вот это уже по-своему особый навык для разработчика. По сути, речь идет об умении посмотреть на систему глазами того, для кого она делается. 

«Продуктовый разработчик — это тот, кому интересно погружаться в продукт, понимать проблему клиента, поставить себя на его место, зайти в интерфейс и оглянуться вокруг его глазами»

— Тимур Хахалев, AI Coding эксперт

Стоит немного поизучать чужие интерфейсы, и вы заметите, что почти всегда найдется кнопка, глядя на которую, думаешь: «Кому вообще в голову пришло вставить ее сюда?!». За такими решениями могут, конечно, скрываться какие-то замысловатые А/Б-тесты, но чаще они появляются из-за того, что кто-то в команде продукта не задумался лишний раз о потребности реального пользователя. 

Свести продуктовость к конкретному чек-листу навыков не выходит. Это скорее характеристика человека — сумма софт-скиллов и технического опыта, который позволяет выстраивать аргументацию. В основе — предрасположенность: человеку не все равно, что он делает. Но и одной предрасположенности недостаточно, ее достраивает опыт. Разработчик уже был в ситуациях вида «принял решение, которое вылилось в техдолг» или «не отстоял, что фичу не надо делать, и ее потом выкинули на помойку». И такой опыт превращает неравнодушие в зрелую позицию, при которой условный тимлид готов доверить разработчику самостоятельный диалог с продактом, зная, что тот почелленджит его при необходимости.

«Продуктовость — не роль и не специальность: нельзя быть сегодня бэкендером, завтра фронтендером, а послезавтра продуктовым разработчиком»

— Антон Сулаев, руководитель направления Darkstore в Magnit OMNI

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

Из этого вытекает практический вопрос — можно ли считать продуктовым джуна с минимальной технической базой? Здесь важно развести то, что человек думает о себе, и то, что ему готовы доверить: джун может искренне считать себя продуктовым, но тимлид не оставит его один на один с продактом на серьезной фиче. Ведь нет ещё доверия ни к его техническим решениям, ни к способности отличить реальную бизнес-проблему от симптома. Поэтому сначала растим доверие и закрываем техническую базу. А смежные продуктовые компетенции появляются уже позже, когда база закрыта.

Как выглядит рабочий день без аналитиков

Работать вообще без бизнес- и системных аналитиков — не такая уж редкость, как может показаться. Есть доска, на которой карточки заводит продакт (а иногда и любой другой член команды), в карточке описана не техническая реализация, а мотивация — какая проблема стоит перед бизнесом и для кого она важна. Дальше эту карточку берет в работу разработчик. Он проводит этап груминга, на котором докапывается до деталей, и если ему не хватает контекста, он сам идет к продакту прояснять и дописывать этот контекст, а затем раскладывает задачу на шаги и решения. Рутинную часть груминга сейчас во многом облегчает ИИ, но творческая часть все равно на разработчике.

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

«Для по-настоящему живого продукта, который непрерывно улучшается, а не делается один раз по заказу, дискавери — это чаще не про то, что нужно сделать (это обычно и так понятно), а про то, что делать не нужно прямо сейчас»

— Глеб Лесников, Head of Architecture, Dodo Brands

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

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

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

— Глеб Лесников, Head of Architecture, Dodo Brands

Есть вариант институционализации роли продуктового разработчика — практика Mission Lead. Ее применяют, например, в Mindbox. Там у сеньорных разработчиков есть возможность взять на себя ответственность за короткую бизнес-цель, которую можно выполнить небольшой командой из трех-четырех человек за месяц-два. То есть цель бизнесовая, но отвечает за нее разработчик. 

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

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

— Антон Бевзюк, инженерный менеджер Mindbox

Дальше — больше. Бывает, что ответственность за фичу выходит не только за пределы какой-то роли, а за пределы одной команды. В Magnit OMNI такую конфигурацию называют Feature Lead. По сути то же самое, что и Mission Lead, но выходящий за границу своей команды. Он решает не только техническую, но и координационную задачу, договариваясь с другими командами. Такой выход за границы своего кусочка системы тоже отлично стимулирует продуктовость и позволяет разработчику увидеть чуть более целостную картину.

Продуктовый разработчик как коммуникатор

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

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

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

«Domain Driven Design — популярный подход к созданию цифровых продуктов, и он как раз про то, что не продактов надо погружать в технику, а разработчиков нужно приучать и говорить, и мыслить, и код писать, и тесты писать на языке бизнеса. И тогда всем будет проще»

— Антон Бевзюк, инженерный менеджер Mindbox

Ключевое слово здесь — «приучать»: само по себе умение объяснить сложное решение простым, но именно бизнесовым языком не появляется само. Это в некотором роде искусство, если хотите. Чаще всего разработчикам сложно дается объяснение, например, почему предложенное продактом решение нельзя реализовать так, как он хочет, или почему рефакторинг вообще необходим.

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

Где предел продуктовости

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

Предположим, у нас есть продукт — сервис, который переводит деньги удаленным сотрудникам в разных странах: у каждой юрисдикции своя регламентация, свой набор документов, свой расчёт НДС. Здесь цена самостоятельной интерпретации слишком высока, потому что вопрос не в удобстве пользователя, а в деньгах и законе. И тут уже есть серьезные риски. Поэтому нужен доменный эксперт (например, юрист) в команде. 

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

Растить продуктового разработчика внутри команды или нанимать с рынка?

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

«Если ты сможешь еще больше ценности приносить компании и сможешь закрывать сторону продукта, то и денег ещё больше будешь получать. Вполне рабочая схема, и у меня в опыте так и было»

— Тимур Хахалев, AI Coding эксперт

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

Поэтому основной путь — растить продуктовость внутри, причем растить осознанно выбранных людей, а не всех подряд. Через постепенное расширение доверия и, соответственно, зоны влияния: чем раньше разработчика подключают к дискавери, тем быстрее он начинает ощущать свое влияние на продукт, а значит быстрее становится продуктовым. 

Но не каждая инвестиция здесь приносит дивиденды. В случаях, когда рост объективно не происходит, можно услышать меткое определение «вечный мидл». И это не какое-то клеймо или показатель некондиции. Просто человек спокойно делает свои задачи, выполняет работу качественно, но лишнего на себя не берет. И поэтому солировать в каких-то крупных задачах он — ясное дело — не будет. 

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

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

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

Как ИИ и агенты меняют роль продуктового разработчика

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

«Если мы взяли и сделали через ИИ работу продакта на основе данных и пошли с этим в продакшен — так, наверное, не стоит делать. Стоит сначала оценить риски: что будет, если мы это делаем. И либо уточняем у специалиста, либо, если риски не сильно высокие, пробуем».

— Тимур Хахалев, AI Coding эксперт

Есть кейс — история одного из разработчиков Mindbox, который с помощью ИИ сделал рефакторинг легаси-сервиса (5000 строк кода превратились в 1500). Код при этом он почти не читал построчно. Зато очень много времени потратил на описание и обсуждение спецификации с ИИ. По сути, он выступал в роли продакта: объяснял, что надо сделать, и убеждался, что нейронка его правильно поняла и с точки зрения задачи клиента, и с точки зрения технического решения. Отсюда вывод:

«Чем лучше ты проблему опишешь в самом начале, тем лучше и ИИ код напишет. Так что мне кажется, с использованием этого инструмента навык продуктовой разработки, наоборот, выходит на первый план, потому что писать код уже не проблема. Проблема — задачу поставить грамотно»

— Антон Бевзюк, инженерный менеджер Mindbox

Но есть и встречное наблюдение. Для разработчиков, которые и раньше умели проектировать системы, ИИ не столько добавляет продуктовости, сколько кратно удешевляет то, что раньше было дорого и медленно: переписать гигантский монолит, сменить библиотеку логирования или базу данных, например.  

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

Тем, кому и раньше доверяли крупные вещи, теперь доверяют делать ещё больше, потому что эти люди теперь просто успевают больше. А тех, кому не доверяли, приходится ревьюить еще тщательнее.

«Расслоение, по сути, увеличивается, потому что больше можно сделать. Раньше код был узким местом, сейчас узкое место — код-ревью»

— Антон Сулаев, руководитель направления Darkstore в Magnit OMNI

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

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

Что сделать в понедельник, чтобы стать чуть продуктовее

Вместо заключения зафиксируем несколько практик, которые помогут копнуть в сторону продуктивности прямо завтра, если хотите.

«Самый простой первый шаг — задать вопрос коллегам, которые отвечают за продукт: а что мы вообще делаем? Кому это нужно? И пообщаться на этот счёт».

— Тимур Хахалев, AI Coding эксперт

Более системная версия того же принципа — превратить вопрос «зачем» в привычку и изменить сам формат постановки задач: не «сделать X», а «есть проблема Y». Главное — начинать с проблемы, а не с того, что надо сделать. А что надо сделать — это уже детали внизу.

«Я делаю задачу — зачем? Могу я построить цепочку: какому человеку она облегчит жизнь и как именно? Если можешь, значит, у тебя есть продуктовое мышление»

— Антон Бевзюк, инженерный менеджер Mindbox

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

«Почитать, посмотреть видео на Ютубе, спросить у ChatGPT, что такое DDD, и как он может мне помочь. И да, DDD надо воспринимать в том числе как концепт — как дух закона, а не как букву. Классы никто не обязывает вас записывать. В общем, хорошо хотя бы знать концепцию»

— Глеб Лесников, Head of Architecture, Dodo Brands

И, наконец, самая неожиданная рекомендация — не начинать с себя вовсе, а сперва честно оценить, в какой среде находишься.

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

— Антон Сулаев, руководитель направления Darkstore в Magnit OMNI