Какое в проекте продукт

К этой статье меня подтолкнул большой перекос, который я вижу в массовом сознании и сознании профессионального сообщества менеджеров IT компаний. Увы, сайтов про управление проектами море, а про управление продуктами — кот наплакал.

Это как если бы было море книг, тренингов, целых институтов о том, как правильно ходить, и ни одной брошюрки про то, как выбрать направление пути.

В книгах по управлению проектами (особенно для новичков) авторы очень любят начинать с тезиса о том, что мир состоит из проектов, проекты везде. Готовите еду — проект, лечитесь у доктора — проект, ковыряетесь в носу или занимаетесь любовью, даже отпуск — всё проекты.

Конечно музыкант и в повседневной жизни повсюду слышит музыку, кинооператор выстраивает кадр, а парикмахер опознает людей по прическе. Но с проектным мышлением и проектной терминологией мир

сошел с ума

зашел слишком далеко.

Дальше я приведу несколько примеров, чем это вам может грозить.

Затевая очередную авантюру, мы говорим, что начинаем проект. Рассказывая другу о каком-то сайте, мы называем его проектом. На собеседовании рассказываем о проектах, над которыми работали.

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

За простым изменением текста часто явно или неявно скрывается мина замедленного действия, корень которой — в изменении смысла и восприятия.

Ликбез

Что такое проект? Проект это деятельность (процесс), определяющийся тремя главными свойствами:

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

Если нет хоть одного из этих признаков, перед нами что угодно, но не проект.

Что такое продукт? Продукт это нечто (часто результат чьего-то труда), что продается, покупается и используется.

Еще проще: проект — это процесс, продукт это результат.

So what?!

Мы (люди, организации с которыми и в которых я работал, о работе которых я знаю не по наслышке) слишком часто излишнее внимание уделяем процессу, а не конечному результату. Без хорошего процесса сложно получить хороший результат, но результат гораздо важнее.

И вот почему.

1. Live long and prosper или рукописи не горят

Любому проекту всегда приходит конец. Действительно успешные продукты обычно переживают своих создателей (вспоминаем Джобса, Диснея, фараонов с их пирамидами, Христа с его учением и так далее вплоть до известных ученых, изобретателей).

Мысля в пространстве проекта, вы невольно настраиваете себя на то, что все это рано или поздно кончится. Но с концом одного проекта в реальной жизни все только начинается (если вы не плохонький аутсорсер, которому надо побыстрее избавиться от очередного заказа).

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

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

2. Show me the f*cking money!

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

Никто не покупает помидоры за тысячу рублей, если рядом продаются такие же за сто. Не смог уложиться по себестоимости в цену конкурентов — ты прогорел, но это твои проблемы. Человек всегда покупал и будет покупать продукты, оптимальные по его личным критериям цена/качество/удовлетворенность, мало задумываясь о том, какой процесс привел к этому результату.

Покупают результат.

Рассуждая о том, что вы делаете как о продукте, вы чаще становитесь на тот же берег реки, где стоит ваш покупатель. И чаще задаетесь ключевыми вопросами (каким должен быть продукт? сколько он должен стоить? как нам его продавать? кому он нужен? куда его развивать?) и под эти ответы подстраиваете ваши процессы, а не наоборот.

3. Продукт это конкретно

Проект может умереть, едва начавшись, а может длиться вечно, он может быть хорошим, плохим, замороженным, запутанным, затянутым, интересным, унылым, тяжелым, дорогим, сложным, дешевым, а нередко сначала дешевым и интересным, а потом внезапно унылым и дорогим…

А продукт либо есть, либо нет.

Проект это абстракция для большой совокупности процессов, это довольно тонкая и сложная материя. Ее не просто объективно и конкретно оценивать, описывать и управлять. Для этого и существует отдельная дисциплина на грани искусства «проектное управление», а вы как думали!

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

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

4. Хороший проект не гарантирует нужный результат

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

Можно взять проверенный сюжет, нанять крутых спецов, вложить много денег в продвижение и получить полный провал (пруфлинк раз и два), а можно на пустом месте создать шедевр (раз и два).

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

Это может дать ложное ощущение того, что все идет хорошо. Что движемся верной дорогой к правильной цели. Обдумывать саму цель, сам продукт при этом уже лень либо некогда: ни на стратегическом, ни на тактическом уровне.

Наглядные примеры (помимо голливудских, указанных выше): третий рейх, СССР, многие дотком-баббл стартапы и т. д.

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

Помните о том, что в вашем деле сейчас важнее — процесс или результат.

Источник

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

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

Теперь же к нашей теме: проект vs продукт, в чем отличия и такая ли огромная между ними пропасть. Нужно подчеркнуть тремя жирными линиями, что мы рассматриваем эти понятия с точки зрения IT-сферы. Потому что булочки, например-это продукт, а выпекание хлеба-проект (хотя я и не согласна с этим), но нас это не сильно интересует.

В интернете можно найти уйму отличий проекта от продукта. Иногда они оформлены в красивые таблички, как, например, вот эта (очень вероятно, что ее вы уже видели):

Понятная таблица, которая немного противоречит сама себе.

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

Проект так же имеет какой-то конечный результат, а разработка сайта (по своей сути) – это именно процесс. Процесс достижения этого конечного результата.

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

Главное отличие проекта от продукта.

Поэтому, по моему скромному мнению, самое главное и важное отличие проекта и продукта в IT — время. Что мешает реализации проекта внутренней командой компании? Или почему разработка сайта — не процесс разработки продукта (но это же и не проект, согласитесь)?

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

Почему никто не рассматривает эту сторону?

Я думаю, это связано с несколькими взглядами на сами понятия продукта и проекта (конечно, можно обращаться к таким авторитетным изданиям, как PMBook, однако всех вопросов это не разрешит). Проект – как процесс, продукт – как результат. Продукт состоит из проектов (= процессов). Тогда одно – лишь составная часть другого и сравнивать их не имеет смысла (но это необязательно, ведь бывают проекты, по окончанию которого результатом будет не часть продукта, а что-либо другое).

Можно сказать, что проект и продукт – разные стадии развития одного и того же. Со своими процессами, организацией работы, команды и т.д., но суть одна – проект должен стремиться к тому, чтобы стать продуктом.

{
«author_name»: «Анна Новоселова»,
«author_type»: «self»,
«tags»: [],
«comments»: 4,
«likes»: 2,
«favorites»: 6,
«is_advertisement»: false,
«subsite_label»: «dev»,
«id»: 79854,
«is_wide»: true,
«is_ugc»: true,
«date»: «Tue, 20 Aug 2019 09:13:14 +0300»,
«is_special»: false }

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник