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

Для кого: прежде всего для специалистов ИТ, которые путаются в понятиях и хотят усвоить суть новых течений в разработке программных продуктов. Я, как автор, пыталась изложить текст таким образом, чтобы он был понятен всем, даже тем, кто не имеет отношение к ИТ.

Время прочтения: 25 минут.

Чем проект отличается от продукта?

В настоящее время стало очень популярным заниматься “продуктовой разработкой”. Вроде бы два слова нам понятны, мы знаем, что такое продукт и что такое разработка, но словосочетание вызывает много вопросов и сомнений. Предлагаю копнуть глубже и разобраться, что же это такое. При этом сплошь и рядом компании переходят от проектного подхода разработки к продуктовой. В чем же отличие? И что же такое “таинственное” есть в продуктовом подходе?

Когда вам говорят слово “продукт”, что рисует ваше воображение? 

Мои ассоциации это пища, что-то вкусное, съестное, например, пирожное, то есть продукт питания. Если обратиться к этимологии слова, то мы увидем в основе латинское слово productus — произведенный. То есть это что-то, что является результатом деятельности человеческого труда, и может быть направлено на потребление людьми. Это может быть предмет, услуга, вывод, или в нашем контексте — программный продукт. 

Мне нравится определение “Викисловаря”, что продукт — это то, что было произведено, создано или получено в результате какого-либо процесса или действия.

Что присуще продукту? Как его можно охарактеризовать или описать?

Это что-то, что имеет законченный вид и готово к потреблению. В данном случае это синоним к слову товар. То есть мы что-то продаём и тем самым зарабатываем от таких продаж. А я, как покупатель, должна быть заинтересована покупкой товара (продукта), который должен мне нравиться, чтобы я гарантировано выбрала его и отдала за это деньги. Мы приходим к бизнесу, предприятию, которое нам приносит прибыль за счет продаж товара (продукта). Если говорить о цифровом продукте, то мы его также продаём и производим.

Что же такое проект? Первая моя мысль, что проект — это деятельность, которая будет иметь результат, например, проектирование здания, которое потом мы построим. Если смотреть на этимологию слова, то тут тоже латинский, и это projectus — брошенный вперед. То есть это разработанный план постройки, сооружения чего-либо. Предварительный, предложенный проект, некий текст, который нам рассказывает о том как мы хотим получить продукт. Если говорить про синонимы, то это такие слова, как схема, план, расчёт. Проект может быть продуктом деятельности проектирования.

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

Если мы внимательно посмотрим на рисунок, то заметим, что каждая итерация создания продукта ведёт нас к новому улучшению продукта. Условно я назвала наш первый продукт “Звезда”. Мы что-то сделали, отдали на рынок, нашли покупателя, продали, получили обратную связь и сделали вывод, как его улучшить. Набили шишки и создали второй, более сложный продукт “Медведица”, который стал улучшенной версией. Далее цикл повторили и создали новый продукт “Созвездие”.

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

Откуда же появился такой интерес к продуктовому подходу ведения бизнеса (разработки программного продукта)? 

Иногда я слышу термин “4-ая промышленная революция”, которая относится к процессу оцифровки всех сфер и часто монетизации всего, что необходимо человеку с применением существующих технологий. Если вкратце проводить анализ развития человечества, то можно сказать, что человечество совершило переход от ручного труда к машинному, от мануфактуры перешло к фабрикам и заводам. Но данные революции совершались по принципу внедрения технологии и её использования. То есть, хочешь, не хочешь, бери и работай с инструментом, станком только потому, что он нам даёт возможность производить быстрее. Качеству и удобству уделяли внимание, но они не являлись основными. 

Сейчас рынок имеет избыток продуктов, который приводит к изменению стратегии продажи от “и так сойдёт” к подходу “хорошо”, и только такой продукт купит наш клиент. То есть рынок повернулся лицом к клиенту, и теперь не технология стоит на пьедестале рынка, а человек, клиент, покупатель, который нам платит деньги за продукт. Я, конечно, груба в своём определении “и так сойдёт”, потому что в тот момент, когда продукт производился в нашем недалеком прошлом, просто не было возможности создать его более удобным, продуманным, т.к. существовали ограничения среды производства и потребления. Но в современном мире многие продукты, произведенные по старым правилам, сейчас кажутся вычурными и непродуманными, про них так и хочется сказать “и так сойдёт”.

Поэтому продуктовый подход так хорошо развивается в направление B2C (то есть Business to consumer- бизнес для конечного потребителя, которым часто выступает физическое лицо) рынка программных продуктов и услуг. 

Рынок B2B (Business to business — бизнес для бизнеса, где в качестве потребителя выступает юридическое лицо) в последнее время сильно подтягивается. И тут тоже растёт конкуренция. 

И только рынок B2G (Business to government — бизнес для государства, в качестве заказчика и в конечном итоге потребителя выступает государство) отстаёт по моему мнению, там по-прежнему работает принцип “и так сойдёт”, точнее правила, регламенты, которые сложно изменить, и они нам приписывают инструкции, как пользоваться той или иной технологией. Они существуют в виде ГОСТов, некоторым из которых около 100 лет (я говорю про свой опыт работы соприкосновения с энергетической отраслью), и, чтобы их развернуть “лицом к человеку”, необходимо потратить много сил и времени, что в целом логично. Но там, где можно сделать быстрые изменения, они происходят, процессы идут.

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

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

В чем суть проектного подхода разработки программного продукта?

Давайте посмотрим на характеристики проекта, это:

• цели,
• сроки, 
• бюджет,
• качество результата,
• ресурсы,
• риски.

И именно Project Manager ведет работу с каждой характеристикой проекта.

Как же реализуется проект в ИТ сфере?

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

Набирается команда проекта, руководитель проекта (тот самый Project manager). И далее процесс укрупненно выглядит следующим образом:

1. Команда собирает требования от заказчика, фиксирует в виде документа, это может быть ТЗ, или пул User story, или ещё что-то. Тут всё зависит от методологии, по которой работает компания.
2. Требования выверяются и согласовываются с заказчиком.
3. По требованиям ведётся разработка программного продукта (внутренняя, своими силами, или внешняя/заказная, когда происходит выбор вендора).
4. Далее проводится этап тестирования.
5. Демонстрация заказчику того, что было разработано, то есть приёмка и доработка программного продукта по результатам приёмки.
6. Выкатка в продуктивную среду программного продукта.
7. Формируется новый пул задач на разработку от бизнес-заказчика, и далее всё по кругу, если оно требуется.

Процессом руководит наш Project manager, он отвечает за: 

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

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

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

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

В чём же суть продуктового подхода разработки программного обеспечения?

Если говорить про продуктовый подход, то, как мы уже ранее упоминали, у нас цель сделать нашему клиенту хорошо, он тут главный. У нас условия сильной конкуренции и наш клиент просто уйдет к другому, если ему не понравится наш продукт/сервис.

Какие же есть характеристики у продукта:

• Возможность приобретения
• Цена
• Качество
• Экологичность
• Имидж
• Марка
• Форма
• Упаковка
• Срок службы
• Ценность

И у нас появляется Product manager, руководитель продукта, который работает с каждой характеристикой продукта, а также с процессом создания продукта. В чём же концептуальное отличие от проектного подхода?

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

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

Пример из жизни. Возьмем компанию “ВкусВилл”. Они работают с отзывами покупателей и анализируют жалобы. Если на производителя сока стало поступать много жалоб, количество их возросло, это повод задуматься о решении проблемы или принятии крайних мер по смене производителя.

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

Тут ещё бы хотела упомянуть статистику, что только 0,1 по шкале до 10 (источник — https://itamargilad.com/the-tool-that-will-help-you-choose-better-product-ideas/ ) идей экспертов на рынке действительно нужны нашим клиентам, и они приносят прибыль. То есть всё остальное можно “выкинуть”. И подход “я — Верховный глава, я всё знаю” сейчас становится проигрышным. Решения же принятые на основе анализа данных дают 10 из 10 результата.

С чего же начинается продуктовая разработка? 

Мне так и хочется сказать — с изменения мышления. Это действительно необходимо. Все настолько привыкли быть «решателями», что мало кто копается в проблеме, остаётся на стадии формулировки, подтверждения. Тем более люди не хотят задавать себе неудобный вопрос «А действительно ли проблема существует?»

Любой продукт начинается с идеи или с идеи улучшения уже существующего продукта.

Но, как мы уже знаем по открытой статистике, 42% стартапов на 2019 провальны по причине того, что они просто никому не нужны (источник https://www.cbinsights.com/research/startup-failure-reasons-top/ ). Основатель компании думает, что если у него есть потребность в продукте, то она есть и на рынке. Но по факту это не так. Запускается что-то новое, вкладываются деньги в разработку, но клиентам оно просто не нужно.

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

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

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

Процессом управляет Product Manager.

Чтобы упростить жизнь, рассмотрим вариант запуска нового продукта.

1. Процесс начинается с гипотезы, то есть предположения существования проблемы, которую будет решать наш продукт. То есть мы считаем, что клиент примет решение о покупке продукта и сделает выбор в нашу сторону, потому что наш продукт действительно ему нужен, и он готов за него платить деньги. 
2. Проводим анализ рынка: что он есть, и есть аналоги нашего продукта на рынках, и насколько они прибыльны. Покупается ли продукт у конкурентов?
3. Чтобы проверить нашу гипотезу, нам нужно пообщаться с клиентом. Именно интервью с нашими клиентами помогут нам сделать выводы и принять решение о том, какие у клиента есть “боли”, проблемы, которые мы решаем с помощью нашего продукта. Делаем выводы по результатам интервью.
4. Далее, понимая проблему, мы переходим в зону решения, то есть мы описываем наш продукт.
5. Нам нужно стать ближе к пользователю и понять, кто наша целевая аудитория, которая нам готова платить. Мы создаём портрет нашего клиента.
6. Понимая нашу целевую аудиторию, мы начинаем подсчет тех самых людей, которые, с нашей точки зрения, готовы нам платить за наш продукт. Выбираем регион, который будет для нас интересен. Прикидываем оценку аудитории. 
7. Пытаемся разработать способы информирования наших клиентов о существовании нашего продукта. То есть мы думаем о рекламе и обратной связи от клиентов, как нам выстроить коммуникацию и узнать, почему клиенты покупают или не покупают наш продукт.
8. Считаем экономику продукта, пытаемся понять, при каких условиях экономика будет сходиться и приносить нам прибыль. Данные расчеты мы можем производить на основе открытых источников наших конкурентов.
9. Мы говорим про первоначальный запуск продукта, поэтому мы делаем пилот продукта, то есть MVP (минимально жизнеспособная версия продукта), запускаем его и смотрим, покупают его или нет, либо просто пробуем вручную имитировать продукт, если мы говорим про услугу.
10. Подсчитываем в цифрах сколько продали продукта, как и кому. Смотрим на цифры и делаем выводы.

Мы собираем “цифры” по каждому ключевому процессу и шагу нашего клиента. То есть производим расчет предполагаемой прибыли, подсчет того, сколько маркетинг привлёк клиентов, сколько купили, сколько отказались от покупки, опрос клиентов о причинах отказа от покупки, оценку того, насколько клиент доволен обслуживанием и покупкой. Всё это нужно для того, чтобы наш клиент к нам вернулся, снова оставил нам денег, еще и всем рассказал и привел с собой друзей. 

Продуктовая разработка ориентируется на данные и потребности клиента, в отличие от проектной, которая удовлетворяет заказчика.

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

После запуска продукта и понимания того, что продукт продаётся, команда идет на новый цикл улучшения продукта и берет в работу новые гипотезы. Я не буду говорить про все инструменты и практики, которые применяются при таком подходе, но всё достаточно логично. Если наш продукт хорошо продаётся, то нет смысла проводить эксперименты на всей нашей аудитории, мы будем выбирать небольшую фокус-группу и на ней экспериментировать, проводить так называемые “A/B тесты”. Смотреть, как наша фокус-группа реагирует на новые фичи продукта. И только после того, как тест на небольшой группе будет успешен, масштабировать нововведения на всю целевую аудиторию, но если тест провалился, то все спокойно выкидывают ненужный функционал вместе с гипотезой.

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

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

А что же всё таки в этом процессе делает Product Manager?

Обязанности Product Manager могут отличаться и зависеть от компании, типа бизнеса и многих факторов. Мы попробуем описать перечень обязанностей “классического” менеджера управления продуктом.

Достаточно часто Product Manager является “руками” основателя бизнеса. То есть именно Product Manager руководит процессом создания и улучшения продукта, транслируя бизнес-цели от руководства.

Product Manager отвечает за:

• определение целевой аудитории пользователей (отвечает на вопрос “Кто пользуется продуктом?”),
• проводит анализ рынка и конкурентов, следит за новинками, чтобы продукт компании был конкурентоспособным,
• формирует, собирает и тестирует гипотезы, которые помогут улучшить продукт,
• отвечает за привлечение и удержание клиентов,
• формирует сценарий шагов клиента, которые приводят его к оплате,
• отвечает на вопрос — “почему клиенты не пользуется продуктом?”,
• следит за изменением показателей/метрик продукта,
• приоритезирует задачи,
• планирует реализацию новых функций/фич продукта,
• отвечает за бюджет (не во всех компаниях входит в обязанности),
• участвует в наборе команды (также не всегда такое происходит на практике, но навыки командообразования также необходимы),
• плотно взаимодействует с командой разработки (описание постановок на разработку с аналитиками или без, разработка пользовательского интерфейса),
• взаимодействие с пользователями продукта (выстраивание коммуникаций, получение обратной связи, анализ поведения пользователей).

Главная цель Product Manager — сформировать Product Vision таким образом, чтобы показатели количества привлеченных пользователей, повторные покупки, “время жизни пользователя” и другие показатели продукта постоянно росли, что должно приводить в итоге к росту прибыли компании.

То есть Product Manager — это руководитель, который обладает способностями предпринимателя (создание и развитие бизнеса).

Выводы

Подводя итоги, предлагаю кратко представить результат сравнения проекта и продукта, Project Manager и Product Manager.

Результат сравнения проекта и продукта.

Термины проект и продукт сложно сравнивать, так как они лежат в разных плоскостях понятий. Проект — это деятельность, продукт — это результат деятельности. И как показал митап №9 “Аналитиков Москвы” (https://www.moscowanalysts.club ), даже точки соприкосновения сложно выделить.

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

Проект	Продукт
Сроки Цели Бюджет Риски Критерии качества	Возможность приобретения Цена Качество Экологичность Имидж Марка Форма Упаковка Срок службы Ценность

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

Характеристика	Продукт	Проект
Синоним	Результат, товар	Процесс, деятельность
Время жизни	Бесконечное время жизни. Время жизни может закончится, только в том случае когда продукт “умрёт” (его никто не будет покупать).	Конечное время жизни. Проект всегда имеет начало и конец, часто данные рамки жесткие и указаны в документации к проекту.
Бюджет	Грубо говоря, “бесконечен”, мы можем посчитать бюджет только на итерацию улучшения продукта для достижения бизнес-цели (метрики).	Строго определен и ограничен.
Функционал	Всегда имеет законченный вид, то есть состояние, когда им можно пользоваться.	Может быть плавающий и может содержать только часть функционала продукта.
Качество	Сложно оценить, на старте создания продукта качество может быть условным, но хочется сказать фразу, “что качественный продукт лучше продается” (иногда более удобный в использовании продукт).	Строго говоря результат проекта описывается в документации, где также должно быть раскрыто понимание качества результата.
Фокус разработки	Фокус на конечного пользователя, наблюдение за его поведением, анализ обратной связи.	Фокус на заказчика. Цель уложиться в бюджет и сроки.

Сравнительная таблица компетенций Product Manager vs Project Manager

Как и с терминами проект и продукт, также и с менеджерами, которые управляют проектом и продуктом, очень сложно их сравнивать и находить общие точки соприкосновения.

Ниже представлена таблица сравнения деятельности менеджеров, источник таблицы:  https://netology.ru/blog/product-or-project

В завершение хочется отметить, что Product Manager не равно Project Manager.

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

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

Но инструментарий, который наши менеджеры используют на практике, сильно разнится. По факту в качестве Product Manager ошибочно назначают маркетологов, дизайнеров, Project Manager и любых других менеджеров, которые занимаются развитием бизнеса или связей с партнерами/клиентами, выделяя только определенное направление деятельности как основное в работе. Такое применение Product Manager в компании не даёт желаемый эффект от реализации продукта. Это тоже самое, если бы спортсмен-пловец качал только одну руку на тренировках. Его бы тогда заносило в бок, он загребал бы сильной рукой больше и не достигал поставленной цели плыть быстро и прямо по дорожке.

Самый страшный сон Product Manager, когда от него ожидают работу не только, как от Product Manager, но и также как и Project Manager, сваливая в кучу обязанности. Конечно, грамотный специалист справится с любыми сложностями, но это больше похоже на заколачивание гвоздей топором или применением back-end разработчика еще и как front-end разработчика. Оно, конечно, получится, но вот результат будет не настолько хорош, как хотелось бы.

Поэтому настоятельно рекомендую не валить в одну кучу понятия Product и Project, не смешивать обязанности Product Manager и Project Manager, которые являются специалистами разных плоскостей и выполняют деятельность, которая только отчасти совпадает.

Во время написания статьи использовался материал: