Описание создания продукта проекта: пошаговое руководство

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

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

Что такое продукт проекта (определение)

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

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

Продукт часто связывают с продуктовыми командами. Но на самом деле любой проект создаёт продукт. Для лучшего понимания рассмотрим разницу в типах команд:

• Продуктовые команды – это команды, которые отвечают за создание того, что можно продать, или того, что может дать настоящую ценность. Продукт всегда имеет какой-то набор свойств: характеристики, форма, структура и т.п. Он не всегда осязаемый, но им всегда можно пользоваться. Чаще всего продуктовые команды трудятся над написанием или сопровождением программ (мобильных приложений, сервисов и т.п.), новой линейкой товаров (с выводом на рынок и тестированием спроса) и т.п. Продуктовая команда может существовать вечно – пока в ней нуждается продукт.
• Проектные команды – это временные команды, которые создаются под конкретную задачу. Они как наемные рабочие или бригада, которым платят за какую-то услугу или предметную работу. Это тоже продукт. Но как только проект завершен, проектная команда распускается, так как она достигла своих целей и больше не нужна. Простые примеры проектов – внедрение CRM или систем управления, строительство домов или жилых комплексов, запуск сайта под ключ, проверка гипотез и т.п.
• Проектные офисы (PMO) – это отдельная команда, а точнее штатный отдел или служба компании, которая управляет другими командами и проектами. Её продукт – управление. Она как диспетчерская, которая берет на себя координацию и распределение ресурсов, управление рисками. Пока существует компания, будет существовать и проектный офис.

Читайте также: Кросс-функциональные команды.

Виды и типы продуктов в проектах

Продукты или результаты работы проектов можно классифицировать по разным признакам. Например:

По варианту создаваемого продукта

Продукты могут быть:

• Материальные – это конкретные предметы, которые можно «пощупать», например, товары, здания, оборудование, бытовая техника, машины, механизмы и прочее.
• Нематериальные – это чаще всего программы, цифровые и интернет-сервисы, базы данных, макеты дизайна, образовательные программы, методики, схемы, бизнес-процессы. Отличие налицо – их нельзя «пощупать», но ими можно пользоваться для получения какой-то ценности.

Альтернативная классификация с привязкой к формату продукта:

• услуга;
• изделие;
• результат (например отчет).

По назначению

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

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

Исследовательские продукты – все то, что может подтвердить или опровергнуть идеи и гипотезы. Исследования рынка, пилотные проекты, MVP, прототипы, тестовые серии продуктов пр.

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

Индивидуальные продукты – те, что делаются строго под одного клиента.

Продукты также можно делить по масштабу или охвату:

• локальные;
• глобальные;
• корпоративные.

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

Пошаговый процесс создания продукта проекта

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

Этап 1. Определение целей проекта

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

Команда должна понимать:

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

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

Этап 2. Сбор требований и анализ

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

Они могут описывать:

• функциональность;
• сроки;
• безопасность;
• внешний вид;
• производительность;
• правила использования;
• и другие свойства или характеристики продукта.

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

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

Этап 3. Планирование работ

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

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

• определить сроки;
• взять в расчет риски;
• распределить зоны ответственности;
• выбрать подход к управлению проектом.

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

Главный критерий – чем понятнее план и его составляющие, тем лучше.

Читайте также: Как оценивать задачи в проектах

Этап 4. Проектирование продукта

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

В зависимости от направленности проекта этап может включать:

• описание архитектуры системы;
• изготовление прототипов или минимально-жизнеспособных продуктов;
• проектирование макетов;
• разработку схем;
• оформление документации.

Например, в IT-проектах часто создаются интерфейсы и тестовые версии продукта, а в инженерных проектах – чертежи и технические модели.

Для схем можно использовать одну из популярных нотаций.

Именно здесь появляется более-менее внятный образ будущего продукта. Иногда для проверки идеи предлагаемый продукт сначала выпускают в упрощенном виде — как MVP или пилотный вариант.

Этап 5. Изготовление продукта

Является основным этапом создания продукта проекта. Команда начинает непосредственно реализовывать все, что было запланировано ранее.

В зависимости от типа проекта сюда может входить:

• написание кода;
• сборка оборудования;
• оформление документации;
• написание контента;
• строительные работы.

Во время разработки часто возникает ощутимая разница между первоначальными ожиданиями и реальной ситуацией. Некоторые решения приходится переделывать, а отдельные функции – упрощать или расширять.

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

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

Этап 6. Проверка качества и тестирование

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

Тестирование предполагает:

• поиск ошибок;
• проверку стабильности;
• анализ безопасности;
• оценку удобства использования;
• проверку совместимости.

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

Методы обратной связи

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

Этап 7. Внедрение и передача продукта

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

На данном этапе необходимо:

• оформить документацию;
• подготовить инструкции для операторов и пользователей;
• провести обучение;
• настроить инфраструктуру;
• обеспечить поддержку.

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

Этап 8. Оценка итогов проекта (ретроспектива)

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

Обычно анализируются:

• сроки выполнения;
• расходы;
• качество продукта;
• удовлетворенность заказчика;
• эффективность процессов.

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

Этап 9. Поддержка и развитие продукта (или закрытие проекта)

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

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

Однако в проектных командах, если проект готов, команда распускается или приступает к работе над другим проектом.

Читайте также: Что такое SDLC и как устроен жизненный цикл разработки ПО.

Как выбрать продукт проектной деятельности

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

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

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

Как раз для этого и существуют проекты – чтобы находить решения для нестандартных / новых ситуаций.

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

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

Критерии оценки качественного продукта в проектной работе

Конечный результат может быть разным. Если вы поручите одну и ту же задачу разным командам, то итоговый продукт у каждой из них обязательно получится уникальным. Но как понять, что результат вас устраивает? Правильный ответ – проведение оценки.

Существуют разные методы и подходы оценки. И, сразу вас расстроим, ни одного 100% рабочего или идеального нет.

Чаще всего в проектах применяются следующие критерии оценки:

• Соответствие требованиям. Это как сравнение «план/факт» (AS IS / TO BE). Чем ближе продукт к тому, что ожидал заказчик, тем лучше. Именно поэтому, если заказчик хочет получить что-то конкретное, а не абстрактное, он обязан предельно четко сформулировать свои требования – функциональные и нефункциональные.
• Ценность и полезность. Чем больше продукт дает ценности своим пользователям, тем он качественнее. Сбалансированная ценность обеспечивает хороший пользовательский опыт, стимулирует продажи продукта, но при этом минимизирует затраты на его реализацию. Продукт, который не приносит пользы и продаж, как можно догадаться, некачественный.
• Удобство использования (юзабилити). Когда аналогичных продуктов на рынке много, сложно чем-то удивить. И здесь на помощь приходит такой критерий оценки, как юзабилити. Чем продукт понятнее целевой аудитории и проще в использовании, тем лучше. Оценить юзабилити можно только с помощью обратной связи и опросов клиентов.
• Удовлетворенность. Еще одна общая оценка от пользователей. Для получения конкретных «цифр» используются разные форматы опросов и метрики: NPS (лояльность), CSat (общая оценка удовлетворенности), CSI (индекс удовлетворенности), CES (индекс усилий клиента). Данные логично анализировать в динамике – с привязкой к изменениям в продукте или к маркетинговым мероприятиям.
• Статистика коммерческих показателей – продажи, окупаемость / ROI, конверсия, средний чек, время использования и т.п. Даже если продукт максимально положительно воспринимается целевой аудиторией, но не дает продаж, он бесполезен для владельца. Нет интереса инвестора или владельца – нет самого продукта. Метрики для оценки финансовых показателей могут быть разными. Главное, чтобы они отражали цели инвесторов и владельцев.
• Соответствие профильным стандартам и нормам. Применимо не для всех ниш, но для многих продуктов можно найти вполне конкретные технические стандарты – ГОСТы, СНиПы и т.п. Все, что им не соответствует, по определению некачественное.

В профильных продуктах могут использоваться нишевые метрики и оценки. Например, время простоя и доступность для SaaS-сервисов, время реагирования на инциденты и т.п.

Как презентовать и защитить свой продукт перед руководством/спонсорами

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

Чтобы заинтересовать потенциальных инвесторов нужно продумать следующие моменты:

• Описать что конкретно дает ваш продукт – какие проблемы и боли он решает, для какой целевой аудитории.
• Посчитать несколько сценариев вложений в продукт: крайне негативный, позитивный и оптимальный.
• По аналогии посчитать выгоды продукта – какая может быть окупаемость вложений, какие выгоды можно получить и в каком объеме, если продукт некоммерческий.
• Как выглядят основные риски и какие вероятности их наступления. Есть ли у вас планы реагирования на них.
• Насколько планы близки к реальности – чем вы можете это подтвердить (исследования, опросы, расчеты, выкладки, тестирование прототипов и т.п.).

Примерная структура презентации, которая сработает в большинстве случаев:

1. Постановка проблемы / боли.
2. Предлагаемое решение и демонстрация возможностей продукта.
3. Описание выгод и пользы от использования продукта.
4. Предметные расчеты – стоимость, сроки, этапы развития и внедрения.
5. Потенциальные риски и ограничения, а также варианты реагирования на них.
6. Выводы.

Заключение

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