Разработка проекта vs разработка продукта — в чем разница
Есть проекты, а есть продукты. Причем оба термина применимы далеко не только к айтишной сфере. Батон и бублик — продукты, а запуск на хлебокомбинате новой линии по выпечке капкейков — проект.
Но если бы всё было так же просто, как хлебушек, то не было бы статьи. А она есть. Как еще можно отличить продукт от проекта:
Ну то есть в целом понятно.
Если говорить про айтишные дела, то когда у тебя есть сервис, который ты бесконечно улучшаешь, меняешь, измеряешь реакцию целевых пользователей, снова меняешь, ищешь под него инвестиции, кусаешь локти, если что-то идет не так, закладываешь свой УАЗ в ломбард ради новой фичи — у тебя стартап продукт. И у тебя, вероятно, продуктовая команда.
Когда у тебя есть краткосрочная задача запилить что-то по определенным требованиям (сайт, логотип, рекламную кампанию и т.д.) забрать деньги и отдать то, что получилось, в руки заказчика — у тебя проект. Вернее, проекты — потому что один закончился, начался второй, конвейер крутится, профиты мутятся.
Здесь и далее, чтобы не путаться, будем считать так:
- Когда говорим о продукте, подразумеваем, что все делается внутри одной компании, все менеджеры, маркетологи, технари, дизайнеры и прочие сидят под одной крышей. Мысленно представляем команду, которая изо дня в день пилит, например, те же «Яндекс.Пробки».
- Когда говорим о проекте, имеем в виду именно какой-то ограниченный во времени квест, переданный заказчиком каким-то парням из Барнаула. Мысленно каждый представляет свою веб-студию. Ну или если не имеет студии, пусть представляет нашу.
Казалось бы, разница невелика — проекты, продукты, один хрен те же самые специалисты сидят и делают примерно одно и то же. Так же за ними присматривает менеджер. Также бюджет берется из кармана владельца бизнеса. Но нет, всё работает по-разному.
Разберем различия с точки зрения владельца-заказчика, команды исполнителей и руководителя.
Работа над проектом и продуктом: в шкуре владельца
Проектная разработка
Хотя адепты гибких методологий и называют заказчика сайта Product Owner’ом — на деле же он таких функций не выполняет. Банкет оплачивает, иногда вторгается в уютный мирок заказной разработки со своей картиной мира и правочками. Но не больше.
У заказчика проекта минимум два оправдания, почему он не может быть тем самым овнером:
- Ему некогда, сайт не в приоритете. Объективно — нужно бизнес делать, а сайтом пусть займутся профессионалы. Все вы тут знаете, сколько килоджоулей надо сжечь, чтобы вытянуть из среднестатистического заказчика заполненный бриф.
- Он не всегда. Продакт-овнер — это работа, требующая подготовки, узкоспециальных знаний и опыта. Само собой, работая в обычном веб-продакшене вы таких уникумов в живой природе будете встречать довольно редко.
Вообще аутсорсинговая природа проекта формирует отношение владельца ко всему процессу. Команду он не хантит по человеку в месяц, никого не собеседует (и своего эйчара не напрягает). У него не болит голова насчет того, что с этими людьми делать дальше, когда работа закончится. Он не парится о мотивации или поиске компетентного менеджера на проект. Не рассчитывает окупаемость, не планирует бюджет.
Вместо этого он поступает просто: берет рейтинг самых-самых, выбирает из него кусок с подъемным для себя бюджетом, из него выбирает подрядчика, который больше понравился.
И дальше уже пошло-поехало: ТЗ, презентации, правочки. Стоп, снято, в продакшен.
Нет, само собой, бывают и совсем другие истории — когда заказчик компетентный в разработке ИТ-проектов, у него сильная команда на своей стороне, маркетологи, техдиректор, проект-менеджер, дизайнеры, контентщики. А на аутсорс он пошел просто потому, что своих ресурсов не хватило (или не хватило специализации).
Еще случай «другой истории» — когда у бизнеса есть доверенное агентство, взявшее на себя весь диджитал. Разные возникающие проекты агентство отдает аутсорс-продакшену.
В обоих случаях уровень работы приближается к продуктовому — тоже KPI, внятные постановки с самого начала, меньше неопределенности. Но это, скорее, исключение из правил, как вы поняли.
Продуктовая разработка
Здесь всё иначе. Продукт, то есть программный продукт — это и есть конечная цель для владельца бизнеса. Вернее, бесконечная — потому что нельзя просто так взять и выложить программный продукт, а потом забить на его улучшения.
И ни один нормальный продакт-овнер не спихнет такую важную миссию на аутсорсеров и не перепоручит безусому менеджеру. Другой уровень ответственности за результат переворачивает всё с ног на голову:
- Поиск кадров и их последующий, простите, груминг становится одной из самых приоритетных задач владельца продукта.
- Прибыльность всего мероприятия определяет благосостояние самого продакт-овнера. Нет успеха продукта — нет денег, владелец сильно рискует.
- Продукт требует настоящего стратегического планирования, бюджетирования и всего остального. В отличие от работы над проектом — где достаточно тактического и чуть-чуть операционного планирования.
- Всё это обязывает владельца осваивать профессиональные приемы и методики управления, несоизмеримо сильнее погружаться в тему, жить ей.
Теперь о том, как себя чувствует команда там и там.
Продуктовая команда и команда «на потоке»
Проектная разработка
Жизнь команды, которая делает проекты, похожа на сплав по горной реке — течение крутит так и сяк, приходится то и дело активно грести веслами, чтобы не напороться на скалу, лодку подбрасывает, адреналин, кайф, ушибы, ссадины. Гребущие активно тренируют мускулатуру и учатся обращаться с инвентарем.
Причем в процессе такой яростной гонки один из гребцов встает посреди лодки и говорит: «ребята, меня позвали вон на тот круизный лайнер, до свидания!». После чего включает свой реактивный ранец и улетает в голубую даль.
Нормальная ситуация.
Работа команды, делающей проекты на потоке — это очень много стресса, переключений между задачами, подгорающий фитилек дедлайна и... чемодан опыта. Так что можно сказать, что потоковая разработка — для молодых и энергичных, здесь как нельзя быстрее можно научиться всему. Такой непрекращающийся интенсив длиною в несколько лет.
Итак, что можно взять для себя хорошего, работая в потоковом продакшене:
- Набить шишек под присмотром ментора.
- Научиться новым интересным технологиям или инструментам.
- Поработать над разноплановыми проектами — как по тематике, так и по сложности.
- Заработать себе портфолио.
- Научиться работать в команде.
- Научиться работать в команде в условиях постоянного стресса.
- Стать гибким, уметь переключаться с одной задачи на другую и при этом минимально терять темп.
- Научиться работать быстро.
- Узнать азы устройства бизнеса.
- Уяснить, как устроен процесс работы над программным продуктом: методологии, стандарты.
В продуктовой команде всё немного по-другому.
Продуктовая разработка
Программисты, которые ушли из студии и устроились в продукт — как правило, говорят о том, что там спокойнее. «Бесконечный» характер работы и отсутствие того самого подгорающего фитилька (и плеяды новых проектов на очереди) делают рабочий темп медленнее и вдумчивее.
У потоковой разработки в фокусе сроки — для студии их очень нежелательно сдвигать вперед (да и назад тоже). При плотной загрузке любой сдвиг идет в ущерб остальным проектам. Если при этом сроки растягиваются — то студия упускает прибыль.
В продуктовой разработке сроки важны, но не критичны. Здесь придерживаются философии: если сдвигаем — значит, совершенствуем, а значит, создаем потенциально более успешный продукт.
Ну это утрированно, но в целом так.
В продукте сильнее бизнес-составляющая. Собственно, та система координат, в которой работает вся команда, от продакт-директора до стажера — это целевые пользователи, конверсии, маркетинговые исследования и так далее. Просто так собраться кучкой и решить «а давайте следующий сайт запилим на Реакте!» — не получится. Маркетологи скажут, на чем, почему и зачем вы будете делать следующий сайт.
Чему можно научиться, работая в продуктовой команде:
- Думать как конечный пользователь проекта и решать его задачи.
- Смириться с тем, что маркетинг и задачи бизнеса важнее технологий.
- Побыть внутри устоявшейся команды (возможно, даже с тимбилдингом, но это не точно).
- Брать на себя ответственность за успех или неуспех продукта.
Сложно сказать, где команде работается лучше. Потоковая разработка — это отличное место для прокачки и развития «по горизонтали». Продуктовая — для углубления в какую-то одну тему. Вряд ли вы встретите человека, который бы хотел вернуться в потоковую разработку после продуктовой — как ни крути, а в продукте спокойнее (правда, если это типичный стартап, то «спокойствие» будет выражаться во впахивании по 12 часов в сутки).
Теперь о менеджменте всего этого.
Менеджер продукта и менеджер проекта — в чем разница
Проектная разработка
Менеджер проекта — это «свой парень». То есть, конечно, он немного из другой касты, но команда понимает: менеджер их защитит от неадекватных правок и нервотрепки.
Однако тот же самый менеджер плохо защищает от внутренних марш-бросков с одного проекта на другой, работы над несколькими проектами сразу и так далее. Получается, что парень свой, но себе на уме — так думает команда.
С точки зрения экспертности проект-менеджера — он выступает для заказчика «консультантом по технологиям», дает экспертное мнение именно с точки зрения работы над проектом (а никак не с точки зрения бизнеса, здесь любая студия целиком полагается на экспертизу заказчика).
В чем заключаются главные функции проект-менеджера: обеспечить равномерную нагрузку на ресурсы, не промотать сроки, проконтролировать результат и продать готовую работу заказчику.
Продуктовая разработка
Вроде бы это тот же менеджер, вид сбоку, но нет. Главное отличие — продакт-менеджер является представителем бизнеса (умное слово: стейкхолдером).
На проектной разработке главным источником угрозы был заказчик — со всеми этими «я вам правочек принес», внезапными новыми идеями и поездками в отпуск. Поэтому менеджер был таким «фильтром», смягчающим внешнее воздействие на команду, защитником.
На продукте внешней угрозы нет — все работают над одним большим делом. Следовательно менеджер для команды сам становится источником угрозы. Для них он — как номенклатурный работник для простых работяг.
Соответственно, если менеджер переходит из потоковой разработки в продуктовую, его главная боль — научиться жить с тем, что он теперь еще в большей степени другая каста, нежели был раньше.
Что еще стоит добавить. Все умные методологии и роли, которые в них есть — изначально разрабатывались для продуктовых команд. Где реально делать ежедневные стендапы со всей командой и владельцем продукта. Где продакт-овнер — роль настоящая, а не номинальная. Где скрам — так скрам. Всё-таки на заказной разработке мало когда нужны эти самые поэтапные запуски, тестирование гипотез и прочая. Наше дело простое.
Применение всего этого опыта на заказной разработке — допустимо, иногда полезно, но не всегда обязательно.
Ну всё вроде бы
Понятно, что всех аспектов одной маленькой статьей не охватить, но мы хотя бы попытались. Есть ли третий путь, что-то между потоковым «клепанием» проектов одного за другим и усердным бдением над продуктом? Да, есть — но об этом расскажем потом.
Кстати, можно подписаться на наши пуши (вон там снизу справа колокольчик) — тогда свежие статейки будут поступать вам сразу по готовности.
