POC и пилот: как проверить концепцию до полноценной разработки

Как понять до большого бюджета, что идея технически осуществима, а продукт нужен людям? Для этого есть форматы проверки разной глубины: доказательство концепции, прототип, MVP (минимальная рабочая версия продукта) и пилот, и каждый отвечает на свой вопрос. Разберём, как выбрать формат под задачу и довести проверенную идею до разработки, сохранив выводы проверки.

11 сентября 2026 Разработка 13 мин чтения

---

Что такое POC простыми словами

POC (proof of concept, доказательство концепции) — короткая проверка одного вопроса: можно ли технически сделать задуманное и работает ли выбранный подход. В Википедии проверку концепции определяют как демонстрацию практической осуществимости метода, идеи или технологии. На выходе — ответ: «да», «нет» или «да, при условиях», подкреплённый работающим фрагментом и отчётом.

Проще говоря, POC снимает главный технический вопрос до того, как под идею собирают команду и бюджет. Распознает ли модель товар по фотографии покупателя? Отдаст ли учётная система остатки с нужной скоростью? Выдержит ли сервер поток заказов в распродажу? Такие вопросы дешевле закрыть на тестовом стенде (отдельной копии системы для экспериментов), чем обнаружить в середине разработки.

Три свойства хорошего POC:

• Один вопрос. Проверка отвечает на одну конкретную гипотезу.
• Ограничение по времени и бюджету. Срок и лимит часов фиксируют до старта, чтобы проверка не превратилась в разработку.
• Измеримый критерий. Заранее решено, какой результат считать успехом, а какой — поводом менять подход.

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

POC, прототип, MVP и пилот: какой вопрос закрывает каждый

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

Сроки в таблице — ориентир по нашему опыту; до 30 рабочих дней — срок первой версии MVP в нашей практике. Форматы не обязательно идут подряд. Для нового сервиса на основе ИИ логична цепочка «POC → MVP → пилот». Для типового интернет-магазина чаще начинают с MVP или с запуска на готовых модулях. Прототип встраивается в любую цепочку, когда главный вопрос — в интерфейсе. Чем MVP отличается от первой полноценной версии, разобрано в материале о MVP мобильного приложения, а зачем схемы экранов появляются до дизайна — в разборе о вайрфреймах.

Когда нужен POC, а когда можно начинать с MVP

POC оправдан там, где главный риск технический: если ответ «нельзя», остальной проект теряет смысл. Четыре типичные ситуации из нашей практики.

Новая технология в продукте

ИИ-ассистент, распознавание изображений, примерка одежды в дополненной реальности, голосовой поиск. Здесь заранее неизвестно, какого качества будет результат на ваших данных, и проверка отвечает на вопрос «достаточно ли точно работает модель» до того, как под неё проектируют интерфейс. Примеры таких задач — ИИ-агенты для бизнеса и AR-примерка в приложении магазина одежды. Мы и сами так проверяли, насколько ИИ ускоряет разработку: новостной агрегатор с персональной лентой был разработан за один день, ход эксперимента описан в отдельной статье.

Интеграция с унаследованной системой

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

Нагрузка и производительность

Распродажа, запуск рекламной кампании, тысячи одновременных заказов. Проверка показывает, где система упрётся в предел, раньше, чем это случится на живых покупателях. Инструменты — нагрузочное тестирование и архитектурный разбор; подробнее разбираем их в материале о высоконагруженных системах.

Согласование бюджета внутри компании

Руководству или инвестору проще выделить деньги под работающий фрагмент, чем под презентацию. POC превращает спор «получится или нет» в демонстрацию, после которой обсуждают уже объём и сроки.

Когда проверка концепции не нужна

Если задача уже решена на рынке типовыми средствами, проверять технически нечего. Каталог, корзина, оплата, личный кабинет, программа лояльности, push-уведомления — стандартные сценарии интернет-магазина. Главный вопрос здесь не «получится ли», а «придут ли покупатели», и отвечает на него MVP или пилот. Подробнее разбираем это в разделе про готовые модули.

Пилотный проект: проверка модели в реальных условиях

Пилот — запуск работающего продукта, в том числе MVP, на ограниченной части аудитории или бизнеса. Его видят реальные клиенты или сотрудники, и проверяется модель целиком: курьеры успевают, склад собирает заказы вовремя, поддержка отвечает, покупатели возвращаются.

Способы ограничить пилот:

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

Для мобильных приложений есть готовые механики закрытого запуска. TestFlight позволяет пригласить до 10 000 внешних тестировщиков версии для iOS, а в Google Play доступны внутреннее, закрытое и открытое тестирование: приложение видят только добавленные участники. Поведение участников пилота измеряют в системе аналитики, например в AppMetrica; какие показатели отслеживать, разобрано в материале про аналитику мобильного приложения.

Пилот заканчивается решением: масштабировать, доработать или сменить модель. Чтобы это решение не превратилось в спор, критерии фиксируют до старта и формулируют по одной схеме.

Как сформулировать гипотезу и критерии успеха

Проверка без критерия почти всегда заканчивается выводом «вроде работает». Чтобы этого не случилось, гипотезу записывают по формуле: «Мы считаем, что [решение] позволит [кому] [получить результат]. Мы узнаем это, если [показатель] достигнет [порога] за [срок]».

Три правила для критериев:

• Порог записан до старта. Задним числом любой результат легко объявить успехом.
• Есть порог остановки. Заранее известно, при каком результате подход меняют.
• Показатель измеряется доступными средствами. Если для замера нужна отдельная аналитика, её закладывают в объём проверки.

С этой работой помогает бизнес-аналитика IT-проектов: аналитик превращает идею в набор проверяемых утверждений. Когда продукт уже запущен, гипотезы об интерфейсе и сценариях удобно проверять через A/B-тестирование.

Как провести POC: шесть шагов

Порядок почти не зависит от технологии, меняется содержимое каждого шага.

Шаг 1. Вопрос и гипотеза

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

Шаг 2. Критерии, срок и лимит

Фиксируют показатель, пороги успеха и остановки, срок и лимит часов. На выходе — согласованные рамки проверки. Без лимита POC незаметно превращается в разработку продукта с неясным результатом.

Шаг 3. Минимальная реализация

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

Шаг 4. Проверка на реальных данных

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

Шаг 5. Отчёт и решение

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

Шаг 6. Перенос в разработку

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

Что делать после проверки: три исхода

Итог проверки — одно из трёх решений, и у каждого свой следующий шаг.

Концепция подтвердилась

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

Концепция подтвердилась частично

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

Концепция не подтвердилась

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

Готовые модули: когда проверять технически нечего

Большая часть функций интернет-магазина давно реализована в готовых решениях и технической проверки не требует. Каталог с фильтрами, корзина, оплата через эквайринг и СБП, личный кабинет, программа лояльности, push-уведомления, интеграции с 1С, маркетплейсами и службами доставки — стандартные сценарии.

Платформа FITTIN устроена как конструктор: эти сценарии уже есть в наборе готовых модулей, и любой из модулей можно доработать под уникальную механику бренда. Для такого проекта технический вопрос снят, и проверять нужно спрос и операционную модель — первой версией или запуском на ограниченной аудитории. Приложения под iOS и Android выпускаются из одной кодовой базы на Flutter, публикация — в App Store, Google Play, RuStore и других сторах по запросу.

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

Сколько стоит проверка концепции и пилот

У каждого формата своя модель расчёта, потому что объём у них предсказуем в разной степени.

• POC — оплата по часам с жёстким лимитом. Объём заранее известен не полностью, поэтому фиксируют потолок: срок и число часов, после которых команда останавливается и докладывает результат.
• MVP — стоимость и состав работ фиксируются после технического задания; ориентир опубликован на странице разработки MVP.
• Пилот — зависит от того, на чём работает продукт. Для запуска на платформе действует модель из трёх частей, она описана ниже.

Факторы, от которых зависит цена проверки

• Сложность вопроса. По нашему опыту, проверка обмена данными и проверка точности модели на тысячах фотографий заметно различаются по объёму.
• Данные. Есть ли готовые выгрузки или данные нужно собирать и размечать.
• Доступы. Насколько быстро команда получает доступ к системам и тестовым средам.
• Платные внешние сервисы. Модели ИИ и сторонние сервисы часто тарифицируют каждый запрос.
• Стенд. Нужна ли отдельная инфраструктура под проверку.
• Участие заказчика. Кто со стороны бизнеса даёт данные и принимает результат.
• Длительность пилота. Сколько циклов продаж или подписки нужно, чтобы результат стал показательным.

Как устроена цена запуска на платформе

Модель FITTIN состоит из трёх частей. Первое — единоразовая интеграция платформы под ваш бренд. Второе — ежемесячные лицензионные платежи, в которые уже включены затраты на техподдержку команды: мониторинг, обновления модулей и обновления безопасности. Третье — доработки нового функционала по Time & Materials со сметой и оценкой по часам перед стартом задачи.

Актуальные пакеты — на странице тарифов, там же опубликованы ставки по ролям для работ по часам. Про планирование денег на проект с инвестиционным циклом — в материале о том, как рассчитать бюджет стартап-проекта.

Как выбрать подрядчика для POC и пилота

Короткая проверка быстро показывает, как команда работает с неопределённостью. Семь пунктов, которые стоит проверить до договора.

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

Если своя команда разработки есть, но под проверку не хватает людей, специалистов можно подключить к ней — так работает аутстаффинг Flutter-разработчиков. Как заложить сроки и деньги на первую версию, разобрано в чек-листе бюджета и сроков разработки.

Кейсы: какой объём укладывается в короткий цикл

Три проекта показывают, какой объём укладывается в короткий цикл, когда состав работ зафиксирован, а технические вопросы сняты заранее. Цифры — со страниц кейсов.

Другие проекты — в разделе кейсов.

Итог: проверка концепции на одной странице

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

Материал подготовила федеральная команда FITTIN с центром разработки в Воронеже.

Что делать дальше:

• Идея есть, требований нет — разработка технического задания или бизнес-анализ требований.
• Главный вопрос в спросе — разработка MVP; ориентир по бюджету — калькулятор стоимости.
• Задача в e-commerce — приложение для интернет-магазина на готовых модулях; обсудить проверку нестандартной механики — контакты.

Часто задаваемые вопросы

Что такое POC простыми словами?

POC, или proof of concept, — короткая проверка одного вопроса: можно ли технически сделать задуманное и работает ли выбранный подход. Например, распознаёт ли модель товар по фотографии или отдаёт ли учётная система остатки с нужной скоростью. Результат — работающий фрагмент и отчёт с выводом «да», «нет» или «да, при условиях». Готовым продуктом POC не становится: его задача — снять главный технический вопрос до того, как под идею выделяют бюджет разработки.

Чем POC отличается от MVP?

Вопросом, на который отвечает каждый формат. POC проверяет, можно ли сделать задуманное технически; его видит команда проекта, а код обычно не переносится в продукт. MVP проверяет, нужен ли продукт людям: это первая версия с одним-двумя ключевыми сценариями, которую получают реальные пользователи, и её код становится основой продукта. Если главный риск технический, начинают с POC; если технология понятна, а неясен спрос, — сразу с MVP.

Что такое пилотный проект простыми словами?

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

Чем пилот отличается от MVP?

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

Сколько длится POC?

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

Сколько стоит POC?

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

Можно ли использовать код POC в готовом продукте?

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

Нужен ли POC перед разработкой приложения для интернет-магазина?

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

Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации.