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

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

Можно вложить в разработку приложения пару миллионов рублей, нанять разработчиков из рейтинга Рунета, а на выходе получить приложение, которое не нужно пользователям. А можно сделать рабочий продукт небольшой командой и в сжатые сроки: приложение будет решать проблемы клиентов, они будут его устанавливать и использовать, и вы достигнете бизнес-целей. Вся разница в подходе: первый нацелен на процесс, а второй — на результат.

Мы в Winfox рекомендуем использовать второй подход. Он называется продуктовым.

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

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

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

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

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

Разработка без продуктового подхода. Иван начитался статей про то, как молодые предприниматели создают приложения и зарабатывают на них миллионы. И подумал: «А чем я хуже? У меня куча уникальных идей». Иван решил сделать приложение, в котором человек сможет купить парковочное место, когда захочет оставить машину у торгового центра или рядом с домом. Предприниматель бегло изучил рынок и понял, что такого сервиса нет. Вот она, золотая жила! Иван нашел разработчиков, заплатил им и они сделали приложение. Оно хорошо выглядит и интуитивно понятно, но водители не стали его устанавливать. Им просто не захотелось заморачиваться: удобнее искать места по старинке, а не открывать очередное приложение и скроллить бесконечную ленту с похожими вариантами.

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

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

При проектном подходе разработчики стараются выполнить все пожелания заказчика, чтобы клиент остался доволен. Чтобы он потом вспоминал, как ребята работали над проектом: соблюдали сроки, всегда были на связи, четко следовали техническому заданию, а менеджер всегда расплывался в улыбке при встрече. Программисты не заморачиваются с тем, как будет работать продукт, принесёт ли он заказчику прибыль и закроет ли боли клиентов. Это не их часть работы.

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

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

Например, вам нужно, чтобы пользователи вводили номер телефона в формате +7 (ХХХ) ХХХ-ХХ-ХХ. Так номер, который попадает в базу контактов, можно использовать для автоматических рассылок. Если пользователи будут вводить номера в других форматах, система их не идентифицирует — и рассылка не уйдёт. Это ваша задача. Но пользователям по большому счёту всё равно, как вводить цифры. Поэтому важно позаботиться о пользователях: помочь им делать так, как нужно вам, но при этом показать, что и для них это удобно. Хорошее решение — использовать маску ввода. Она исключает ввод данных в неверном формате, а пользователь видит в поле нужный формат телефона данных и вводит цифры в нем. Все довольны.

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

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

Проект — это что-то, растянутое во времени. Продукт — это результат. А результат в бизнесе важно достигать как можно быстрее.

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

При продуктовом подходе не нужно ждать, когда все будет идеально (в реальном мире так все равно не бывает). Вы можете сделать первую версию приложения с базовым функционалом и отдать его пользователям. Да, пока в приложении нельзя оплачивать заказы с помощью Apple Pay и оставлять чаевые курьеру. Зато оно выполняет главную функцию здесь и сейчас — продает ваш товар клиентам. Люди сейчас отдают вам деньги, а вы сейчас получаете доход и развиваете бизнес.

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

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

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

Допустим, вы делаете приложение для управления грузоперевозками, которым будут пользоваться водители грузовиков. Пока вы рисовали прототип, в России приняли закон о системе «Платон». Теперь все водители грузовиков тяжелее 12 тонн должны платить налог за пользование дорогами. И вы подумали: «Было бы здорово, чтобы водители могли оплачивать налог прямо в приложении. Так продукт будет еще полезнее». Вы рассказали об идее разработчикам, они добавили задачу в бэклог — список основных функций и характеристик продукта. Закончив один спринт, разработчики выбирают задачи для следующего спринта из бэклога: они могут поскорее добавить в приложение новую функцию.

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

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

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

Менеджер проекта — связующее звено между заказчиком и разработчиками. Он отвечает за планирование, контролирует выполнение задач и сроки, следит за бюджетом, улаживает проблемы и отвечает за конечный результат. Несмотря на правильные цели, на практике работа проектного менеджера зачастую сводится к тому, чтобы угождать заказчику, выполнять условия договора и вписываться в бюджет.

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

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

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