Итак, вы разработчик. Грызете гранит, положим, Java, осваиваете очередной фреймворк, учитесь управлять Kubernetes, а иногда даже читаете про консистенцию данных в ACID. Но вот незадача: крутые компании хотят не только ваших знаний. Им нужны продуктовые разработчики. Но кто это вообще такие? Где заканчивается разработчик обычный и начинается продуктовый? Или они вообще существуют отдельно друг от друга и пересекаются только в фантазиях нанимателей? Попробуем ответить на эти вопросы, составить портрет продуктового разработчика и разобраться, как же им стать.
Привет, я Андрей Степанов, технический директор fuse8. Мы строим свою экспертизу на создании цифровых продуктов для бизнеса и делимся наработками через контент. В этом материале я хочу поделиться личными наблюдениями и размышлениями о том, почему компании так хотят продуктовых разработчиков, и что люди вообще вкладывают в это понятие. Помимо этого расскажу о нескольких практиках, которые помогут «настроить» в себе продуктовые качества и понять, как разрабатывать сервисы качественнее.
Вообще само понятие «продуктовый разработчик» довольно обтекаемо. По сравнению, например, с продуктовыми менеджерами, продуктовые разработчики скорее не наименование позиции, а надстройка восприятия компетенций сотрудника, которую каждый может понимать и описывать по-разному. Предлагаю сделать шаг в сторону унификации этого понятия и разложить по полочкам компетенции и подходы, характерные для продуктового разработчика.
Дано
У нас есть два героя: разработчики Тоня и Мартин. Оба талантливые, оба знают, как устроены фреймворки, как работает PostgreSQL и даже разбираются в таких нюансах, как вариации консистенции данных по ACID. Но их подходы к задачам кардинально различаются.
Тоня: продуктовый разработчик. Будет нашим эталоном.
Мартин: классный технарь.
I суперспособность: понимание продукта
Задача: сделать выгрузку отчетов данных в Excel.
Что делает Мартин
Мартин быстро генерирует файл с колонками и цифрами. Файл есть, данные правильные. Но в отчете отсутствуют форматирование и пояснения к данным.
Такого вида таблица выходит у Мартина. Технически не подкопаться: все выгружено, данные верны. Но черт ногу сломит в этих данных ввиду отсутствия контекста и вспомогательных расчетов. Нет, это не значит что Мартин не справился с задачей. Напротив – он все сделал четко как просили. Но можно было лучше.
Как действует Тоня
Она спрашивает: «Для чего нужен этот отчёт? Как его используют?». Оказывается, это бухгалтеры хотят видеть цифры и сверять их с 1С. Тоня добавляет формулы и базовое форматирование: итоговые суммы выделяются, данные фильтруются по датам, рассчитывается стоимость единицы товара. Итог: отчёт становится понятным и удобным, а бухгалтеры экономят время.
Форматирование – минимальное. Настроить выгрузку на это форматирование – прописать пару строчек. Зато как круто на выходе.
Как Мартину стать как Тоня
Тоня, прежде чем приступить к задаче, сформировала User Story.
Это фиксация требований, при которой мы не просто берем задачу в работу как есть, а добавляем ей дополнительного смысла. Здесь самое сложное ответить на вопрос «Зачем?». Важно не путать пользу с возможностью и не получать утверждение вида «Хочу загружать пользователей, чтобы пользователи загружались». Нужно копать до конечной потребности пользователей.
Нам нужно представлять продукт с точки зрения пользователей и бизнеса. Отсюда можем рассуждать и ставить под сомнение предложенные решения, если что-то оказывается непонятным или несвязным.
А еще неплохо участвовать в прояснении требований к продукту. Да, звучит странно. У нас ведь есть продакт/аналитик/дизайнер для этого. Однако на деле реальное устройство продукта могут знать только разработчики. Ценность этого знания высока на начальном этапе работы над функцией: разработчик может подсказать неочевидные связи, более простое техническое решение, чтобы не тратить много времени всей команды.
Полезные практики + что почитать
- Соберите полезную документацию по проекту. Чтобы онбордить новичков в команду, нужна медленно устаревающая информация, например:
- общий бизнес-контекст продукта: как он зарабатывает или экономит нам деньги, как он встраивается в контекст компании;
- портреты пользователей: кто пользуется продуктом, какую боль этих людей решает продукт;
- ключевые сценарии использования: тут пригодятся user story mapping или customer journey map — оба формата довольно наглядные и могут дополнять друг друга.
- Если вы сами разработчик, который только пришел в команду — не бросайтесь сразу пилить таски. Изучите документацию, пользователей и реализованную функциональность.
- Поймите ключевые метрики продукта: бизнес оценивает результаты деятельности по определенным показателям, и стоит узнать у продакта, какие они сейчас, и чего нужно добиться. Если есть возможность – покопайтесь в дашбордах, где их отслеживают.
- Jobs to be done — альтернативный, немного более глубокий подход для понимания ценности продукта, вместо более простого user story. В нем мы представляем, что пользователи, как бы «нанимают» ваш продукт на определенную «работу». Для старта лучше всего почитать гайд у Ивана Замесина
- Догфудинг – самостоятельно пользоваться разрабатываемым продуктом, если это возможно. Легко это делать, если ты пишешь интернет-банк, в который тебе приходит зарплата, сложнее – если систему управления электростанцией. Но стоит пробовать проходить отдельные сценарии, как реальный пользователь (не с тестовыми данными). Например, если заполнить десяток-другой заявок на обслуживание нашей электростанции, часто можно обнаружить пару хороших мест для улучшений в процессе.
-
Алан Купер, «Психбольница в руках пациентов» — довольно старая, но актуальная книга об интерфейсах цифровых продуктов. С момента выхода книги многое в мире стало лучше, но мы все еще сталкиваемся с ужасно неудобными интерфейсами. Книга научит базовым принципам, по которым программы должны общаться с людьми, чтобы вы смогли выявлять и предлагать хорошие решения.
II суперспособность: коммуникация с не-технарями
Кросскомандное взаимодействие – одна из составляющих процесса создания цифровых продуктов. Часто разработчикам приходится общаться не только между собой, но и с другими членами команды, которые не так подкованы технически и могут просто не понимать «программистский» язык. И эта коммуникация может быть очень разной.
Как общается Мартин
Возникает потребность что-то изменить или добавить в функциональности. Мартин на такой запрос отвечает: «А может вы там как-нибудь без меня разберетесь?». Когда становится понятно, что не разберутся, Мартин просит скинуть ТЗ и обещает глянуть его, как освободится время. Спустя пару часов получаем от Мартина письмо примерно следующего содержания:
Мартин может и постараться что-то пофиксить в системе. Опять же, на основе собственного анализа в условиях нехватки необходимых данных. Однако, не разобравшись в том, как выглядит проблема на самом деле, есть риск сделать бесполезные фиксы.
Как общается Тоня
Ее подход в том, чтобы поучаствовать в прояснении требований и проектировании. Поэтому она может появиться на встречах с бизнес-заказчиками и поговорить с ними лично, а не через посредников. После этого она свяжется с дизайнерами и аналитиками, чтобы вместе спроектировать необходимые фичи, заключив в них необходимую пользу.
Стремясь говорить с коллегами на одном языке, Тоня анализирует ту же проблему, что и Мартин. Она тоже пишет письмо с результатами своей работы. Но подача в нем уже совсем другая:
Как Мартину стать как Тоня
Разница в подаче может быть не самой существенной, но пользы от нее при этом значительно больше. Где-то более тщательно структурированная мысль, где-то приведены примеры, сам текст проще. Само по себе присутствие на обсуждениях работы с не-технарями раз к разу будет улучшать способность понимать их и общаться так, чтобы они понимали вас. Со временем станет понятно, как вычленять из проговариваемой информации ценное, и как запрашивать нужные данные так, чтобы никто не сконфузился и ответил на поставленный вопрос.
Полезные практики + что почитать
- Книга «Пиши, сокращай» Максима Ильяхова — вроде про написание текстов, но на самом деле про то, как выделить и донести пользу в частном случае в виде текста. Вставляет на место мозг, измученный канцеляризмом и школьными уроками русского.
- Участвовать в клиентских демо, когда разработчики сами демонстрируют реализованную функциональность из первых рук. Демо – не только для того, чтобы отчитаться о сделанном, но и чтобы команда лучше узнала бизнес, получила прямую обратную связь и возможность ее обсудить. Так дальнейшее создание продукта будет проще. Бонус для руководителей: разработчики автоматом становятся ответственнее.
- Проводить 1-2-1 с не-технарями (продактами, сейлзами, дизайнерами, саппортами): если вы пришли в проект, который создает небольшая команда, полезно поближе познакомиться с другими коллегами. Так можно узнать об их собственных взглядах на пользователей, их потребности, и продукт. Особенно это полезно это в отсутствие хорошей документации.
- Собственно работать в паре с теми же не-технарями. Может быть полезно, например, сделать набросок интерфейса вместе дизайнером, поработать над проектированием какого-то бизнес процесса вместе с аналитиком или планом выпуска фич с продактом. Совет довольно очевидный, но регулярно сталкиваюсь с командами, в которых принят многоступенчатый подход, где все работают отдельно и потом передают какие-то артефакты в следующий этап на ревью. А потом через боль все переделывают.
- Участвовать в Customer development интервью. Обычно их проводят продакт-менеджеры, и, если они делают это регулярно в вашей команде, вы можете присоединиться в качестве слушателя или ассистента и вести заметки.
- Полевое исследование или Гэмба 現場 — это когда мы идем на место, где пользователи работают с продуктом, и наблюдаем за ними, общаемся. Иногда «увидеть своими глазами» и пара часов такого времяпровождения дают больше, чем чтение кучи документов. Например, вот история, как Александр Поломодов, техдир Т-Банка, ходил на гембу и развозил карты клиентам.
- Если участие пользователей в демо и полевые исследования вам недоступны, можно проводить отдельные встречи для сбора фидбека с небольшой группой пользователей (возможно, это ваши самые лояльные клиенты или бета-тестеры), где продакты могут обсудить проблемы, а разработчики – послушать и лучше понять их.
- Еще вариант – поработать на саппорте. Например, в продуктовой команде Basecamp разработчики регулярно дежурят на саппорте. Аналог: почитать отзывы о продукте.
III суперспособность: проактивность
Под проактивностью мы понимаем способность человека самостоятельно инициировать действия и события, подходить к реализации задач творчески и брать ответственность за их выполнение.
Как проактивность проявляет Мартин
Мартин видит бардак в коде и буквально кричит о необходимости рефакторинга. С точки зрения руководителя рефакторинг – это, конечно, круто, но денег не принесет.
Мартин, разумеется, молодец, потому что думает о развитии продукта. Это с одной стороны. С другой – он предлагает продолжительную и часто непредсказуемую задачу как-то внедрить в существующий план проекта, но не учитывает контекст: сроки, приоритеты, продуктовую стратегию.
Как проактивность проявляет Тоня
Тоня тоже понимает необходимость рефакторинга, но также понимает и то, что текущим планом работы пренебречь нельзя. Поэтому она предлагает не срочно бросить все силы на рефакторинг всей системы, а анализирует приоритеты.
Как Мартину стать как Тоня
Нужно ограничиваться не только базовыми данными, а идти чуть дальше. Быть проактивным – это не просто что-то предлагать. Также это и не про борьбу за идеальный код. Нужно уметь оценить, что действительно полезно предложить в текущих условиях. Сделать это можно только при понимании приоритетов и того, как должен работать продукт.
Полезные практики + что почитать
- База проактивности: Увидел – записал. Фиксируйте все идеи, проблемы, предложения и наблюдения, которые могут сделать продукт лучше, но не являются срочными. Это могут быть как технические улучшения (рефакторинг, оптимизация производительности), так и продуктовые (улучшение UX, добавление новых функций). Можно будет вернуться к ним позже, когда появится подходящее время или ресурсы. Главное — вести такой список системно, например, в виде отдельной доски в таск-трекере, и периодически его просматривать и переоценивать.
- Ретроспективы – регулярное обсуждение с командой, что получилось хорошо, что пошло не так и какие улучшения можно внести в следующий спринт. Вовлекает разработчиков в рефлексию и проактивную позицию, они участвуют и вносят предложения. Главное тут — выбрать какие-то отдельные предложения, взять в работу и не забыть реализовать.
- Прокачивать насмотренность: мы все время пользуемся кучей цифровых продуктов, иногда они нравятся нам, иногда приносят боль – полезно отмечать такие моменты. Например, в папочке со скриншотами интересных находок. В них стоит задавать себе вопрос «Почему так сделано, а не иначе?», «Что конкретно не так?» и «Как можно было сделать лучше?» или наоборот «За счет чего так удобно?». Дополнительно, как хобби, можно устанавливать и тестить разные продукты.
- Если лень собирать примеры самому, можно подписаться на канал Ильи Бирмана, где он регулярно постит примеры такого и делает разборы интерфейсов своих студентов
IV суперспособность: планирование непонятных задач
Не всегда получается стартовать разработку, предварительно закрыв все белые пятна. То есть при реализации фич в продукте неизбежно будут возникать моменты на прояснение. Бытует мнение, что оценивать задачи с высокой степенью неопределенности стоит с большим запасом, либо перед оценкой прописывать скрупулезно ТЗ, учитывая каждую мелочь.
Как действует Мартин
Мартин человек ответственный и понимает, что просто так накидать оценки не получится – нужна детализация. Поэтому требует подробное ТЗ. И такой подход на самом деле может работать.
Однако порой слишком глубокое погружение в детали может убить продукт еще на старте. Вот ТЗ прописали, Мартин на него посмотрел и говорит: «Разработка займет три года». С Мартином спорить сложно, но вот вопрос – кому этот продукт вообще будет нужен через три года? И точно ли будет?
О том, почему перегруженное деталями ТЗ вредит продукту, и как это исправить, рассказываем в другой нашей статье.
Как действует Тоня
У Тони другая установка. Она знает, что в целом в продукте работает правило, при котором 20% усилий дают 80% результата. Она думает итерациями и понимает, что нужно выделить первую версию для самой большой группы пользователей. А дальше двигаться в сторону расширения сервиса, параллельно собирая обратную связь с пользователей.
Как Мартину стать как Тоня
Продуктовый подход здесь состоит в том, что неопределенные задачи нужно прототипировать. Например, вместо того чтобы заранее говорить «сложнааа, поэтому делать будем 300 лет», можно посоветоваться со смежной командой, чтобы получить взгляд со стороны. Это позволит разбить задачу на этапы и примерить временные и технические затраты.
Еще важно, что продуктовые компромиссы обычно лучше технических. Технические компромиссы – это, например, наделать костылей (пусть и работающих), готовясь морально к тому, что в будущем придется разбирать гигантский техдолг. Продуктовый компромисс – это когда, например, у нас есть в плане система оплаты через крипту, но мы понимаем, что реально пользоваться ею будут полтора землекопа. Поэтому просто не делаем эту функциональность. Отпадает сразу ряд задач и проблем.
Полезные практики
- Делать быстрые черновые прототипы — накидывать интерфейс в Figma или набросать неработающих компонентов в React/Vue, не стремясь к идеалу. Нет времени на такое? Нарисовать карандашом на бумаге или в Paint. Сложный интерфейс с кучей данных и графиками? Можно набросать в Гугл Таблицах. И так далее. Главное — показать идею и обсудить её с командой.
- Показывать демо незавершенных решений. Не каждую фичу можно сделать в спринт, но часто важно получать фидбек и по ходу разработки: на реальных данных могут обнаружиться необычные кейсы, которые лучше скорректировать до релиза.
- Spike: это короткая исследовательская задача. Её цель — выяснить, насколько реалистично выполнить сложную часть проекта. Вместо гадания и споров команда получает конкретный ответ: стоит ли браться за задачу сейчас или отложить. Обязательное условие — чётко ограниченное время на исследование.
Пример: Мы разрабатываем онлайн магазин, нужно добавить Apple Pay. Разработчик берёт spike на день, пробует SDK и делает прототип. Выясняется: работает только в мобильном Safari, нужен отдельный эндпойнт на бекенде. - Метод прогрессивного JPEG – cначала делаем костяк решения: от начала до конца, без идеала. Главное — дойти до рабочей версии как можно быстрее. Потом улучшаем и допиливаем. Такой подход экономит ресурсы, ускоряет проверку гипотез и быстрее приносит пользу пользователю.
Пример: Вместо полной реализации покупки в онлайн магазине команда запускает базовую версию: товар → корзина → оплата → спасибо. Пользователи уже могут заказывать, бизнес — зарабатывать. Остальные детали (разные варианты оплаты, доставки, промоакции, связь c CRM и т.д.) добавляют позже, шаг за шагом.
V суперспособность: ответственность за результат
Критерии готовности задачи могут определяться от компании к компании, от команды к команде, от разработчика к разработчику. Понятно, что здесь нельзя сделать универсального паттерна для выполнения любой задачи на каком бы то ни было проекте, но все же мы можем говорить о некой концепции результата.
Что есть результат для Мартина
Мартин долго трудился над бэкендом системы. Делал-делал и выдает: «Бэк готов!». Все протестировано, тесты зелененькие, все работает – красотища. И да, к качеству реализации вопросов нет, но «Бэк готов!» – это все-таки не совсем цельный результат. Это скорее шаг к нему, пусть и довольно существенный.
Что есть результат для Тони
Тоня выполняла ту же задачу, но для нее понятие готовности было чуть более расширенным. Она понимала важность согласования модулей системы между собой, необходимость выдачи промежуточных результатов. Поэтому цельный результат получился более комплексным.
Для Тони «готово» — это когда:
- фича интегрирована в продукт,
- проверена в связке с другими модулями,
- доступна пользователям,
- получена обратная связь.
В некоторых компаниях разработчики сами отслеживают целевой результат заливок: сколько человек стали пользоваться новым модулем, как часто они это делают, принес прибыль или нет. Это и продуктовый подход, и дополнительная галочка в резюме.
Полезные практики + что почитать
- Явно описывать Definition of Done. Перед началом работы договориться, что значит «готово»: фича протестирована, задеплоена, проверена в проде, заанонсирована. Это формирует привычку доводить до результата, а не останавливаться на этапе «код написал».
- Введение новой роли — Feature lead. Это временная роль. Как тимлид, только для одной фичи. Один разработчик берёт ответственность за выпуск всей фичи: от уточнения требований и синхронизации с командой до выката и получения обратной связи. Такая роль помогает тренировать навык видеть продукт целиком и доводить дело до конца.
- Применять подход You build it, you run it. Команда, которая разрабатывает фичу, отвечает и за её поддержку после релиза. Это значит: следить за логами, быстро реагировать на баги и инциденты, участвовать в улучшении стабильности. Такой подход усиливает чувство ответственности: ты не просто «сдал фичу», ты за неё в ответе и после продакшена. Со временем это меняет мышление — разработчик начинает проектировать так, чтобы проще было сопровождать и отлаживать.
- Тестировать самому. Есть продуктовые команды, которые работают без выделенных QA-специалистов. Например, Intercom, Basecamp, GitHub. Разработчики сами обеспечивают качество через автоматизацию, статанализ кода, мониторинг, CI/CD и код-ревью. Даже если у вас есть QA, не стоит уповать только на них – полезно провести тестирование новых фич: своих или чужих.
Темная сторона
Погоди, не многовато ли? И с бизнесом пообщайся, и фичу сделай, и сам протестируй, и баги поймай, и метрики проверь, и пользователям покажи. И всё это — на фоне дедлайнов, сложного продукта и часто небольшой команды. Можно я просто буду код писать, а вы ТЗ мне дадите?
Отвечаю: можно. Мир айти большой, и на рынке полно компаний, которым не нужен тот самый продуктовый разработчик, а нужен просто толковый прогер, глубокий технарь. Даже те продуктово-ориентированные компании, которым нужен продуктовый разработчик, обычно ожидают лишь часть из всего большого спектра ответственностей. Так что выбор есть.
Быть продуктовым разработчиком — стресс, ведь нужно держать в голове целостную картину, думать о пользователях и бизнесе, переключаться между разными видами деятельности и отвечать за ошибки.
Но награда — четкое понимание ценности своей работы, того как, продукт помогает людям. А ты – создатель продукта, а не просто исполнитель. Ну, и платят неплохо.
Подведем итоги
Качества продуктового разработчика можно развивать через выработку нескольких привычек. Для этого не нужно читать триллион статей от продуктологов или ходить на сотни конференций.
Задавайте вопрос «Зачем?». Вот прямо так: зачем эта задача? Что она решает? Иногда вы можете заметить, что задача вообще не нужна или её можно решить проще. Ну и другие вопросы тоже задавайте, если чувствуете, что они могут углубить ваше понимание. Всегда лучше спросить чем не спросить.
Разберитесь в продукте. Вы не сможете задавать правильные вопросы, если не понимаете, как работает продукт. Нужно погружаться: изучать документацию, пробовать использовать продукт, читать отзывы пользователей – иногда в них больше мудрости чем в 20 встречах с продактом. Ну и общайтесь с ребятами из команды, которые работают над разными частями функциональности.
Не ждите указаний сверху, действуйте сами. Видите, что что-то можно улучшить? Предлагайте. Нашли баг, который всех раздражает? Почините. Продуктовые разработчики постоянно ищут, что можно сделать лучше. Кажется, что такая фишка в подходе к работе вырабатывается сама, если продукт, который вы разрабатываете, действительно вам нравится.
Умейте искать компромиссы. Не всегда нужно делать идеально. Иногда достаточно «нормально» или «хорошо». И это не о том, чтобы писать код абы как, а о понимании, где можно упростить задачу, чтобы сэкономить время и ресурсы.
Общайтесь с разными сторонами процесса. Хорошая коммуникация — это умение говорить на языке собеседника. Технические детали должны быть понятны не-технарям, а бизнес-задачи — разработчикам. Продуктовые разработчики строят мосты между этими мирами, объясняя сложные вещи простым языком. Тут можно возразить, что медиатором между разработкой и бизнесом должен выступать проджект, аналитик или человек на другой роли, но даже при его наличии умение объяснить спорные моменты не будет лишним.
