Продуктовая разработка против проектной

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

Но если бы всё было так же просто, как хлебушек, то не было бы статьи. А она есть. Как еще можно отличить продукт от проекта:

b_5950df05c2fba.jpg

Ну то есть в целом понятно.

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

Когда у тебя есть краткосрочная задача запилить что-то по определенным требованиям (сайт, логотип, рекламную кампанию и т.д.) забрать деньги и отдать то, что получилось, в руки заказчика — у тебя проект. Вернее, проекты — потому что один закончился, начался второй, конвейер крутится, профиты мутятся.

Здесь и далее, чтобы не путаться, будем считать так:

  • Когда говорим о продукте, подразумеваем, что все делается внутри одной компании, все менеджеры, маркетологи, технари, дизайнеры и прочие сидят под одной крышей. Мысленно представляем команду, которая изо дня в день пилит, например, те же «Яндекс.Пробки».
  • Когда говорим о проекте, имеем в виду именно какой-то ограниченный во времени квест, переданный заказчиком каким-то парням из Барнаула. Мысленно каждый представляет свою веб-студию. Ну или если не имеет студии, пусть представляет нашу.

Казалось бы, разница невелика — проекты, продукты, один хрен те же самые специалисты сидят и делают примерно одно и то же. Так же за ними присматривает менеджер. Также бюджет берется из кармана владельца бизнеса. Но нет, всё работает по-разному.

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

Работа над проектом и продуктом: в шкуре владельца

Проектная разработка

Хотя адепты гибких методологий и называют заказчика сайта Product Owner«ом — на деле же он таких функций не выполняет. Банкет оплачивает, иногда вторгается в уютный мирок заказной разработки со своей картиной мира и правочками. Но не больше.

У заказчика проекта минимум два оправдания, почему он не может быть тем самым овнером:

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

Вообще аутсорсинговая природа проекта формирует отношение владельца ко всему процессу. Команду он не хантит по человеку в месяц, никого не собеседует (и своего эйчара не напрягает). У него не болит голова насчет того, что с этими людьми делать дальше, когда работа закончится. Он не парится о мотивации или поиске компетентного менеджера на проект. Не рассчитывает окупаемость, не планирует бюджет.

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

И дальше уже пошло-поехало: ТЗ, презентации, правочки. Стоп, снято, в продакшен.

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

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

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

Продуктовая разработка

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

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

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

Теперь о том, как себя чувствует команда там и там.

Продуктовая команда и команда «на потоке»

Проектная разработка

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

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

Нормальная ситуация.

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

Итак, что можно взять для себя хорошего, работая в потоковом продакшене:

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

В продуктовой команде всё немного по-другому.

Продуктовая разработка

Программисты, которые ушли из студии и устроились в продукт — как правило, говорят о том, что там спокойнее. «Бесконечный» характер работы и отсутствие того самого подгорающего фитилька (и плеяды новых проектов на очереди) делают рабочий темп медленнее и вдумчивее.

У потоковой разработки в фокусе сроки — для студии их очень нежелательно сдвигать вперед (да и назад тоже). При плотной загрузке любой сдвиг идет в ущерб остальным проектам. Если при этом сроки растягиваются — то студия упускает прибыль.

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

Ну это утрированно, но в целом так.

В продукте сильнее бизнес-составляющая. Собственно, та система координат, в которой работает вся команда, от продакт-директора до стажера — это целевые пользователи, конверсии, маркетинговые исследования и так далее. Просто так собраться кучкой и решить «а давайте следующий сайт запилим на Реакте!» — не получится. Маркетологи скажут, на чем, почему и зачем вы будете делать следующий сайт.

Чему можно научиться, работая в продуктовой команде:

  • Думать как конечный пользователь проекта и решать его задачи.
  • Смириться с тем, что маркетинг и задачи бизнеса важнее технологий.
  • Побыть внутри устоявшейся команды (возможно, даже с тимбилдингом, но это не точно).
  • Брать на себя ответственность за успех или неуспех продукта.

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

Теперь о менеджменте всего этого.

Менеджер продукта и менеджер проекта — в чем разница

Проектная разработка

Менеджер проекта — это «свой парень». То есть, конечно, он немного из другой касты, но команда понимает: менеджер их защитит от неадекватных правок и нервотрепки.

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

С точки зрения экспертности проект-менеджера — он выступает для заказчика «консультантом по технологиям», дает экспертное мнение именно с точки зрения работы над проектом (а никак не с точки зрения бизнеса, здесь любая студия целиком полагается на экспертизу заказчика).

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

Продуктовая разработка

Вроде бы это тот же менеджер, вид сбоку, но нет. Главное отличие — продакт-менеджер является представителем бизнеса (умное слово: стейкхолдером).

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

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

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

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

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

Ну всё вроде бы

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

Кстати, можно подписаться на наши пуши (вон там снизу справа колокольчик) — тогда свежие статейки будут поступать вам сразу по готовности.

©  vc.ru