Можно заказать приложение у именитого разработчика и на выходе получить сервис, который не решает проблем целевой аудитории и никому не нужен. А можно сделать приложение в небольшой студии, которое будет закрывать боли клиентов и приносить доход. Всё зависит от подхода к разработке: один нацелен на процесс, а другой на результат. Рассказываем, чем продуктовый подход отличается от проектного, почему продуктовый подход выгоднее и как заказчику начать его использовать.
Этот материал подготовила студия мобильной разработки WINFOX специально для Workspace. В блоге ребята делятся полезным контентом для тех, кто хочет сделать свое приложение. Там много полезных статей про этапы рабочего процесса, выбор подходов и платформ, продвижение готовых решений.
Продуктовый подход к разработке — это задача проверить идею заказчика и найти продукт, который нужен целевой аудитории и который решает ее задачи, а потом упаковать этот продукт в мобильное приложение и помочь бизнесу на нем зарабатывать.
Рустам Мухамедьянов:
Руководитель студии WINFOX
Главная идея продуктового подхода — постоянное тестирование решений и идей, стремление адаптировать их к потребностям пользователя. То есть нацеленность на бизнес-результаты, а не желание скорее сделать приложение, получить деньги и забыть про него.
Обнаружение продукта — необязательный процесс. Но если начать дорогостоящую разработку без проверки идеи, есть риск на выходе получить то, что не нужно клиентам, и зря потратить деньги. Например, у предпринимателя появилась идея сделать приложение, в котором человек сможет купить парковочное место, когда захочет оставить машину у торгового центра или рядом с домом. Предприниматель бегло изучил рынок и понял, что такого сервиса нет. Быстро нашел разработчиков, заплатил им и они сделали приложение. Оно хорошо выглядит и интуитивно понятно, но люди не стали его устанавливать. Им просто не захотелось заморачиваться: в этом случае удобнее искать места по старинке, а не открывать очередное приложение и скроллить бесконечную ленту с похожими вариантами.
Но есть другой вариант развития событий. Предприниматель не стал спешить с разработкой, потратил больше времени на выбор исполнителей, но в итоге нашел команду, которая использует продуктовый подход к разработке. Вместе они досконально изучили целевую аудиторию на этапе идеи, поняли, какие у этих пользователей запросы, и предприниматель не стал вкладываться в ненужный сервис. Вместе с разработчиками они решили продвигать другую идею, которая сработала. Ребята сделали приложение, которое помогает найти свою машину на огромной парковке — с этой проблемой часто сталкиваются те, кто приезжает в торговые центры на авто.
В первом случае заказчик пошел по традиционному пути, решив заниматься проектом, который лично ему показался интересным, а во втором сделал ставку на сам продукт.
Продуктовый подход предполагает другие приоритеты, подходы к работе и организацию рабочего процесса, чем проектный.
Определение целевой аудитории и ее проблемы — главная часть продуктового подхода. Не бойтесь потратить больше времени и сил на поиск проблемы и способов ее решения. Тогда как многие сразу переходят к поиску и обсуждению идей, лучше сделать шаг назад и сначала тщательно определить свою целевую аудиторию и ее боль.
Рустам Мухамедьянов:
Руководитель студии WINFOX
Прежде всего надо понять, как пользователь принимает решение о покупке. Для этого мы определяем персонажи пользователей, описываем пользовательские истории (User Story), составляем карту путешествия пользователей (Customer Journey Map). Это помогает хорошо представить и изучить потенциального покупателя, чтобы определить его главную потребность, которую и закроет приложение.
При продуктовом подходе разработчики не ждут от заказчика готовую концепцию, список требований к будущему приложению, свое видение бюджета и сроков реализации. Студия разработки подключается к проекту на этапе идеи, проверяет ее жизнеспособность и вместе с заказчиком находит оптимальную экономическую модель и модель монетизации, с которыми приложение будет решать проблемы клиентов и приносить прибыль.
Сегодня, когда жизнь и технологии меняются очень быстро, сложно составить адекватный план на год, четко его придерживаться и получить то, ради чего все затевалось. Поэтому долгосрочное планирование все реже бывает эффективным.
Удобнее ставить небольшие цели, например сделать MVP и протестировать его, а не представлять работу над приложением как одну огромную сложную задачу с одним измеримым результатом. Для этого в рамках продуктового подхода всю работу делят на короткие спринты — этапы, после каждого из которых заказчик получает рабочий продукт.
Рустам Мухамедьянов:
Руководитель студии WINFOX
Мы предлагаем заказчикам разделить всю работу на три главных составляющих: создание MVP, выпуск приложения с базовыми функциями и релиз функционального продукта, который приносит ожидаемый доход. Это позволяет в конце каждого этапа получать готовый продукт, который можно использовать, тестировать и монетизировать.
При проектном подходе бюджет определен заранее. То есть неважно, какой результат показали разработчики в конце. Если они формально выполнили техническое задание, учли пожелания заказчика и уложились в сроки, они достигли цели. А значит, должны получить оплату по договору.
Когда команда использует продуктовый подход, заказчик четко понимает, за что платит. Обычно бюджет проекта поделен на части: разработчики сделали MVP и получили часть оплаты, а заказчик начал тестировать приложение и работать с ним, не дожидаясь завершения всей работы полностью.
Рустам Мухамедьянов:
Руководитель студии WINFOX
При продуктовом подходе сложно четко определить стоимость всей работы в начале. В процессе часто появляются новые задачи и сложности, так как мы гибко реагируем на потребности пользователей, изменения рынка и пожелания заказчика. Но так как заказчик в этом случае платит не за процесс, а за результат, это все равно получается выгоднее.
Продуктовый подход — это про гибкость в принятии любых решений. Это значит, что если рынок быстро изменился и клиенты хотят использовать в приложении новую функцию, заказчик всегда может сказать об этом разработчикам. Они отреагируют быстро и перестроят свою работу, чтобы улучшить продукт здесь и сейчас.
При проектном подходе к разработке тестирование — отдельный этап, к которому переходят после того, как приложение полностью готово. Из-за этого не всегда можно быстро проверить, как работает добавленная функция и не падает ли приложение после обновления iOS: надо ждать, когда все остальное будет готово.
Продуктовый подход, который строится на внимательном отношении к потребностям целевой аудитории и стремлении помогать им решать свои проблемы, предполагает быстрое добавление новых функций и выпуск обновлений. Поэтому тестирование новых фич, экранов, обновленной системы лояльности и других инструментов происходит постоянно. Так получается быстро находить баги, исправлять их и идти дальше, стремясь непрерывно улучшать продукт.
При проектном подходе задача разработчиков — сделать продукт, который попросил заказчик. Поэтому дорабатывая и обновляя приложение, они ориентируются на мнение бизнеса: проектный менеджер собирает хотелки заказчика, формализует требования, рассчитывает стоимость доработок, ставит задачи программистам и следит за сроками.
Сердце продуктового подхода — пользователь. Поэтому после релиза разработчики собирают и анализируют обратную связь от тех, кто пользуется приложением. Эти отзывы попадают в бэклог, разработчики проверяют гипотезы и воплощают в жизнь те нововведения, которые помогут бизнесу достигать поставленных KPI.
Проектный менеджер — это связующее звено между заказчиком и разработчиками. Он отвечает за планирование работ, контролирует выполнение задач и сроки, следит за бюджетом, улаживает возникающие проблемы и отвечает за качество конечного результата. Несмотря на правильные цели, на практике работа проектного менеджера зачастую сводится к тому, чтобы угождать заказчику, выполнять план и вписываться в бюджет.
Например, заказчик захотел убрать возможность постоплаты товара из приложения, чтобы быстрее получать деньги и увеличить оборотные средства. Сказал об этом проектному менеджеру, тот пошел к разработчикам, они все сделали. Но через неделю заказчик пришел с новой проблемой: он открыл статистику и увидел, что из-за отключения возможности постоплаты теряет 15% клиентов и надо вернуть все на круги своя. В итоге команда зря потратила время и не сделала продукт лучше для пользователя.
Когда над приложением работает продуктовый менеджер, он смотрит на все пожелания заказчика глазами клиента. Потому что главная цель заказчика и разработчиков — сделать хорошо клиенту, а от этого выиграет и бизнес.
В этой ситуации продуктовый менеджер сначала проверит гипотезу заказчика. Прежде, чем идти к разработчикам, он изучит, как клиенты оплачивают покупки в приложении, и расскажет заказчику, к чему приведет его решение отключить постоплату.
Проектный подход | Продуктовый подход |
|---|---|
Когда делают проект, думают о том, как это делают | Когда делают продукт, думают о том, для кого это делают |
Желание удовлетворить заказчика | Стремление решить боли клиентов заказчика |
Заказчик приходит с готовой идеей и планом: он говорит, что ему надо, и разработчики дают ему это | Разработчики подключаются к проекту на этапе идеи, проверяют ее жизнеспособность, находят оптимальную модель монетизации приложения и способы решить боли клиентов |
Долгосрочное планирование и реализация | Работа по спринтам: краткосрочные цели, которые можно быстро достичь и сразу получить эффект |
Оплата за процесс: формальное выполнение технического задания, соблюдение сроков, работу над приложением | Оплата за результат: после каждого спринта заказчик получает рабочее решение, за которое заплатил |
Заказчик может вносить корректировки, добавлять новые функции и совершенствовать приложение после того, как оно готово | Совершенствование продукта — непрерывный процесс |
Тестирование готового приложения и исправление багов, когда сервис готов | Непрерывное тестирование и улучшение приложения после каждого спринта |
Доработка приложения на основе хотелок заказчика | Сбор обратной связи от пользователей, анализ данных и составление списка доработок на основе статистики |
Работой управляет проектный менеджер — связующее звено между разработчиками и заказчиком | Работой управляет продуктовый менеджер, который погружен в бизнес-цели заказчика и смотрит на продукт глазами клиента |
Продуктовый подход использует правило 1:10:100. Оно применяется в разных сферах жизни и бизнеса — от личной эффективности до управления проектами и менеджмента. Если применить правило к разработке, то его суть в следующем.
Разработка приложения включает три этапа:
идея и планирование;
разработка и тестирование;
релиз и использование.
На первом этапе мы обсуждаем идеи и планируем работу. После этого делаем приложение. На третьем этапе пользователи скачивают приложение и начинают его использовать.
Дешевле всего решить проблему на этапе идеи и планирования. Решение этой же проблемы на этапе разработки и тестирования обойдется в 10 раз дороже. Решение проблемы, когда приложение уже готово и загружено в сторы, выйдет в 100 раз дороже.
Рустам Мухамедьянов:
Руководитель студии WINFOX
Мы объясняем заказчикам, что разумнее потратить 1 рубль в начале, чем вкладывать 10 рублей в исправление ошибок во время разработки, не говоря уже о 100 рублях после запуска приложения. Предупредить возможные ошибки на старте — более правильно и выгодно, чем исправлять их по ходу или после релиза бесполезного приложения.
При продуктовом подходе рабочий процесс строится не так, как при проектном. Вот так обычно выглядит создание приложения при проектном подходе.
Работа происходит последовательно: чтобы начать следующий этап, надо закончить предыдущий.
Но на практике бывает удобнее решать задачи параллельно. Например, рисовать дизайн нового раздела, тестировать добавленные функции и проверять новые гипотезы, составленные на основании обратной связи от пользователей. Поэтому продуктовый подход состоит не из привычных этапов вроде дизайна, разработки и тестирования, а из спринтов.
Каждый спринт включает задачи из разных областей работы над приложением, но все они подчинены одной цели: в конце спринта показать рабочий продукт, который заказчик сразу сможет использовать.
Некоторые заказчики уверены: разработчики должны писать код, дизайнер — рисовать интерфейс, а заказчик — заниматься маркетингом, определять бизнес-цели и ценность продукта. При продуктовом подходе все члены команды включаются в процесс создания продукта. Это позволяет более комплексно смотреть на задачу и всегда иметь несколько точек зрения от разных специалистов.
Если вы думаете сделать приложение, будет эффективно подключить к работе над созданием продукта следующих специалистов:
технические специалисты: iOS-разработчики, Android-разработчики, программисты, которые работают с бэкендом и фронтендом;
специалисты по работе с бизнес-показателями: бизнес-аналитики, бизнес-разработчики;
специалисты по дизайну: UX-дизайнеры, UI-дизайнеры;
специалисты по управлению процессами: продуктовый менеджер, скрам-мастер, аджайл-мастер;
другие заинтересованные стороны: инвестор, представители компании заказчика;
целевые пользователи приложения.
Когда в создании приложения задействовано много людей, заказчик получает всесторонний обзор и мгновенную обратную связь по идеям, которые хочет реализовать.
Рустам Мухамедьянов:
Руководитель студии WINFOX
При продуктовом подходе сотрудники студии более ответственно подходят к работе: они чувствуют себя не наемными работниками, а создателями продукта. Они вместе с заказчиком переживают за результат и выкладываются на полную.
Работайте с идеям все вместе: выдвигайте гипотезы, оспаривайте предположения и проверяйте их на практике, привлекая разработчиков к процессу поиска продукта.
Поставьте себя на место целевого пользователя: исследуйте его потребности.
Определите проблему: сформулируйте потребности и проблемы пользователя приложения.
Сделайте MVP: создайте первую версию продукта и начните решать проблемы пользователей здесь и сейчас.
Тестируйте и совершенствуйте: проверьте, как работает приложение, получите обратную связь от клиентов, поймите, что надо улучшить, и постоянно дорабатывайте приложение.
Подпишитесь на ежемесячную рассылку Workspace
Отлично! Мы отправили письмо на указанный вами электронный ящик с инструкцией по подтверждению.
Если письмо с подтвержением вашего e-mail не будет получено в течение 10 минут, пожалуйста, проверьте папку СПАМ в соответствующем почтовом ящике.
