Уложитесь в мой дедлайн?
Oops! Something went wrong while submitting the form.
Представьте, что вы придумали приложение и хотите выйти с ним на рынок. В разработке программного обеспечения переходить к финальному релизу без тестирования нельзя — есть риск финансовых потерь. Поэтому нужно сначала разработать MVP, чтобы посмотреть, как продукт впишется в рынок. Но тратить деньги на MVP, который не выдержит конкуренции, тоже опасно.Чтобы снизить риски, не воплощайте идею сразу — начните с проверки концепции (proof of concept, POC). В статье расскажем о разработке программного обеспечения с проверкой концепции и дадим алгоритм проверки идей за 4 шага.
.webp)
Проверка концепции — исследование, которое вы проводите перед разработкой ПО, чтобы проверить его идею. Цель POC — доказать, что будущее приложение технически реализуемо и решает проблему пользователей. У POC нет общепринятого формата — вы можете сделать презентацию или файл PDF. Писать код вы начнёте только на этапе прототипирования. Но итоговый отчёт должен подробно описывать технические требования к проекту.
POC существует не только в разработке программного обеспечения. Например, режиссёры снимают короткометражные фильмы, чтобы показать основные темы, персонажей и технические приёмы, например, хромакей. Потом продюсеры смотрят эти фильмы и решают, стоит ли их расширять до полного метра. POC в киноиндустрии отличается от IT — но цели те же:
В отличие от MVP, в результате проверки концепции вы получаете не законченный продукт, а прототип — «черновик» продукта. Но важнее другое — POC даёт чёткое представление о проекте. И оно нужно не только вам. POC поможет привлечь инвестиции. Стейкхолдеры хотят увидеть, насколько реально заработать на вашем продукте. И если вы покажете им прототип и результаты исследования, шансы на сделку увеличатся.
Ещё POC позволяет обозначить возможные препятствия и предостеречь вас от:
Разработка программного обеспечения с проверкой концепции не только позволяет убедиться в реализуемости идеи, но и помогает выбрать лучшие решения для разработки.
Наконец, POC экономит время и деньги. Отсутствие потребности в продукте — одна из трёх причин почему стартапы закрываются. POC — не маркетинговое исследование, но тоже позволяет проверить, нужен ли ваш продукт людям.
Допустим, вы придумали приложение — нейросеть, которая пишет фоновую музыку для работы, учёбы и медитации. Вашим друзьям идея не нравится. Потенциальные инвесторы тоже могут не оценить. Чтобы доказать всем, что ваш проект принесёт деньги, вы решили проверить концепцию.
Это звучит как начало маркетингового исследования.Но в POC это нужно не для UX-дизайна или стратегий продвижения, а чтобы:
Один из способов сбора данных — глубинное интервью с потенциальными клиентами. Для нашего примера можно собрать фокус-группу людей, которые слушают фоновую музыку во время работы или учёбы, и задать им вопросы:
Это качественное исследование, поэтому много данных вам не нужно. Достаточно провести одно интервью с группой из 6–10 человек. Но можно споткнуться об отбор респондентов из-за конфаундеров — факторов, которые искажают данные и приводят к неверным заключениям. Например, не набирайте респондентов, которые не будут заинтересованы в результатах исследования — таких, как эта дама:
Но при этом берите в фокус-группу разных людей. Мужчины и женщины, зумеры и миллениалы, люди с разным культурным бэкграундом станут источниками разных мнений и ценных инсайтов. Помимо этого, нельзя проводить исследование в пользу одной социальной группы. Например, если вы не делаете приложение только для мужчин, однополая фокус-группа не будет репрезентативной. И такое исследование приведёт к волне негативных отзывов из-за сексистских текстов в интерфейсе.
Также учтите, что любой результат интервью ценен. Может оказаться, что людям не нужны плейлисты от нейросети — они довольны радио лоуфайного хип-хопа на Youtube. Поэтому POC и начинается с обозначения проблемы — если её нет, людям и продукт не нужен.
Но представим другой исход. Например, пользователи сказали, что от лоуфайного хип-хопа их клонит в сон. Или что они не могут слушать живые DJ-сеты, потому что отвлекаются на переходы между треками. А эти проблемы может решить ваша нейросеть — она будет генерировать плейлисты, которые не отвлекают и улучшают продуктивность. Если на этапе интервью вы нашли проблему, переходите к следующему шагу.
Кодить всё ещё не надо. На этой стадии вам нужно ответить на вопрос: Как вы решите проблему?
Во время интервью пользователи рассказали вам о проблеме. А решение — ваш продукт. На этом этапе подробно опишите будущее приложение, а именно:
Учтите, что вы пишете POC не для разработчиков, а для инвесторов. Главная цель проверки концепции — оценка реализуемости и описание технических подробностей. Но документ должен быть понятным человеку, который ничего не знает о разработке. Описывайте технические подробности без лишних деталей. Рассмотрим на примере с нейросетью-композитором фоновой музыки. В POC стоит включить эти детали:
Больше и не потребуется — текст POC должен быть подробным, но простым и понятным.
POC обозначает два вида критериев успеха: технический и экономический. Технические критерии подтверждают, что программа работает и решает проблему, как было задумано. Экономические критерии — это финансовые цели вашего проекта. Подробности зависят от проекта. Но все цели должны быть поставлены по методологии SMART:
Думайте цифрами. Успех в разработке мобильного приложения, технический или рыночный, можно описать метриками. На этом этапе у вас две задачи:
Используйте последний столбец в таблице выше в качестве референса. Но помните, что это только пример. Успех на рынке измеряется не только MAU и ROI, а технические критерии сложнее и зависят от проекта.
Прототип — модель будущего приложения. Это не MVP — пользоваться им нельзя и на рынок с ним не выйти. Прототип даёт общее представление о конечном продукте. Но это не единственное отличие:
Прототипы не нужны:
Но если вы собираете приложение с нуля,прототип вам нужен — в том числе для проверки инновационных решений. Не только для инвесторов — прототип позволит:
Прототип — только модель будущего продукта. Но насколько упрощённой будет эта модель, зависит от вас — только не переборщите:
Прототипы бывают lo-fi и hi-fi — рассмотрим их главные отличия:
Не всем проектам нужен рабочий прототип — для простых решений достаточно нарисовать основные экраны:
Но если вы работаете над сложным приложением и тестируете новые технологии, hi-fi прототип будет информативнее для пользователей и инвесторов. Это решение подойдёт и нашему примеру с нейросетью для фоновой музыки. Но перед прототипированием стоит учесть не только то, будет ли ваша модель хотя бы кликабельной.
Есть ещё одна классификация прототипов — по роли в процессе разработки:
Выбор зависит от сложности проекта. Инкрементные прототипы подходят для составных приложений, в которых несколько модулей. Быстрые прототипы — хороший выбор для технически простых проектов, для которых нужно протестировать только сценарии и дизайн. А эволюционные прототипы помогут проверить и показать сложные технологические решения, и станут фундаментом для дальнейшей разработки — это лучший вариант для нашего примера.
Теперь рассмотрим процесс прототипирования перед разработкой мобильного приложения.
Определение цели и главных фич. Для начала решите, модель чего вам нужна и зачем вашему проекту прототип. Например, вы хотите собрать фидбек, показать проект стейкхолдерам и перед разработкой мобильного приложения проверить, справляется ли архитектура LSTM с написанием музыки. Для этого вы собираете hi-fi прототип с короткими плейлистами генеративной музыки.
Бумажный прототип. Начните с наброска экранов, чтобы определиться с расположением элементов интерфейса. На этом этапе не думайте о деталях — вы сделаете это позже. Ваш набросок достаточно хорош, если он понятно показывает логику приложения.
Вайрфреймы. Перенесите набросок в Фигму или другую программу и добавьте детали. На этом этапе готов лоуфайный прототип — но нашему примеру его не хватит.
{{tg-banner}}
Кликабельный прототип. Добавьте интерактивные элементы — связи между экранами, анимации, состояния кнопок. Кликабельные вайрфреймы — тоже лоуфайный прототип. Но нашему примеру и этого недостаточно.
Разработка. Начните писать код, если вы делаете hi-fi прототип. Для проектов с искусственным интеллектом это сложнее — вам нужно показать, на что способна нейросеть. Поэтому в прототипе будет много деталей. Чтобы собрать приложение быстрее, используйте меньше данных для обучения и уменьшите выход — для демо-версии достаточно получасового плейлиста.
Фидбек и правки. После сборки прототипа покажите его фокус-группе потенциальных пользователей, запросите обратную связь и внесите правки. Например, на первом этапе тестирования пользователи пожаловались на неприятные цвета кнопок, непонятную логику и зависания в фоновом режиме. Вы решаете эти проблемы и показываете новую версию. Проведите прототип через несколько итераций правок.
Презентация. Наконец, покажите прототип потенциальным инвесторам вместе с результатами проверки концепции и обратной связью от пользователей. К документу POC нет единых требований — пишите в свободной форме, составьте презентацию или возьмите шаблон из любого источника. Но в нём всё равно должны быть все элементы, о которых мы говорили ранее.
Если проверка концепции показала, что приложение нужно пользователям и его можно разработать, вы разрабатываете MVP для тестирования фич и сбора данных о пользователях. На этом этапе вы смотрите, как продукт ведёт себя на рынке, и меняете дизайн и набор фич для улучшения метрик. А после теста — работаете над финальным релизом.
Проверка концепции важна для работы над уникальными решениями — но это долго. А на рынке инноваций время критично — к выпуску MVP идея продукта может устареть. Чтобы сократить время выхода на рынок, можно отдать разработку на аутсорс — и в этом вам поможет Purrweb.
За 3 месяца наша команда разработает MVP с красивым интерфейсом и основными фичами. Чтобы сэкономить время, мы собираем приложения на React Native — так вы покажете продукт более широкой аудитории. Мы ведём проекты от идеи до загрузки в магазины приложений. Но вы всё ещё сможете решить, будет ли в приложении экран с чатом.
Мы будем рады поработать с вами — оставьте свои контакты <a class="blog-modal_opener">в форме</a>, и мы сделаем оценку вашего проекта в течение 48 часов.
.svg)
