Назад

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

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

Чтобы снизить риски, не воплощайте идею сразу — начните с проверки концепции (proof of concept, POC). В статье расскажем о разработке программного обеспечения с проверкой концепции и дадим алгоритм проверки идей за 4 шага.

Время чтения: 9 минут

разработка программного обеспечения с проверкой концепции
Содержание

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

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

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

разработка программного обеспечения с проверкой концепции

Давайте начнем создавать ваше приложение с проверкой концепции уже сегодня!
Мы будем рады услышать ваши идеи. Свяжитесь с нами и получите бесплатную оценку проекта в течение 48 часов.
Начать

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

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

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

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

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

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

разработка программного обеспечения с проверкой концепции

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

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

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

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

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

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

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

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

разработка программного обеспечения с проверкой концепции

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

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

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

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

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

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

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

  • метод решения проблемы;
  • пользовательские сценарии;
  • архитектура;
  • стэк — языки, фреймворки, типы данных и т. д.;
  • необходимые ресурсы и примерное время разработки.
ЧИТАЙТЕ ТАКЖЕ  Разработка на React Native для «узких» задач. Кейс Purrweb

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

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

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

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

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

Параметры Плохо Что не так Хорошо
Конкретные (Specific) Приложение работает. А как вы поймёте, что приложение работает? Нейросеть на основе архитектуры LSTM генерирует до 24 часов фоновой музыки без оверфиттинга. Во время сбора обратной связи пользователи в среднем оценивают выход нейросети не более чем на 3 балла из 10 по шкалам «раздражающая», «отвлекающая» или «вызывающая эффект зловещей долины».
Измеримые (Measurable) Людям нравится приложение.

Приложение приносит деньги.

У репутации и экономики приложения есть метрики. Средняя оценка на Google Play равна 4.0 и выше.

Показатель ROI — 6%.

Достижимые (Achievable) Мы выпустим конечный продукт через месяц после POC. Это реалистично только для зерокодинга. Мы два года учим нейросеть, потом разрабатываем MVP за 3 месяца, и доводим продукт до финального релиза за полгода.
Релевантные (Relevant) А ещё мы выпускаем приложение для знакомств. Эта цель не имеет отношения к проекту, для которого вы пишете POC. Мы выпускаем финальный продукт, если тестирование MVP пройдёт успешно.
Ограниченные во времени (Timely) Мы достигнем 3000 активных пользователей в месяц (MAU). Нет дедлайна. Мы достигнем 3000 MAU к третьему кварталу 2024 года.

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

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

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

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

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

Прототип MVP
Тестирует концепт продукта Тестирует продукт и фичи
Может быть интерактивным, но обычно им нельзя пользоваться Можно пользоваться, но функции только базовые
Сделан для инвесторов Сделан для инвесторов и изучения поведения пользователей
Основа для MVP Основа для конечного продукта

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

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

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

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

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

разработка программного обеспечения с проверкой концепции

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

 

Lo-fi прототипы Hi-fi прототипы
Неинтерактивные Интерактивные
Делаем в Фигме или с помощью инструментов для прототипирования — например, Justinmind Пишем код для базовых фич
Показывают логику приложения, user flow и дизайн Показывают решение проблемы в подробностях

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

разработка программного обеспечения с проверкой концепции

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

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

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

разработка программного обеспечения с проверкой концепции

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

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

разработка программного обеспечения с проверкой концепции

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

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

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

Инсайты из мира разработки и экспертный взгляд на цифровые продукты в нашем Telegram-канале Стартап-пикап.

Подписаться

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

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

Георгий Путилов,

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

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

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

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

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

А что дальше?

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

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

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

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

Насколько публикация полезна?

Оцени эту статью!

25 оценок, среднее 4.5 из 5.

Оценок пока нет. Поставьте оценку первым.

Так как вы нашли эту публикацию полезной...

Подписывайтесь на нас в соцсетях!

Share