Что такое 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:
Параметры | Плохо | Что не так | Хорошо |
Конкретные (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-моделью — это самая оригинальная фича приложения. Прототип должен быть достаточно понятным, чтобы люди увидели, как будет работать ваш продукт. Но при этом нельзя перегружать его фичами.
Фидбек и правки. После сборки прототипа покажите его фокус-группе потенциальных пользователей, запросите обратную связь и внесите правки. Например, на первом этапе тестирования пользователи пожаловались на неприятные цвета кнопок, непонятную логику и зависания в фоновом режиме. Вы решаете эти проблемы и показываете новую версию. Проведите прототип через несколько итераций правок.
Презентация. Наконец, покажите прототип потенциальным инвесторам вместе с результатами проверки концепции и обратной связью от пользователей. К документу POC нет единых требований — пишите в свободной форме, составьте презентацию или возьмите шаблон из любого источника. Но в нём всё равно должны быть все элементы, о которых мы говорили ранее.
А что дальше?
Если проверка концепции показала, что приложение нужно пользователям и его можно разработать, вы разрабатываете MVP для тестирования фич и сбора данных о пользователях. На этом этапе вы смотрите, как продукт ведёт себя на рынке, и меняете дизайн и набор фич для улучшения метрик. А после теста — работаете над финальным релизом.
Проверка концепции важна для работы над уникальными решениями — но это долго. А на рынке инноваций время критично — к выпуску MVP идея продукта может устареть. Чтобы сократить время выхода на рынок, можно отдать разработку на аутсорс — и в этом вам поможет Purrweb.
За 3 месяца наша команда разработает MVP с красивым интерфейсом и основными фичами. Чтобы сэкономить время, мы собираем приложения на React Native — так вы покажете продукт более широкой аудитории. Мы ведём проекты от идеи до загрузки в магазины приложений. Но вы всё ещё сможете решить, будет ли в приложении экран с чатом.
Мы будем рады поработать с вами — расскажите о своих идеях в форме ниже.
[wpim]