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

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

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

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

Особенности продуктовой разработки с привлечением подрядчика:

*Time&Material — это подход, при котором договор оформляется не на фиксированный результат работ и её стоимость соответственно, а на часы работы специалистов, занятых на проекте и их наработки за это время.

**Важно не путать исследователя с бизнес-аналитиком. Бизнес-аналитик сосредоточен на описании требований и желаний заказчика, который часто не является пользователем. А задача исследователя – проработать проблему и потребности пользователя продукта.

Product Owner или исследователь и этап валидации гипотез до того, как программисты начнут работать, – должны быть в вашем проекте в любом случае. Даже когда вы решили всё делать самостоятельно.

Исследования бывают количественные и качественные. Выбор методик и оценки зависит от особенностей и стадии развития продукта. Разберёмся на примерах.

Есть только идея

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

Нужно сформулировать и проверить гипотезу потребности

На этом этапе нужно ответить на вопрос: Какую проблему/задачу пользователя сервис будет решать? Как много таких людей/компаний на рынке?

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

Сформулировать и проверить гипотезу ценности. Какую ценность сервис принесёт пользователю?

Пример. Крупный институт развития создал сервис BI-аналитики для синхронизации показателей с регионами: качество жизни, удовлетворённость медициной и образованием, доступность социальных услуг и др. К нам заказчик пришёл за доработками. Планировалось добавить блок по мониторингу социальных программ. Менеджер проекта считал, что раздел будет полезен для региональных руководителей, чтобы отслеживать статус таких программ, какие практики внедряются и др. Чтобы удостовериться в гипотезе, мы провели JTBD-исследование, опросили более 20 пользователей и сформулировали Job story. Выяснилось, что региональные руководители всегда в курсе актуального состояния хода программ и дополнительный инструмент для отслеживания им не нужен. Зато им важно знать лучшие практики из других регионов, которые работают с такими же программами. В результате, в разделе появилась аналитика по другим регионам. А ещё мы получили данные о том, как пользователи сейчас работают с сервисом и поставили метрики, по которым будут оцениваться обновления.

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

Пример. К нам обратился стартап Manufaqtura-Proptech с запросом разработать сервис для бронирования переговорных комнат и рабочих мест. Заказчик настаивал на детальной 3D-визуализации офиса как важной функции для будущих пользователей. В модель предполагалось вставить все детали интерьера — от столов до растений. Такая проработка сильно бы замедлила загрузку сервиса. А разрабатывать проект было бы долго и дорого. Мы провели исследование, и опрос ЦА показал, что пользователям не нужна настолько подробная визуализация. Мы скорректировали ТЗ и сэкономили время и деньги заказчика. Подробнее о проекте можно прочитать здесь.

На схеме показали, как выглядит полный цикл проверки идеи.

Продукт вышел на рынок, требуются доработки

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

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