Продукты, проекты и другие звери

Продукт или проект? Диспуты на тему определений этих понятий не утихают и это не праздные споры. От особенностей каждой дисциплины зависят методы управления, зависят ожидания заинтересованных лиц. Хочу представить свои определения понятий «продукт» и «проект». Сразу хочу подчеркнуть — это будут именно мои определения, основанные на многолетней практике. Вряд ли вы найдёте их слово в слово в сертифицированной литературе, но я постараюсь показать все выкладки, которые приводят именно к таким определениям. С удовольствием подискутирую в комментариях, если ваша точка зрения отличается от моей.

Проект — это деятельность. Продукт — это тоже деятельность. По её завершении может появляться материальный результат в виде ИТ-продукта, но софт никогда не является самоцелью продукта. В отличии от проекта, где сам факт создания работающего ИТ-решения будет значимым результатом. Целью деятельности по созданию продукта является решение конкретной проблемы конкретной группы людей. Качество решения проблемы может измеряться деньгами, лайками, количеством спасенных жизней, числом ДТП или просто субъективным понятием «качество жизни». Да, так как мы, всё-таки, ИТ-шники, то мы используем ИТ-инструментарий для решения проблем. Однако, результат продукта в целом нельзя оценить по соответствию ТЗ и разработанного ИТ-продукта. А вот в проекте именно так мы и оцениваем результат.

Целью проектной деятельности является выполнение поставленной задачи в чётко заданные сроки и бюджет, с заданным качеством. Даже если проектное задание пишется первым этапом проекта, у проекта всегда есть заказчик, в интересах которого это задание и пишется. Проект — заказчик, продукт — проблема. Это очень важное различие! Даже если заказчик проекта сформулирует цель как «решите мне проблему», это не будет равнозначно продукту по одной простой причине: ответственность. Как только проектная команда сформирует задание и принесёт на подпись заказчику, ответственность за то, что предложенный способ решает поставленную проблему, переходит к заказчику. Да, в каких-то случаях можно снизить риски непопадания в решение путем применения Agile-подходов (чтобы не затевать ещё один холивар, давайте примем, что в данном контексте Agile — это «подход, который снижает риски непопадания в результат короткими циклами разработки, постоянным анализом результата и возможностью поменять направление движения на любой итерации»). Но у проекта всегда есть ограничения. Как минимум по времени. А значит, ответственность за то, что в конце проекта результат не будет достигнут, все равно останется на заказчике (в особенности, как раз, при Agile-подходе, где заказчик вовлечен в работу достаточно плотно).

У продукта нет заказчика. Есть пользователи, чью проблему продукт решает. Но они совершенно не заказчики. Генри Форду приписывают фразу «Если бы я спрашивал своих пользователей, что мне делать, я бы до сих пор приделывал пятую ногу к лошади». Не так важно, кто фразу придумал, но она отлично иллюстрирует разницу. Форд решал проблему быстрого и независимого перемещения людей среднего класса. Яндекс-такси решает проблему быстрой подачи автомобиля независимо от принадлежности к таксопарку, а использование смартфона и ИТ-системы вместо единого диспетчерского центра позволяет выигрывать у последних ценой и качеством. Delivery-club решает проблему разнообразия еды. И так далее.

У продукта всегда есть инвестор. Это может быть как основатель, который инвестирует своё время и накопленные деньги, так и отдельная компания, вкладывающая деньги или связи. Инвестор отличается от заказчика тем, что не принимает от команды ответственность за результат. За результат продукта отвечает команда. Чтобы понимать, в правильном ли направлении двигается продукт, формируются продуктовые метрики. Относительно их изменения оцениваются те или иные изменения, сделанные в продукте за определенный период. У проекта тоже есть метрики, но они относятся, в основном, к освоению времени или бюджета. Чтобы понять разницу, давайте разберём простой пример: метрика «выполнение бюджета» за период показала превышение факта относительно плана. Анализ показал, что мы зацепили контекстной рекламой сегмент на который не рассчитывали. Конверсия сегмента в целевое действие показала, что потенциал есть. Если мы делаем продукт, то мы проведём анализ и усилим конкурентные преимущества продукта в новом сегменте, увеличив бюджет. Если мы делаем проект, то это явный выход за границы проекта и мы должны скорректировать рекламные объявления, чтобы убрать лишний трафик.

У каждого продукта есть, как минимум, один конкурент — привычный пользователю способ решения проблемы. Для Генри Форда — это были поездки верхом или конным экипажем. Для Яндекс-такси — обзвон таксопарков или звонок в единую диспетчерскую службу. Деливери клаб борется, в первую очередь, с «приготовим сами». И эффективностью каждого является не удобство интерфейсов их приложений, а качество решения исходной проблемы. Если Яндекс-такси будет всегда приезжать существенно быстрее, чем через диспетчера, то каким бы ни было неудобным приложение, им будут пользоваться. А вот в Тольятти, например, до сих пор такси, заказанное по телефону единой диспетчерской службы, приезжает быстрее и в большее количество мест. Поэтому в Тольятти Яндекс-такси как продукт — неуспешен, несмотря на супер-крутое приложение.

У проектов вполне может не быть конкурентов, так как целью проекта может быть оптимизация какого-то процесса или просто сбор данных, разведка боем. Проект заканчивается, как только достигнута его цель или вышел срок на её реализацию. Продукт жив, пока жива проблема. Изменения для продукта — способ выживать в условиях конкуренции. Каждую итерацию продуктовая команда должна отвечать на вопросы «что мы можем поменять, чтобы нашим пользователям стало ещё проще/быстрее/комфортнее решать свою проблему». Проектная команда решает обратную задачу — как не допустить разрастания объёма проекта.

Теперь, исходя из приведённых характеристик, давайте выведем определения проекта и продукта.

• Проект — это деятельность, направленная на получение изначально заданного результата в пользу конкретного заказчика, в изначально заданные деньги, время и уровень качества. Успешность оценивается абсолютными (не зависящими от оценки предыдущих периодов) показателями точности попадания в деньги, время и требования ТЗ.
• Продукт — это деятельность, направленная на решение определённой проблемы определённой группы пользователей. Бюджет, сроки и качество зависит, в первую очередь, от возможностей конкурентов, во вторую — от умения команды ошибаться быстро, извлекая пользу из ошибок. Критерий успешности продукта — это всегда относительные метрики — понять успешность продукта можно только сравнивая текущую метрику с её же значением на предыдущем периоде.

Перед тем, как сделать выводы, хочу ответить на немой вопрос читателей: «Какое отношение имеет картина в заголовке к обсуждаемой теме»? Самое прямое. Якоб Йорданс изобразил вторую встречу сатира с крестьянином из басни Эзопа «Человек и сатир». При первой встрече сатир спросил крестьянина, дующего зимой на свои руки:

—Что ты делаешь? Зачем дуешь на руки?
—Я согреваю их своим дыханием.
Во второй встрече, которая на картине, сатир спрашивает крестьянина:
—Зачем ты дуешь на суп, пытаясь его согреть? Он же и так горячий?
—Да нет же, я дую на суп, чтобы его остудить!

Из этого диалога сатир делает вывод, что люди — подозрительные двуличные существа, с которыми лучше не иметь дело.

Определения понятий «продукт» и «проект» нужны для того, чтобы не попадать в такую же ситуацию, как и сатир. Они нужны, чтобы применять нужные инструменты в нужное время, правильно выбрав систему управления. Чтобы не пытаться оценивать проектную деятельность продуктовыми метриками или наоборот. Чтобы не пытаться формировать бюджет продукта на основе ТЗ на ИТ-систему. Чтобы чётко сфокусировать команду на определённую стратегию работы. Например, при проектировании ИТ-систем в проекте имеет смысл выбирать наименее рискованные решения. А в продукте — те, что отвечают концепции win-win. Выбор итерационного водопада для разработки проекта — вполне естественный шаг, так как позволяет точнее контролировать бюджет и сроки. Использование гибких подходов в продуктах удобнее, так как именно они позволяют чаще и быстрее ошибаться. Используйте подходы в соответствии с реальностью, не обманывайте сами себя — и разочарований в жизни станет меньше.