За 20 лет через Rubius прошли сотни успешных и не очень продуктов. Часть из них были нашими разработками, а часть – продукты заказчиков, которые мы помогали развивать. Какие-то из них так и не дошли до своего пользователя, и превратились в просто обязательства по контракту. В любом случаем, каждый из продуктов принёс нам полезный опыт работы с продуктами, который мы собрали в этом материале. Делимся, как должна выглядеть продуктовая разработка с технологическим партнёром, и почему делать хорошие продукты можно не только внутренней командой. Статья будет полезна всем, кто занимается развитием продуктов внутри промышленных компаний и планирует привлекать к этому подрядчиков.
Ключевое отличие в разработке продукта от проекта лежит в фокусе. Когда мы делаем проект, в нашем фокусе функции, роли, процессы, сроки и бюджеты, когда продукт — наш пользователь и его проблема. Поэтому в продуктовой разработке возникает ещё один важный этап работ – исследования рынка. Это не вписывается в классический подход к разработке, поэтому мы собрали особенности продуктовой разработки в отдельную услугу.
Особенности продуктовой разработки с привлечением подрядчика:
- Финансирование возможно только по модели Time&Material*: можно менять требования и приоритеты в любой момент
- В команде должен быть Product Owner или исследователь**. Он будет отвечать за все процессы, связанные с изучением рынка и проверкой гипотез продукта
- + 1 этап в работе команды: исследование и подтверждение гипотез перед началом разработки
- Фокус на метрики и бизнес-результаты. Систему метрик должны выстроить исследователь и заказчик совместно
- Больше синхронизаций между заказчиком, аналитиком и исследователем
* Time&Material — это подход, при котором договор оформляется не на фиксированный результат работ и ее стоимость соответственно, а на часы работы специалистов, занятых на проекте и их наработки за это время.
** Важно не путать исследователя с бизнес-аналитиком. Бизнес-аналитик сосредоточен на описании требований и желаний заказчика, который часто не является пользователем. А задача исследователя – проработать проблему и потребности пользователя продукта.
Product Owner или исследователь и этап валидации гипотез до того, как программисты начнут работать – должны быть в вашем проекте в любом случае. Даже когда вы решили всё делать самостоятельно.
Какие исследования нужны для разработки продукта
Исследования бывают количественные и качественные. Выбор методик и оценки зависит от особенностей и стадии развития продукта. Разберёмся на примерах.
Есть только идея
Заказчики приходят к нам с идеей продукта на десятки или сотни миллионов рублей. В этом случае мы рекомендуем пройти весь цикл исследования.
Сформулировать и проверить гипотезу потребности.
На этом этапе нужно ответить на вопрос: Какую проблему/задачу пользователя сервис будет решать? Как много таких людей/компаний на рынке?
Пример. Крупный производитель электродвигателей Русэлпром планировал разработать систему мониторинга работы и прогнозирования поломок на базе искусственного интеллекта. По задумке система должна была сократить затраты компании на гарантийное обслуживание оборудования. Однако в перспективе Русэпром планировал сделать систему коробочным решением и выходить на рынок готового ПО. Прежде чем начать разработку, мы оценили обе возможности: для внутреннего использования сделали прогноз время возврата инвестиций и их рентабельности, а для реализации как продукта оценили ёмкость рынка, целевую аудиторию, смоделировали возможную бизнес-модель. Обсудив это с заказчиком, мы сформировали концепцию MVP и начали разработку.
Сформулировать и проверить гипотезу ценности. Какую ценность сервис принесёт пользователю?
Пример. Крупный институт развития создал сервис BI-аналитики для синхронизации показателей с регионами: качество жизни, удовлетворённость медициной и образованием, доступность социальных услуг и др. К нам заказчик пришёл за доработками. Планировалось добавить блок по мониторингу социальных программ. Менеджер проекта считал, что раздел будет полезен для региональных руководителей, чтобы отслеживать статус таких программ, какие практики внедряются и др. Чтобы удостовериться в гипотезе ценности, мы провели JTBD-исследование, опросили более 20 пользователей и сформулировали Job story. Выяснилось, что региональные руководители всегда в курсе актуального состояния хода программ и дополнительный инструмент для отслеживания им не нужен. Зато им важно знать лучшие практики из других регионов, которые работают с такими же программами. В результате, в разделе появилась аналитика по другим регионам. А ещё мы получили данные о том, как пользователи сейчас работают с сервисом и поставили метрики, по которым будут оцениваться обновления.
Сформулировать гипотезу решения. Определить, как должен выглядеть будущий продукт, какие функции для него важнее всего, а какие можно отбросить. Компании часто пропускают этот этап и сразу переходят к разработке. И это большая ошибка. Мы рекомендуем обязательно тестировать возможные решения на будущих пользователях.
Пример. К нам обратился стартап Manufaqtura-Proptech с запросом разработать сервис для бронирования переговорок и рабочих мест. Стартап предлагает офисы в формате built-to-suit: находит клиента, составляет ТЗ, инвестирует в строительство, выступает генподрядчиком, а дальше — сдаёт клиенту коммерческие помещения в долгосрочную аренду. Одна из функций будущей системы – детальная 3D-визуализация офиса. По мнению заказчика, такая функция была необходима клиентам. В модель предполагалось вставить все детали офиса: от столов до растений. Такая проработка сильно бы замедлила загрузку сервиса. А разрабатывать проект было бы долго и дорого. Чтобы удостовериться в необходимости такого решения мы провели небольшое исследование. Опрос ЦА показал, что пользователям не нужна настолько подробная визуализация. Мы скорректировали ТЗ и сэкономили время и деньги заказчика. Подробнее о проекте можно прочитать здесь.
На схеме показали, как выглядит полный цикл проверки идеи.
Продукт вышел на рынок, требуются доработки
В этом случае цикл исследований похожий, но в сжатом формате. Задача исследователя протестировать на рынке каждую доработку по схеме: понять аудиторию продукта с доработками, какие потребности пользователя закрываются в этом случае, определить ценность и чего ещё может не хватать, чтобы полностью доработать продукт.
В чём польза привлечения подрядчика к продуктовой разработке
Такой подход к разработке продукта обеспечивает предсказуемость результатов и повышает шансы на выход продукта на рынок, способствует росту ключевых метрик продукта и прибыли компании. Кроме того, подход помогает сократить затраты и время на разработку, раньше вывести продукт на рынок и повысить удовлетворенность пользователей. Процесс разработки легко контролируется и имеет прозрачную цель и стратегию.