Разработка программного обеспечения с проверкой концепции: как проверить идею приложения за 4 шага

Что такое POC в разработке программного обеспечения?

Проверка концепции — исследование, которое вы проводите перед разработкой ПО, чтобы проверить его идею. Цель POC — доказать, что будущее приложение технически реализуемо и решает проблему пользователей. У POC нет общепринятого формата — вы можете сделать презентацию или файл PDF. Писать код вы начнёте только на этапе прототипирования. Но итоговый отчёт должен подробно описывать технические требования к проекту. 

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

Зачем проверять концепцию, если можно просто разработать MVP?

В отличие от MVP, в результате проверки концепции вы получаете не законченный продукт, а прототип — «черновик» продукта. Но важнее другое — POC даёт чёткое представление о проекте. И оно нужно не только вам. POC поможет привлечь инвестиции. Стейкхолдеры хотят увидеть, насколько реально заработать на вашем продукте. И если вы покажете им прототип и результаты исследования, шансы на сделку увеличатся. 

Ещё POC позволяет обозначить возможные препятствия и предостеречь вас от:

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

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

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

Хорошо, а как проверить концепцию?

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

Определите, кому и зачем нужен продукт

Это звучит как начало маркетингового исследования.Но в POC это нужно не для UX-дизайна или стратегий продвижения, а чтобы:

• обозначить проблему;
• показать, что ваш продукт её решит.

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

• Почему вы слушаете музыку во время учёбы или работы? Она улучшает продуктивность?
• Какие плейлисты или сервисы вы используете? Что вам нравится в них? А что не нравится?
• Что вы думаете о генеративной музыке?

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

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

Также учтите, что любой результат интервью ценен. Может оказаться, что людям не нужны плейлисты от нейросети — они довольны радио лоуфайного хип-хопа на Youtube. Поэтому POC и начинается с обозначения проблемы — если её нет, людям и продукт не нужен. 

Но представим другой исход. Например, пользователи сказали, что от лоуфайного хип-хопа их клонит в сон. Или что они не могут слушать живые DJ-сеты, потому что отвлекаются на переходы между треками. А эти проблемы может решить ваша нейросеть — она будет генерировать плейлисты, которые не отвлекают и улучшают продуктивность. Если на этапе интервью вы нашли проблему, переходите к следующему шагу.

Опишите решение

Кодить всё ещё не надо. На этой стадии вам нужно ответить на вопрос: 

Как вы решите проблему?

Во время интервью пользователи рассказали вам о проблеме. А решение — ваш продукт. На этом этапе подробно опишите будущее приложение, а именно:

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

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

• архитектура нейросети — LSTM;
• обработка корпуса музыки для обучения с помощью Music21;
• нейросеть будет написана на Python;
• 3 корпуса по 3 млн минут музыки в одном из трёх жанров — эмбиент, инструментальный хип-хоп или хаус;
• приложение будет собрано на React Native;
• на разработку мобильного приложения уйдёт 3 года.

Больше и не потребуется — текст POC должен быть подробным, но простым и понятным.

Определите критерии успеха

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

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

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

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

Соберите прототип

Прототип — модель будущего приложения. Это не MVP — пользоваться им нельзя и на рынок с ним не выйти. Прототип даёт общее представление о конечном продукте. Но это не единственное отличие:

Прототипы не нужны:

• миграционным проектам (переход с нативной разработки на React Native);
• небольшим изменениям в готовом продукте;
• маленьким проектам, которые не требуют нескольких месяцев или лет разработки;
• типовым проектам с понятными требованиями.

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

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

Прототип — только модель будущего продукта. Но насколько упрощённой будет эта модель, зависит от вас — только не переборщите:

Прототипы бывают lo-fi и hi-fi — рассмотрим их главные отличия:

Не всем проектам нужен рабочий прототип — для простых решений достаточно нарисовать основные экраны:

Но если вы работаете над сложным приложением и тестируете новые технологии, hi-fi прототип будет информативнее для пользователей и инвесторов. Это решение подойдёт и нашему примеру с нейросетью для фоновой музыки. Но перед прототипированием стоит учесть не только то, будет ли ваша модель хотя бы кликабельной.

Есть ещё одна классификация прототипов — по роли в процессе разработки:

• Быстрые прототипы используются только для сбора обратной связи от пользователей и стейкхолдеров — в разработке они не нужны. Например, вы нарисовали в Фигме экраны с основными UI-элементами. После правок вы используете этот файл как референс, но частью MVP он не станет.
• Эволюционные прототипы — это небольшие приложения с основными фичами. После правок и презентации они «эволюционируют» до MVP — в прод пойдёт код из прототипа. Например, вы сделали приложение с одним экраном и дропдауном. На экране есть кнопка Play/Pause, а меню даёт выбор из трёх жанров фоновой музыки. После презентации вы дописываете тот же самый проект — добавляете другие экраны и функции.
• Инкрементные прототипы состоят из нескольких моделей, которые показывают разные части сложной системы. Например, вы работаете над приложением для редактирования фотографий. В нём слишком много функций. Для прототипа вы выбрали цветокоррекцию, эффекты и удаление красных глаз. Для каждой фичи вы написали по одному приложению. После правок вы объединяете три проекта и добавляете другие модули — например, коррекцию экспозиции и слои. 

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

Теперь рассмотрим процесс прототипирования перед разработкой мобильного приложения.

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

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

Вайрфреймы. Перенесите набросок в Фигму или другую программу и добавьте детали. На этом этапе готов лоуфайный прототип — но нашему примеру его не хватит. 

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

Разработка. Начните писать код, если вы делаете hi-fi прототип. Для проектов с искусственным интеллектом это сложнее — вам нужно показать, на что способна нейросеть. Поэтому в прототипе будет много деталей. Чтобы собрать приложение быстрее, используйте меньше данных для обучения и уменьшите выход — для демо-версии достаточно получасового плейлиста.

В сборке hi-fi прототипа самое сложное — решить, какие именно фичи нужно проверить. С этой проблемой столкнулась и команда Purrweb. Мы делали веб-приложение для автоматизации работы бормашины. Приложение генерирует 3D-модель зубов пациента на основе данных с камеры. И вместо ручной работы доктор рисует на модели траекторию движения бормашины. Это сложный проект и мы не могли включить все фичи в демо-версию. Прототипировали мы только интерфейс взаимодействия между врачом и 3D-моделью — это самая оригинальная фича приложения. Прототип должен быть достаточно понятным, чтобы люди увидели, как будет работать ваш продукт. Но при этом нельзя перегружать его фичами.

Георгий Путилов, 
менеджер проектов в Purrweb

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

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

А что дальше?

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

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

За 3 месяца наша команда разработает MVP с красивым интерфейсом и основными фичами. Чтобы сэкономить время, мы собираем приложения на React Native — так вы покажете продукт более широкой аудитории. Мы ведём проекты от идеи до загрузки в магазины приложений. Но вы всё ещё сможете решить, будет ли в приложении экран с чатом.

Мы будем рады поработать с вами — расскажите о своих идеях в форме ниже.