Комментарии 16
Мне кажется, что вы попутали управлением проектом с непосредственно разработкой.
Отдельные задачи дизайнера, аналитика или разработчика минимально отличаются в проектной и продуктовой разработке.
Различается последовательность их выполнения, а вот она уже от типа разработки зависит.
Отдельные задачи дизайнера, аналитика или разработчика минимально отличаются в проектной и продуктовой разработке.
Различается последовательность их выполнения, а вот она уже от типа разработки зависит.
Отдельные задачи, действительно, мало чем отличаются: дизайнер — рисует макеты, разработчик — пишет код, аналитик — работает с данными. На мой взгляд, основное отличие между продуктовой и проектной разработкой заключается в подходе к этим задачам. Насколько участник команды разработки (не зависимо от специализации) широко смотрит на любую реализуемую им фичу, понимает и принимает участие в проработке не только своей отдельной задачи (по основной специализации), но и вовлечен в общий процесс. Участвуя и помогая на всех этапах разработки. Например на этапе проработки макетов — помогая дизайнеру в проработке UX. Прокачивая T-shaped скилы, становясь более ценным для разрабатываемого продукта специалистом. Понятное дело, что целью не является стать профессионалом в абсолютно всех направлениях и специализациях. Но понимание и навыки в смежных областях помогают решать более глобальные вопросы и задачи, чем написание кода по четкому ТЗ
Этот вопрос большое связан с размером команды и обязанностями(ролью) конкретного сотрудника, а не с подходом к разработке (проект vs. продукт).
На мой взгляд, существуют только две роли, результат работы которых очень сильно зависит от используемого подхода. Это сам менеджер проекта (владелец продукта) и архитектор. Первый определяет приоритеты выполнения задач (что в большей степени и определяет выбор подхода), ну а архитектор вынужден учитывать возможные смены приоритетов и требуемую последовательность реализации функционала.
На мой взгляд, существуют только две роли, результат работы которых очень сильно зависит от используемого подхода. Это сам менеджер проекта (владелец продукта) и архитектор. Первый определяет приоритеты выполнения задач (что в большей степени и определяет выбор подхода), ну а архитектор вынужден учитывать возможные смены приоритетов и требуемую последовательность реализации функционала.
Как мне кажется, основная разница между проектной и продуктовой разработкой отличается степенью неопределенности конечного результата. Обычно проектная разработка идет по ТЗ и есть достаточно полное понимание того, что мы хотим получить в итоге. Продуктовая же разработка, по большей части, построена на тестировании большого количества гипотез, которые могут не выстрелить, или в ходе экспериментов кардинально поменять свою суть, так как создается что-то новое, и важно понимать отклик рынка. На мой взгляд, роль архитектора перестает быть актуальной, в тот момент, когда продукт становится большим и сложным, когда тестируется большое количество гипотез, когда над ним работают хотя бы больше 3 команд. Да, можно иметь человека, который будет заниматьс продумыванием высокоуровневой архитектуры продукта, но он не будет погружен в детали реализации каждой фичи. И в этой ситуации принятие тех или иных продуктовых и архитектурно-технических решений уходит в зону ответственности команд. А для того, чтобы принимать эти самые решения, как раз таки и нужен этот самый T-shape и выход за рамки своей основной специализации (непосредственное написание кода).
Задачи по архитектуре есть всегда, даже когда для этого нет отдельной должности. Просто они могут быть неявно размазаны между исходными требованиями и самими разработчиками.
Конечно, задачи связанные с архитектурой есть всегда. В предыдущем комментарии я говорил о непосредственно роли архитектора, сконцентрированной на конкретном человеке. В нашей компании, каждый разработчик в продуктовой команде является архитектором той фичи, которую разрабатывает его команда. А для этого уже требуется более широкий взгляд на продукт и соответствующие скилы.
Вот из-за этого у вас и получается домик как на второй картинке ;-)
Чаще всего, домик на второй картинке получается если пытаться заложить железобетонную архитектура в самом начале, и пытаться вписать в ее рамки, быстро меняющееся реалии. Наш подход — идти маленькими итерациями, не пытаясь в самом начале архитектурно заложить всё и вся, так как архитектура меняется и развивается итеративно, исходя из полученного от рынка фидбека.
Это уже зависит не от подхода, а от квалификации архитектора, насколько он может учитывать особенности подхода к разработке (то, о чем я и писал пару комментариев выше). Но это уже совсем другая история…
Хм, такое ощущение, что домики просто надо конвертировать в микросервисы и расположить в одном парке (соединить через брокер сообщений).
Забавно, что лет N назад ровно так же утверждали проектные менеджеры, противопоставляя себя продуктовым: у них-де определённый продукт с занятой нишей и определённым функционалом, а у нас — полная неизвестность и неопределённость, но чтобы ей управлять мы определим сроки и бюджет на эксперименты.
Если открыть PMBoK (книгу по проектному управлению) — то именно это вы там и увидите.
Так что, имхо, это просто попытка набить себе цену/снизить цену рекрутеру на противопоставлении текущего замшелого подхода и свежего прогрессивного, существенные отличия отсутствуют.
Если открыть PMBoK (книгу по проектному управлению) — то именно это вы там и увидите.
Так что, имхо, это просто попытка набить себе цену/снизить цену рекрутеру на противопоставлении текущего замшелого подхода и свежего прогрессивного, существенные отличия отсутствуют.
Мне кажется не совсем корректно противопоставлять один подход другому — каждый из них хорошо работает в своем конкретном случае. Может быть несколько путей развития как профессионала, например глубокая узкая специализация, или тот путь, который описан в данном посте. Кому-то ближе одно, кому-то другое, «правильного» пути, на мой взгляд, не существует.
Более того, даже отличия между этими путями не существует. И там, и там Т-развитие, управление рисками, и прочее, и прочее. Беглое гугление про отличие подходов говорит про ограниченность проекта во времени, но в нынешних реалиях это уже не так (проекты продолжаются из года в год). Говорят про кэш флоу, но это не проблема разработки, да и в продуктах за ним следить надо.
Может, вы назовёте какие-то явные отличия проектного подхода от продуктового подхода в современных реалиях? Описанные у вас отличия скорее про байки ужаса проектного подхода, который кому-то из продактов удалось продать.
Может, вы назовёте какие-то явные отличия проектного подхода от продуктового подхода в современных реалиях? Описанные у вас отличия скорее про байки ужаса проектного подхода, который кому-то из продактов удалось продать.
Достаточно часто встречаю подход (из общения с другими людьми, и самому тоже доводилось работать в подобных командах), когда каждый сосредоточен на решении своего участка работы, без попытки вникнуть в то, какая именно задача (в широком смысле этого слова) и для кого решается. Условно говоря, кто-то придумал решение, мы взяли и реализовали, для кого, зачем и почему — не наша проблема. Не сомневаюсь, что и при проектном подходе, бывает иначе. Но на моем опыте, и опыте тех людей с кем доводилось общаться, довольно часто получается так, что разработчики пилят код (и делают это хорошо), но без глубокого понимания для кого и зачем. Я рад, что у вас есть другой опыт в этом плане :)
По своему опыту скажу, что с человеком, который погружен в продукт, гораздо проще коммуницировать; легче доносить хотелки и предложения по улучшению. Идеально, когда разработчик полностью погружены в проект, а не работает по принципу «моя хата с краю». Типа сделала что-то бесполезное, получил за свой бесполезный труд деньги и ОК…
К списку книг можно еще добавить:
" Сильнейшие. Бизнес по правилам Netflix", автор: Патти МакКорд
К списку книг можно еще добавить:
" Сильнейшие. Бизнес по правилам Netflix", автор: Патти МакКорд
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Да кто вообще такой этот продуктовый разработчик?