Назад

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • метод решения проблемы;
    • пользовательские сценарии;
    • архитектура;
    • стэк — языки, фреймворки, типы данных и т. д.;
    • необходимые ресурсы и примерное время разработки.
    READ MORE  Разработка на 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 прототип с короткими плейлистами генеративной музыки. 

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

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

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

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

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

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

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

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

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

    READ MORE  Оффшорная разработка ПО: что скрывают Google и Microsoft

    А что дальше?

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

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

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

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

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

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

    23 оценок, среднее 4.4 из 5.

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

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

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

    Share