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