proof of concept что это такое

Почему никогда не стоит использовать Proof of Concept в продакшене

Никогда не встречал разработчика, не любящего создавать всевозможные proof of concept (POC). Возможность построить что-то новое с нуля, чтобы протестировать теорию/процесс/технологию… Сама мысль об этом вдохновляет меня.

Есть в них что-то, что стимулирует наше творческое мышление. Вероятно, это отсутствие всяческих ограничений. Может, быть, это просто восторг от разработки «с чистого листа». Как бы то ни было, разработчикам это нравится.

Частично привлекательность создания proof of concept заключается в широте способов их применения. Можно создать POC для чего угодно! Хотите ли вы создать что-то забавное, научить кого-то незнакомой концепции, придумать идею для бизнеса или научиться использовать новую технологию для решения проблемы — варианты просто бесчисленны.

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

Proof of concept — это именно концепция. Это не «рабочая лошадка» для продакшена, соответствующая всем рекомендациям, общепринятым шаблонам и процессам разработки. Это инструмент для демонстрации идеи за короткий промежуток времени.

Сегодня мы поговорим о четырёх причинах, по которым POC ни за что не должно попадать в продакшен.

Продакшен изменяет способ разработки

Один из удобных аспектов создания POC заключается в том, что вы не скованы привычными ограничениями разработки. Вы можете писать на любом языке, использовать «быстрые и грязные» решения, а также хардкодить.

Не важно, как вы реализуете результат, если в результате сможете доказать свою правоту.

Если бы вы предполагали, что POC будет использоваться в продакшене, то подходили бы к кодингу немного иначе. Вы бы выбирали другие архитектурные решения, намеренно использовали другие шаблоны и придирчивее обрабатывали бы ошибки. Иными словами, вы бы двигались медленнее.

БОльшую часть времени нужно тратить на реальный продукт, а не на POC, которое продаёт вашу идею владельцу продукта.

Proof of concept должно передать вашу идею за как можно более короткий промежуток времени.

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

Оно не предназначено для этого

Ваше POC создавалось, чтобы проиллюстрировать суть. Это идея. Она не создавалась с расчётом на нагрузки продакшена.

Перед ремонтом дома вы набрасываете свои идеи на листе бумаги, чтобы показать их друзьям, семье и рабочим. Все понимают, чего вы хотите, но этот черновик с каракулями явно не стоит отдавать строителям.

Нет, вы попросите составить чертёж в CAD, всё просчитать, найти несущие нагрузку конструкции и формализовать проект, прежде чем к нему приступать.

Ваше proof of concept — это набросок на листе. Он выполнил свою цель и продемонстрировал чёткое направление, но в продакшене вы использовать его точно не будете. Его нужно проработать, правильно спроектировать, разбить на истории и задокументировать.

Если команда разработки использует методологии agile, то этот процесс будет выглядеть примерно так:

Proof of Concept хрупки

Вы отлично справились. Вы создали POC, единственное назначение которого — демонстрация работающего примера новой концепции. Его создание почти не заняло времени, и вашему руководству оно понравилось. Отлично!

Как и можно было ожидать, владелец продукта просит вас просто вывести его в продакшен, потому что, по его мнению, у вас уже есть работающий продукт.

Но вы-то знаете правду.

В нём нет обработки ошибок. Вы создали ПО, которое будет работать в идеальных условиях. Как только вы отклонитесь от реализованного в коде процесса, он сломается.

На обзоре спринта вы не отклоняетесь от сценария демонстрации, и на то есть причины. Если вы нажмёте кнопку X вместо кнопки Y, всё развалится. Но это нормально! Вы создали именно то, что и должны были создать. Proof of concept продемонстрировало именно то, что и должно было показать.

Хотя подобные ситуации в продакшене считаются багами, в proof of concept они багами не являются. Помните, это просто черновик, а не готовый чертёж.

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

Во второй раз всегда получается лучше

Век живи — век учись. Практикуйся. В следующий раз повезёт.

Что общего у всех этих фраз?

Они подразумевают, что чем больше вы чем-то занимаетесь, тем лучше будут результаты.

Вы же не думаете, что спортсмены не тренируются перед соревнованиями? Конечно же, они тренируются, ожидая, что чем больше практикуешься, тем лучше проявишь себя.

Тот же принцип применим и к созданию ПО. Когда ты в первый раз что-то пишешь (например, POC), то находишься в фазе исследования. Изучаешь все аспекты, пытаясь собрать что-нибудь.

Во второй раз ты движешься быстрее, потому что узнал часть нюансов. Ты пишешь более производительный код, который проще поддерживать. Ты пишешь лучше.

Воспринимайте POC как поучительный урок. Проиллюстрируйте идею и научитесь кодировать концепцию. Найдите все подводные камни. Будьте готовы, что потом найдёте новые. Приготовьтесь к созданию более качественного ПО.

Заключение

Proof of concept всегда стоит потраченного на него времени. Даже если результат докажет, что вам не стоит использовать проверяемую концепцию, по крайней мере, вы не потратили на выяснение этого много времени.

POC дают нам шанс поэкспериментировать с чем-то новым и взвесить свои решения перед тем, как приступать к реализации. Но они не являются реализацией. Хотя иногда может возникать искушение встроить этот код в приложение в продакшене, не стоит этого делать.

Используйте proof of concept как отправную точку. Пользуйтесь его уроками как руководством, чтобы создать нечто лучшее. Ужесточите требования к тому, что вы сделали. А потом начинайте новую итерацию.

Не распыляйтесь при создании сборок POC. Создавайте их как можно быстрее. Тратьте максимально возможное время на работу над реальным ПО, обладающим безопасностью, устойчивостью к сбоям и надлежащей обработкой ошибок.

На правах рекламы

Серверы для разработчиков и не только! Недорогие VDS на базе новейших процессоров AMD EPYC и хранилища на основе NVMe дисков от Intel для размещения проектов любой сложности, создавайте собственную конфигурацию сервера в пару кликов!

Источник

Proof of Concept: Как проверить, что внедрение ML стоит свеч

Недавно в уютном чатике дата сатанистов подняли вопрос, как правильно «продавать» внутренние проекты по машинному обучению. Оказалось, что многие из нас весьма брезгливо относятся к экономическому обоснованию своей деятельности. Меж тем, чтобы провести минимальную оценку рентабельности проекта, никакого MBA не нужно — в небольшой статье (10 страниц текста, ке-ке-ке) я расскажу вам, что такое рентабельность инвестиций, как оценить её для внутреннего проекта, какую роль в этом играет Proof of Concept, и почему в реальной жизни всё может пойти не так. Делать мы всё это будем вокруг вымышленного проекта по автоматизации составления расписаний для колл-центра. Добро пожаловать под кат!

Наш вымышленный проект

В колл-центре работает 100 операторов. Они работают по плавающему расписанию, выходя на работу сменами по 8 или 12 часов. Смены начинаются в разное время и расставлены так, чтобы обеспечивать дежурство множества людей в часы пик и малого количества людей в холодные часы по ночам и выходным. Расписание планирует дежурный супервайзер колл-центра темными пятничными вечерами, на глазок планируя нагрузку на следующую неделю.

Один 8-часовой день работы оператора колл-центра стоит компании 2.000 руб. Если считать, что в году 250 рабочих дней, то колл-центр обходится компании в 100 х 2.000 х 250 = 50 млн руб в год. Если мы автоматизируем составление расписания, мы сможем прогнозировать почасовую нагрузку и расставлять смены так, чтобы варьировать число дежурных операторов в зависимости от прогнозной нагрузки. Если наш прогноз и расстановка смен окажется хотя бы на 10% лучше, чем прогноз и расстановка супервайзера, получится экономия аж 5 млн руб. в год. Если нам действительно удастся выжать 10% улучшения, проект однозначно окупится. Или нет. Давайте подумаем, как вообще принимать такие решения.

Как считают ROI

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

ROI (Return on Investment) — это показатель доходности проекта, равный отношению доходов к затраченным инвестициям. ROI ¯\_(ツ)_/¯ ). Картинка оттуда же — на ней пример прогноза нагрузки.

Для начала, нам удалось предсказывать почасовую нагрузку с WAPE = 14%. Удалось достичь ошибки меньше 10% на 43% часов, меньше 20% на 70% часов.
Вообще, это очень неплохо — мы достаточно точно ловим и суточные колебания, и недельные циклы, и среднесрочные тренды. Обжигаемся только на случайных флуктуациях, и, скорее всего, избежать их не удастся.

По нагрузке мы сможем легко вычислить число операторов, которые должны быть в смене в данный час. Мы написали жадный неоптимальный алгоритм планировщика смен и вычислили, что что нам удается сэкономить 10% смен на прогнозной нагрузке. При этом оказалось, что если мы в дополнение к 12-часовым сменам введем 8-часовые и умно расставим их по суткам, можем сэкономить еще 5%.

Переводим показатели в деньги. Текущая стоимость годового содержания колл-центра — 50 млн руб в год. Наш эксперимент показал, что мы можем уменьшить эту сумму на 15%, что приведет к экономии до 7,5 млн руб в год, а за весь срок жизни — до 22,5 млн руб.

Это очень хороший эффект, и так и хочется признать PoC успешным. Давайте, однако, задержимся и проанализируем, что может пойти не так.

Риски, влияющие на экономический эффект

Мы получили положительный эффект за счет сокращения числа сотрудников. Число сотрудников мы смогли сократить за счет сокращения числа смен. Число смен мы смогли сократить за счет перераспределения их по предсказанной нагрузке. Нагрузку мы смогли предсказывать с помощью моделирования на основе исторических данных.

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

Во-вторых, мы предсказали нагрузку достаточно точно, но, тем не менее, в 30% случаев ошибаемся больше, чем на 20%. Может оказаться, что такая ошибка в час пик приводит к недопустимому росту длительности ожидания. Супервайзеры примут решение закладывать резервные смены для покрытия рисков.

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

Итого, нам нужно заложить резервные смены в часы пик и поддерживать немного «балласта» в тихие недели. А кроме того, нам нужно будет заложить расходы на поддержание модели.
Настало время поговорить о расходах и рисках, с ними связанных.

Разработка и сопровождение, их стоимость и риски

По ходу проведения PoC нам стало понятно, что нужно делать для промышленной реализации решения.

Во-первых, нужно выстроить стабильно работающий процесс сбора данных. Оказалось, что мы достаточно легко можем получать данные из CRM. Однако, данные о расписании операторов мы были вынуждены собирать по крупицам. Значит, нам придется сначала сделать автоматизированную систему контроля расписаний операторов. Удачное совпадение, что результаты планирования мы тоже будем выгружать в эту систему. Мы оценили, что на разработку выгрузки из CRM у нас уйдет неделя-две. Разработка системы для управления расписанием потребует месяца два, и есть риск, что мы ошиблись в оценке в разы.

Во-вторых, нам нужно закодить сервис, применяющий модель для прогноза нагрузки, а потом закодить алгоритм, составляющий расписание под эту нагрузку. Саму модель мы уже обучили, как ее применять, примерно понятно — мы сможем упаковать ее в сервис примерно за неделю, максимум две. С алгоритмом составления расписаний сложнее, к тому же, мы можем погрязнуть в реализации ограничений или не смочь обойти комбинаторную сложность. Разработка алгоритма займет у нас от пары недель до двух-трех месяцев — неопределенность высока.

В-третьих, для работы всего этого потребуется инфраструктура — сервера приложений, базы, балансировщики и мониторинг. Как хорошо, что мы делаем это не в первый раз и знаем, что это займет где-то неделю. Если накосячим с оборудованием, то две. Сопровождение инфраструктуры будет занимать у нас от силы один-два человеко-дня в месяц, пфффф. Но за три года набежит до пары полных месяцев, ой. Кроме того, надо заложить дообучение и перевыкладку модели раз в полгода — итого 2-5 раз, каждый раз по 3-5 дней.

Просуммируем расходы в оптимистичном, реалистичном и пессимистичном вариантах.

Пусть средний разработчик обходится компании в 20 тыс. руб. в день.

Оптимистичный — 5 дней на CRM, 40 дней на систему управления расписанием, 5 дней на прогнозирование, 10 дней на составление расписаний, 5 дней на инфраструктуру, 3х12х0,5 дней на ее поддержку, и 2х3 дней на редкие дообучения модели. Итого 65 рабочих дня на разработку, 24 дня на поддержку. Итоговая стоимость решения — 1,3 млн руб на разработку + 0,48 млн руб на поддержку за 3 года.

Реалистичный — 10 + 60 + 10 + 20 + 10 + 3х12х1 + 5х3 = 110 разработки и 51 поддержки, 2,2 + 1,02 млн руб.

Пессимистичный — это когда все пошло не так. 20 + 80 + 20 + 40 + 10 + 3х12х2 + 5х5 = 170 разработки и 97 поддержки, 3,4 + 1,94 млн руб.

Отметим, что около 40% стоимости уходит на поддержку, как ни крути.

Оценка ROI и целесообразности проекта

При оптимистичной оценке мы получали 15% экономию на рабочей силе, что приводило нас к экономии 22,5 млн руб за срок жизни проекта, из которых 7,5 млн руб сваливалось на нас в первый год. Оптимистичная оценка расходов показывала всего 1,3 + 0,48 млн руб, что дает +6,2 млн (+377% ROI) в первый год и +21 млн руб (+1160% ROI) за время жизни. Божественно.

Однако, если реализуется хотя бы часть рисков, ситуация изменится. Если окажется, что на часы пик выпадает 50% смен, и мы захотим поддерживать 10%-ный резерв, мы тут же потеряем 5% эффекта. Еще 2,5% расходов на неэластичность штата — и вот мы потеряли в сумме 7,5% из 15% эффекта. Получаем всего 3,75 млн руб доходов в год, 11,25 млн за срок жизни. Это реалистичная оценка доходов.

Вычтем из этого расходы по реалистичной оценке — 2,2 млн на разработку и 1,02 на поддержку. Получим +55% ROI в первый год, +252% за срок жизни. Результат все равно достойный, но вывод о внедрении выглядит уже не таким однозначным.

Теперь давайте перестрахуемся и добавим 20%-ный резерв в часы пик. Мы потеряли еще 5% эффекта, осталось всего 2,5% сокращения расходов, или 1,25 млн в год, 3,75 млн за срок жизни. Это пессимистичная оценка эффекта, но эффект всё ещё хотя бы есть. Теперь при реалистичной оценке расходов проект не окупается в первый год, и только на горизонте в 3 года немного выходит в +17% ROI. Кажется, положить деньги на депозит выглядит надёжнее. Таким образом, при реалистичной оценке доходов и расходов мы уже не можем себе позволить 20%-ную перестраховку.

При реализации пессимистичного сценария разработки расходы составят 3,4 млн руб в первый год. Приемлемый ROI +121% мы получим только в самом радужном случае. На горизонте 3х лет также окупится с +108% ROI «средний» по доходам сценарий.

Таким образом, видно, что реалистично ждать от проекта ROI +55% в первый год и +252% за все время жизни, однако, мы будем вынуждены сильно ограничивать себя в резервах. И если мы не уверены в компетенциях собственной разработки, то проект лучше вообще не начинать.

P.S. Делать свое или купить готовое

Живой менеджер изучил бы альтернативные решения еще до внедрения PoC, но у нас же умозрительный проект, да? К тому же, про сторонние закрытые решения статью не напишешь.

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

Решения от вендоров биллятся, исходя из стоимости аренды рабочего места. По нашей «реалистичной» оценке дохода в 7,5%, мы экономим на одном рабочем месте 37,5 тыс. руб в год. Это и есть максимальная стоимость решения. Если решение стоит дешевле — оно принесет положительный ROI. С собственной разработкой все сложнее — окупаемость зависит от числа операторов. За первый год положительный ROI возможен при расходах на операторов в 26,66 млн в год, что достигается при 53 операторах. За три года положительный ROI начинается от 27 операторов.

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

Источник

Эти совместные испытания направлены на проверку осуществимости бизнес-концепций и предложений для решения бизнес-задач и ускорения достижения бизнес-инноваций.

СОДЕРЖАНИЕ

История использования

Этот термин используется с 1967 года. В 1969 году на слушаниях Комитета по науке и астронавтике, Подкомитета по передовым исследованиям и технологиям, доказательство концепции было определено следующим образом:

Правление определило доказательство концепции как этап разработки, на котором создается и тестируется экспериментальное оборудование для изучения и демонстрации осуществимости новой концепции.

Одно определение термина «доказательство концепции» было дано Брюсом Карстеном в контексте «прототипа доказательства концепции» в его журнальной колонке «Уголок Карстена» (1989):

В столбце также приведены определения связанных, но различных терминов « макет » (термин, используемый с 1940 г.), « прототип », «инженерный прототип» и « доска ».

Примеры

Кинопроизводство

Инженерное дело

Развитие бизнеса

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

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

Безопасность

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

В разработке программного обеспечения термин «доказательство концепции» часто характеризует несколько отдельных процессов с разными целями и ролями участников: бизнес-роли поставщика могут использовать доказательство концепции, чтобы установить, удовлетворяет ли система тому или иному аспекту цели, для которой она была разработана. Когда поставщик удовлетворен, разрабатывается прототип, который затем используется для поиска финансирования или демонстрации потенциальным клиентам.

Ключевые преимущества проверки концепции при разработке программного обеспечения:

Пилотный проект относится к начальному выкатным системы в производство, ориентация на ограниченный объем предполагаемого конечного раствора. Объем может быть ограничен количеством пользователей, которые могут получить доступ к системе, затронутыми бизнес-процессами, вовлеченными деловыми партнерами или другими ограничениями, соответствующими домену. Целью пилотного проекта является тестирование, часто в производственной среде.

Разработка лекарств

Фаза I обычно проводится с небольшим количеством здоровых добровольцев, которым вводятся однократные дозы или короткие курсы лечения (например, до 2 недель). Исследования на этом этапе направлены на то, чтобы показать, что новое лекарство обладает некоторой желаемой клинической активностью (например, что экспериментальный антигипертензивный препарат действительно оказывает некоторое влияние на снижение артериального давления), что его можно переносить при введении людям и дать рекомендации относительно уровней доз, которые заслуживают дальнейшего изучения. Другие исследования фазы I направлены на изучение того, как новый препарат абсорбируется, распределяется, метаболизируется и выводится из организма (исследования ADME).

Фаза IIA обычно проводится у 100 пациентов с интересующим заболеванием. Исследования на этой фазе направлены на то, чтобы показать, что новое лекарство обладает полезным количеством желаемой клинической активности (например, что экспериментальное антигипертензивное лекарство снижает кровяное давление на полезную величину), что его можно переносить при введении людям в в долгосрочной перспективе и выяснить, какие уровни доз могут быть наиболее подходящими для возможного маркетинга.

На этом этапе принимается решение о том, продвигать ли лекарство к более поздней разработке или от него следует отказаться. Если прием препарата будет продолжен, он перейдет к более поздним стадиям клинических исследований, названным Фазой IIB и Фазой III.

На этом этапе принимается решение относительно того, является ли препарат эффективным и безопасным, и если да, то в регулирующие органы (например, Управление по санитарному надзору за качеством пищевых продуктов и медикаментов США ( FDA) и Европейское агентство по лекарственным средствам) подается заявка на получение разрешения на прием препарата. продаваться для использования вне клинических испытаний.

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

Источник

Proof of concept что это такое

Перед началом реализации идеи, многие люди по-разному называют предполагаемый результат. Наиболее часто встречающиеся термины в этом случае: MVP ( minimum viable product ), POC ( proof-of-concept ), Prototype.

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

MVP

Minimum viable product — версия продукта, которая имеет минимальный набор функций исключительно для реализации бизнес-цели, сохраняя при этом жизнеспособность. Другими словами, она не содержит кучи интересных “фич” и красивого интерфейса. Такое решение имеет смысл использовать при работе со стартапами для того, чтобы вывести продукт на рынок и выяснить, будет ли он вообще пользоваться спросом. Таким образом, если спрос появился, то смысл дальнейшей работы есть и можно пробовать получить деньги с первых инвесторов на развитие продукта в будущем. Естественно, в свете того, что MVP отправляется прямиком на рынок, это должна быть стабильно работающая без ошибок версия ПО.

POC

Так называемое подтверждение концепта ( proof of concept ). В отличие от MVP, это маленький проект, созданный для проверки критически важных гипотез перед началом полноценной разработки. Например, POC создается для того, чтобы проверить, можно ли вообще реализовать какую-либо функцию или, если нет уверенности, что идея сработает. Подтверждение концепции охватывает не всю систему, а лишь небольшую её часть, которую пользователи могут и вообще не увидеть, потому что чаще всего POC используются внутри компании для уточнения пути развития продукта. Грубо говоря, POC — это небольшое исследование, которое дает зеленый (или красный) свет для дальнейшей работы, будь то начало нового проекта или развитие существующего. Бывают и случаи, когда POC используется вместо MVP для получения финансирования.

Prototype

И последнее, но не менее важное определение в нашем обзоре — прототип (Prototype). Основная цель создания прототипа — помочь принять решение о разработке продукта и уменьшить количество ошибок в нем. Прототип — это рабочая модель нескольких аспектов продукта (в отличие от POC, где чаще реализовывается одна функция). Чаще всего прототипирование используется для демонстрации какой-либо части системы, обнаружения ошибок в ней, опроса пользователей. С помощью прототипа, команда проверяет дизайн продукта, удобство использования, а зачастую и функциональность, чего никак не сделаешь, используя POC. Если говорить проще, прототип больше похож на драфт — т.е. своего рода черновой набросок, который еще требует много доработок, но при этом показывается конечным пользователям для того, чтобы услышать их мнение в целом о полученном результате. Важно отметить, что прототипы часто используются для реализации каких-то свежих идей и впоследствии вполне могут перерасти в MVP.

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

В итоге хочется отметить, что хотя MVP, POC и Prototype имеют много общего, но все же у них разные цели. А также то, что в ходе работы POC может перерасти в прототип или MVP или наоборот. В итоге только вам решать, каким именно путем идти.

В своей работе со стартапами мы чаще всего имели дело с MVP, которому могли предшествовать POC и/или Prototype.

Источник