что такое продуктовая разработка
Продуктовая разработка. О чём не рассказывают на собеседованиях
Авторизуйтесь
Продуктовая разработка. О чём не рассказывают на собеседованиях
архитектор CS-Cart
Вместо предисловия
Часто слышу от начинающих разработчиков про муки выбора компании-работодателя: продуктовая компания vs аутсорс-компания, занимающаяся заказной разработкой. Конечно, каждый случай уникален; всё зависит от того, чего вы ожидаете и хотите от своей работы, какими качествами и скиллами обладаете.
Для начала пару слов о том, что такое продуктовая разработка
Продуктовая разработка — разработка продукта, ориентированного на определенную целевую аудиторию. Продуктом может быть всё, что можно продать: сайт, приложение, услуга.
Этапы разработки нового продукта:
идея → разработка → альфа/бета → продукт
Этапы разработки в существующем продукте (на примере CS-Cart):
бизнес-требование → прототип → демки/фидбек → фича
Что рассказывают на собеседованиях в продуктовых компаниях
Если вы придёте на собеседование в продуктовую компанию или загуглите «преимущества работы в продуктовой компании», то, скорее всего, услышите / прочитаете это:
Из всего этого может сложиться ощущение, что продуктовая разработка — это только кодинг и внедрение. Но это не так.
Я не буду сравнивать особенности работы в разных типах компаний, поделюсь своим опытом работы в продуктовой компании.
Продуктовая разработка = развитие клиента (customer development), а не развитие продукта
Этот подход к построению бизнеса был разработан американским предпринимателем и учёным Стивом Бланком на основе его опыта с десятками стартапов и компаний. Суть подхода: важнейший актив компании — это клиенты, а не продукт; продукт должен решать проблемы покупателей и заключать в себе ценность.
В рамках этого подхода есть 4 важных этапа:
Таким образом, продуктовая разработка находится где-то на стыке поиска, подтверждения и создания.
Продуктовая разработка = работа внутри команды
Всех сотрудников объединяет общая цель — совершенствование продукта, не получится работать изолированно. Если мы говорим не про стартап, то как правило, в продуктовых компаниях команда самоорганизована: обладает компетенциями, принимает решения, анализирует задачи и выдвигает гипотезы, разрабатывает и тестирует решения. В команде идёт непрерывный обмен знаниями и компетенциями, развитие и обучение каждого сотрудника.
Продуктовая разработка = аналитика и гипотезы
Данный пункт вытекает из 2-х предыдущих. Чтобы повысить ценность продукта, команде нужно активизировать весь ресурс сотрудников для выявления проблем, потребностей клиентов и генерации идей.
Мы много общаемся и в процессе диалогов пытаемся ответить на важные вопросы. Например:
Продуктовая разработка = прототипы и фидбек
Чтобы понять насколько наши идеи жизнеспособны и будут ли они востребованы среди клиентов, нужно делать прототипы. Чтобы проверить гипотезу перед выкаткой фичи в продукт, мы используем MVP (minimum viable product) — «минимальный рабочий продукт». Он даёт пример решения задачи клиента, но не покрывает крайние случаи. Основная задача MVP — получение обратной связи для оценки и принятия решения. Нужно быть готовым к тому, что ряд прототипов по результатам собранного фидбека придётся выкинуть и полностью переработать. Это нормальный процесс.
Продуктовая разработка = обязательства
При этом обязательства возникают сразу по нескольким направлениям:
Продуктовая разработка = стандарты индустрии
Знать ответы на эти вопросы и следовать индустриальным стандартам — значит сохранять актуальность в комьюнити разработчиков.
Продуктовая разработка = ответственность
Разработчик возлагает на себя ответственность за успех или провал продукта. Продуктом уже пользуются, поэтому появление багов в нём гораздо критичнее, чем косяки в коде проекта, ещё не выпущенного в продакшн.
Продуктовый подход — польза и для бизнеса, и для разработчика
Я продуктовый разработчик, но так было не всегда. Лет 5 назад я впервые услышал фразу «продуктовая разработка», но я тогда не совсем понимал, что это значит. Мне говорят — вот у нас продукт, ну а я пишу код и пишу, чего такого-то. Есть ТЗ — и славно, нет ТЗ — как говорится, и результат будет ХЗ
Но это на самом деле своего рода проектный подход. Вот есть у вас ТЗ, а за ним — много тяжелой, усердной работы. Люди упорно гребут, в голове у них только код. Потом проект закончился, все молодцы.
Потом что-то поменялось в моей работе — ТЗ не стало. Это такой следующий шажок. Вот мы в продукте работаем, а теперь у нас еще и ТЗ нет. И что делать? Началось осознание того, что происходит.
Во-первых, продукт не имеет четкого начала и конца. Нет каких-то границ. Вот в проекте у нас были границы. Например, количество функций, которые нужно сделать, количество разработчиков, которые работают над проектом, дедлайны всякие, когда проект должен закончиться. У продукта же таких границ нет, он живёт, и его надо развивать.
Приходит к нам бизнес и говорит — давайте экономить. Конкретно на SMS и на платежной форме. Мы соглашаемся. У нас так вышло, что в тот момент наша команда знала продукт лучше, чем владелец продукта, так бывает. Мы знали особенные кейсы, мы знали, что мы где-то лишних SMS немного тратим. А значит, примерно знали, где можно что поделать.
Так что мы взяли спринт на анализ, и за этот спринт мы не написали ни строчки кода. Вообще.
Зато мы много общались, много обсуждали, брейнштормили, накидывали гипотезы, оценивали их, предлагали, что можно сделать. Мы находили сценарии, где отправляются лишние смски, прикидывали, сколько этих SMS лишних мы отправляем. Мы же знаем стоимость одной SMS и, соответственно, знаем, сколько мы можем сэкономить. И по каждому сценарию примерно прикидывали, сколько будет стоить всё это сделать.
Затем мы из этих задач выстроили роадмап. В начало поставили такие низковисящие фрукты, которые легко сделать и которые дают явный эффект. А в конец — задачки посложнее, у одних из них эффект был послабее, а у других — более заметный.
Примеры задач
Например, вот задачка совсем простая. Есть пользователи, которые в настройках поставили галочку «логиниться только по паролю». А мы им зачем-то предлагаем логиниться по SMS. И они зачем-то эти SMS отправляют. Потом они вводят SMS, а потом они еще вводят пароль, хотя SMS можно было не вводить вообще. И пофиксить этот сценарий — это просто, что мы первым делом и сделали.
А вот посложнее задачка — перевести все SMS на пуши. Задачка достаточно грандиозная, у нас до сих пор идут работы, чтобы зафиналить этот перевод, потому что там много рефакторингов было, и мы написали много новых микросервисов и новые хранилки.
Вот мы написали роадмап, декомпозировали его, прикинули, составили план для каждой задачки, стали делать. Планомерно каждый спринт делали какую-то задачку, которая часть SMS срубала. И смотрели в реалтайме прямо на график, как меняется количество SMS. Мы видели, что продукт экономит. Прямо на глазах. Экономит — значит зарабатывает. Вот я смотрю на график и понимаю, что мы окупились в этот же спринт. Это очень круто по бизнес-эффекту. И понимаю, что мы как команда полезные. Мы окупаемся.
И еще на будущее вперед. Это же долгоиграющая штука, мы же теперь каждый месяц экономим много-много SMS. Меня лично это ощутимо мотивирует. И я очень рад осознавать, что я полезный.
Плюсы подхода
У этого подхода (когда разработчика пускают на ранний этап) есть несколько плюсов и для бизнеса, и для самих разработчиков.
Я начну с плюса для бизнеса. Разработчик может предложить решение по принципу Парето. То есть за 20% времени можно сделать 80% бизнес-эффекта, и бизнесу это в большинстве случаев ОК. Можно на раннем этапе привлечь разработчика и ограничить какое-то количество функциональности, чтобы сделать ни больше и ни меньше.
Разработчик, допустим, такой вот грамотный парень, бизнес-ориентированный, который понимает, зачем, что, как внутри рефакторить, он может предложить такой рефакторинг, который откроет портал в инженерный рай и оттуда начнут сыпаться фичи. Сами.
То есть не просто там кодить какие-то технически упоротые вещи, а именно сделать рефакторинг ради бизнеса. Ну мы так открыли портал в инженерный рай и оттуда насыпалось на форму оплаты несколько новых фич. Среди них — новый способ оплаты, да еще и пару багов пофиксили одним рефакторингом.
А ещё разработчик может на раннем этапе оценить стоимость разработки задачи. Понятно, что если это какая-то нереальная вещь, у нее сомнительный бизнес-эффект, ее можно дальше не прорабатывать и не собирать для нее какие-то бизнес-требования, а просто отложить и пойти дальше, что-то более приоритетное взять.
Разработчик, у которого есть знание доменной области и знание SQL, может посчитать количество SMS, которые отправляются в месяц по какому-то сценарию. И исходя из этого количества SMS можно понять, сколько денег эта задача принесет. То есть бизнес-эффект тоже можно оценивать с помощью разработчика. Причём для этого не нужен какой-то отдельный аналитик. Понятно, что разработчик это сделает с какой-то погрешностью, но все-таки это возможно.
Обычно у фронтендеров такой майндсет и такая насмотренность, что они могут набросать макет. А если этот человек в офисе, то он может этот макет людям показывать и проводить коридорное тестирование. Тоже плюс.
Самый главный пункт, на мой взгляд, это когда мы в команде задачу сами придумали, когда мы ее сами декомпозировали, предоценили, потом мы ее взяли делать, потом мы ее довели до продакшена и еще собрали постоценку (в идеале). Тут есть ощущение, что вот это моя фича, это наша задача, она становится частичкой нас. И отсюда большая мотивация, чтобы задачу протащить через все этапы, чтобы везде ее сопроводить, и в конце концов понять — была ли твоя работа полезной.
Отсюда следует первый плюс для разработчика — это дополнительная мотивация. Как я и сказал, когда я задачу прорабатываю, я с ней сближаюсь и хочу ее делать. И другие задачи я тоже хочу делать. Это работает сильнее, чем зарплаты и прочее. Вот просто хотеть делать задачи, чтобы чувствовать себя полезным.
Следующее — это прокачка скиллов. И хард-скиллы типа SQL, и софт-скиллы. Некоторым разработчикам сложно выйти из команды, чтобы пойти куда-то там наружу с другой командой договариваться. И вот это очень хороший толчок к развитию этого навыка.
Отдельным пунктом я вынес прокачку бизнес-мышления. Это очень важный навык для продуктового разработчика и не только. В принципе, если вы хотите основать стартап или занять ведущую роль в стартапе или в Big Tech компании, то понимать бизнес, понимать, как это работает на всех этапах, это прямо обязательно. И продуктовая разработка такого плана, когда ты задачу сам придумываешь и сам предоцениваешь, она заметно способствует тому, чтобы прокачаться в бизнес-мышлении.
Следующий пункт — нетворкинг. Когда человек идет из команды с кем-то общаться — с инфобезопасниками, с юристами, еще кем-то внешним — он приходит к людям, знакомится с ними. И в следующий раз, когда он к ним приходит, они знают, зачем он пришел и что ему надо, и многие вопросы решаются гораздо легче.
Ещё один пункт, я уже говорил про мотивацию, но есть еще мотивация другая. Когда приносишь больше пользы продукту, можно рассчитывать на взаимность. Когда есть реальный измеримый в деньгах эффект от твоей работы, можно рассчитывать и на какой-то быстрый хороший карьерный рост, на какую-то хорошую зарплату, и вот эта внутренняя мотивация — это тоже такое вознаграждение.
И последний пункт. Просто нравится. Попробуйте, может, вам тоже понравится.
Но есть нюансы
Мы в команде начинаем с того, что придумываем, а заканчиваем тем, что выкатываем в прод. А это же новые зоны ответственности, мы их раньше не брали на себя, и надо сделать это более качественно.И я тут не только про отсутствие багов, а больше про качественную предоценку и подготовку задач. У нас для того, чтобы сделать качественно, есть инструменты.
По сути, это чеклисты. Я рекомендую эти инструменты, даже если у вас не скрам, не аджайл, если вы вот это все ненавидите. Инструменты скрамовские, но вы можете их применять, даже если у вас вотерфолл — они просто помогут. Это не какие-то ограничители, это шпаргалки.
Вот есть шпаргалка для проработки задачи. Definition of Ready for sprint. Этот чеклист мы писали сами.
Это шпаргалка, но это не барьер. Мы можем на него посмотреть и подумать, что по задачке можно еще поделать предварительно, чтобы ее успеть в спринте. Но если владелец продукта говорит — надо, мы соглашаемся, мы ее возьмем, но мы ни на что не коммитимся.
То есть с большой вероятностью там вскроется какая-то неизвестность в спринте, которая нас затормозит, и мы что-то не сможем. Увы, такое бывает. Но не барьер, это важно.
А вот Definition of done — это барьер. Что такое Definition of done?
Бывает же, что программист говорит: — Я сделал.
А у него спрашивают: — Что ты сделал?
Отвечает: — Я код написал.
Если программист говорит, что он написал код, это даже не всегда значит, что он его отладил. Но для бизнеса нет никакой ценности от написанного кода. Просто написанного кода. Потому что нужно еще отладить, поревьювить, поправить после ревью, оттестировать, вывести в продакшен, обвесить мониторингом и собрать постоценку. Это в идеале.
DoD — чеклист, который позволяет договориться, когда говорить “Сделано” по задаче. Про DoD я сказал, что это барьер. Почему барьер? Потому что мы договорились с бизнесом, что мы продукт поддерживаем вот на таком уровне качества, не ниже. Этот чеклист — он про фиксацию уровня качества. Не Definition of Done команды, не Definition of Done компонента, а Definition of Done всего продукта.
И если мы что-то по Definition of Done, не успели за спринт сделать — печальная ситуация, но бывает. То мы берем эту несделанную работу и кладем ее в бэклог. И продакту нужно понимать, что есть некоторая несделанная работа, техдолг. Что ее придется потом когда-то сделать. А если ее не делать, она нас в будущем затормозит.
Мы все делаем сами. И чеклисты мы сами составляли, и процессы мы можем сами двигать как-то, если видим потребности, мы сами прорабатываем задачу, мы сами катим ее в продакшн, мы сами собираем постоценку.
Через это мы получаем некоторые профиты. Пять лет назад я не особо задумывался, пишу код и пишу. Это когда ты приходишь, в 9 утра начинаешь писать код, в 6 вечера можешь закончить и уйти домой.
Потом что-то менялось, и в какой-то момент пришло осознание — то как мы работаем, то зачем мы на работу приходим, оно очень сильно влияет на качество нашей жизни в целом.
На ментальное здоровье, на физическое здоровье, на отношение с близкими. Мы на работе проводим 80% времени. И очень важно то, как мы на работе кайфуем.
Я вам очень советую задуматься о ваших рабочих процессах и попробовать взять на себя больше ответственности по задачам. Вы можете попросить об этом своих тимлидов и менеджеров. А если вы сами тимлиды, то вы можете эту ответственность ребятам дать.
Если вам интересен взгляд на продуктовую разработку изнутри — подписывайтесь на мой TG-канал «Product Developer».
Да кто вообще такой этот продуктовый разработчик?
Сегодня в названиях вакансий всё чаще появляются приставки «продуктовый» — дизайнер, аналитик, разработчик… Компании, придерживающиеся продуктового подхода, ожидают от кандидатов определённого образа мышления, хороших технических скиллов бывает недостаточно. Меня зовут Михаил Мазеин, я тот самый продуктовый разработчик в ManyChat, занимаюсь бекэндом и участвую в процессе найма. Давайте расскажу, как это выглядит изнутри.
Помните известную байку про двух программистов-одногруппников? Один из них был троечником, второй — заядлым отличником. Троечник сделал небольшой прототип, за несколько месяцев открыл компанию, вышел на рынок. А отличник работал над очень продуманной и красивой архитектурой. В итоге через два года у троечника была компания и ниша на рынке, а отличник пришёл к нему на собеседование. История ироничная, но под капотом лежит довольно много правдивых фактов.
@innubis
Продуктовая разработка и MVP
Для начала давайте обсудим, чем продуктовая разработка отличается от проектной. Приведу пример — у проектной разработки путь такой же, как при ремонте квартиры: заказали дизайн-проект, пришли рабочие, реализовали всё по нему — готово. Схема рабочая и стара как мир. Но продукт — меняющаяся и живая сущность: в квартире вам могут разонравиться обои, потом нужно будет переделать гостиную под комнату для детей, вы заведёте кота и так далее. Поэтому подход «сначала делаем немного, потом смотрим, что с этим будет на рынке, затем доделываем» выгоднее экономически: меньше time to market, больше шанс не делать полгода работу, которая никому не будет нужна. Работа над продуктом – это бесконечный процесс, когда вы его улучшаете через небольшие итерации при помощи небольших проектов.
Создавая продукт мы чаще всего работаем по принципу проверки гипотезы на прототипе (MVP), который отдаём реальным юзерам. MVP — это минимально рабочий продукт, который даёт возможность продакту что-то протестировать, а разработчику — реализовать функционал минимальным количеством ресурсов, чтобы не аффектить архитектуру (ладно, не аффектить архитектуру слишком сильно). Это на тот случай, если гипотеза не оправдает ожиданий, и код будет выпилен, чтобы не поддерживать. Да, хоронить проекты никто не любит, но MVP тут как раз и помогает — сократить боль от невыполненных проектов. То есть прототип электромобиля — это не шасси или самокат с габаритной моделью, а «Запорожец» на аккумуляторе. Кондиционер и прочее повесим после.
Баланс между техникой и продуктом
Итак, я разговариваю на эльфийском, постоянно сыплю какими-то непонятными гипотезами, метриками и идеями, не давая спокойно пилить код. Хуже, я регулярно мешаю работать, прося что-то перестать делать, а что-то вообще выкинуть из прода. То есть веду себя как типичный продакт — какой-то опасный гиперобщительный чувак, попивающий смузи. При этом я же разработчик.
Опасная пересоциализация в образе ПР — это оттого, что идёт постоянное общение: с пользователями, коллегами, представителями бизнеса. Но нам необязательно это делать в таком же активном режиме, как это делают продакт-менеджеры, устраивая созвоны. Можно почитать тикеты в саппорте, посмотреть форум, ознакомиться с feature requests, попросить аналитика прислать какие-нибудь исследования — главное, это попытаться понять, какие именно проблемы решают при помощи вашего продукта другие люди и какие у них есть потребности.
Продуктовый разработчик находится посередине между программистом и продакт-менеджером, соединяя в себе лучшее от двух ролей, он озабочен технологиями и пользовательским опытом в равной мере. Ему нужно понимать продукт настолько, чтобы с технической точки зрения помогать продактам достигать целей и предлагать варианты, как проверить гипотезу минимальными средствами. Например, вместо того, чтобы делать сложную валидацию формы сбора номеров телефонов, можно начать с простой валидации длины и символов в номере, постепенно улучшая по фидбеку пользователей и добавляя дополнительные этапы валидации, включая определение страны и региона через внешние библиотеки/апи, добавляя в следующих итерациях определение оператора, обслуживающего номер телефона.
Не бойтесь быстрых экспериментов для проверки реакции. Сутки на фичу — и вот уже люди пишут, что и как нужно. А вы понимаете, как вашу архитектуру и вашу кодовую базу нужно будет поменять для того, чтобы в дальнейшем это было проще расширяемо и поддерживаемо. Так что ПР — это своего рода учёный, который через цепочку опытов открывает что-то новое.
Что мерить, если не длину кода
ПР ориентируется на продукт в глазах пользователя. Чем больше ценности у продукта — тем лучше работает ПР. Если говорить конкретно о ManyChat, то продуктовый разработчик — это человек, который начинает думать не только о том, как писать код, но и о том, какую ценность его код несёт.
Каждый раз, когда ты пишешь какую-то строчку кода, ты принимаешь решение о том, как твой пользователь воспользуется этим функционалом, который ты только что написал. И поэтому стоит думать в этот момент о том, будет такой кейс или не будет такого кейса, если будет, то сколько людей из сотен тысяч им воспользуются, стоит ли один пользователь из миллиона поддержки этого функционала в будущем и так далее.
Когда у нас продакт-менеджер приносит фичу, продуктовый разработчик вполне может почелленджить его на предмет, действительно ли эту гипотезу нужно делать. И когда они оба находят точки синхронизации, то это идёт в реализацию. После этого, когда видно, как заработал продукт, все вместе смотрят на фидбек и проблемы и находят решения.
Функция разработчика меняется с обеспечительной в духе «Напишите нам тут ещё кода» на стратегическую. То есть решения начинают приниматься там, где быстрее их реализовать. Чтобы стать ПР, на самом деле достаточно болеть за свой продукт или компанию и разбираться в деньгах. Полезно будет изучить, как бизнес монетизирует создаваемую ценность в софте, разобраться в ключевых метриках: что для вашего продукта и бизнеса важно (MAU, DAU, другие показатели), как эти метрики влияют, на чём сейчас фокусируется бизнес для того, чтобы стать успешнее. Стоит следить за трендами рынка, где позиционируется бизнес, погружаться в бизнес-контекст, но при этом не забывать о технической составляющей. Моя задача, как продуктового разработчика, объяснять бизнесу, как всё работает и находить компромисс, в том числе, чтобы закладывать время на архитектурные улучшения и поддержку, чтобы не копить техдолг.
Для разработчика в момент, когда он перестаёт решать какие-то конкретные узкие задачи, и начинает мыслить категориями бизнеса, — профессиональный и, наверное, в том числе, материальный рост. Не стоит забывать, что бизнес платит не за количество строк, а за решение проблем пользователей. А пользователи платят за это бизнесу.
С чего начать
Если желания самостоятельно выходить из зоны «я пишу код по задаче, и всё хорошо» нет — то не надо, кому-то важнее уровень определённости и ближе проектная разработка. Если человек не вылезает за пределы спеки и не спрашивает, как лучше писать фичу, — скорее всего, не в его характере мыслить «за ту сторону». А тем, кому хочется расширить кругозор и быстро видеть результат работы, я могу посоветовать следующее:
Почитать
Эрик Рис — «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели»
Экономичный стартап — это целый подход, который позволяет разрабатывать действительно нужные для пользователя продукты. Из названия может сложиться впечатление, что подход применим только к стартапам. Но сам автор утверждает, что это нет так: стартап для него — это любой проект, даже если он реализуется внутри крупной компании. На примерах историй различных бизнесов книга рассказывает о важности быстрого тестирования гипотез на реальных пользователях, сборе обратной связи, её анализе и последующих корректировках. В этой книге автор определяет такие понятия, как MVP, гипотеза роста, гипотеза ценности, прыжок веры и многое другое.
Cindy Alvarez — «Lean Customer Development»
Если вы уже готовы пообщаться с пользователями и провести свой первый CustDev, но не знаете, с чего стоит начать, это книга может вам помочь. Здесь вы легко сможете найти информацию о том, как правильно выбирать пользователей для интервью, как правильно проводить интервью, чтобы найти настоящую боль пользователя, почему полезно показать даже минимально жизнеспособный макет, чтобы получить первый фидбек и проверить свою гипотезу.
Майк Кон — «Пользовательские истории. Гибкая разработка программного обеспечения»
В этой книге подробно описан процесс подготовки требований к разработке на основании исследования пользователей продукта и выявления пользовательских историй — коротких и понятных кейсов, которые принесут ценность для конечного юзера продукта. Если вы решите прочитать книгу, то найдете практические методы сбора историй; как действовать в тех ситуациях, когда нет возможности непосредственно пообщаться с пользователями; объяснения, что делает истории хорошими или плохими и многое другое, что поможет эффективно применять данный подход для постановки задач и планирования.