PoC (Proof of Concept): когда он нужен и как поставить его так, чтобы он дал ответ

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

Ключевое слово — «рискованной». Если задача состоит из десяти понятных блоков и одного непонятного, проверять надо один. Делать PoC на то, что команда делала уже двадцать раз, — трата времени и бюджета, а такое встречается регулярно: подрядчику удобно продать короткий понятный этап, а заказчику кажется, что он снижает риск.

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

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

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

Правило простое: проверяют то, чего никто в команде не делал и о чём нельзя узнать чтением документации.

Это единственная часть, которую нельзя делегировать подрядчику целиком, и место, где проваливается большинство проверок. «Проверить, работает ли распознавание» — не критерий: работать оно будет, вопрос в том, насколько.

Рабочий критерий состоит из четырёх частей: метрика, порог, условия, данные. Например: не менее 92% точных совпадений номенклатуры при распознавании фотографий накладных, на выборке из 500 реальных документов от трёх разных поставщиков, при обработке одного документа не дольше трёх секунд.

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

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

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

Технической части в PoC обычно меньше, чем возни с данными. Типичные истории:

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

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

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

Данные врут. Справочники с дублями, поля, заполненные «на отвяжись», исторические записи по другим правилам. Обнаруживается это всегда в процессе, и иногда именно это и есть главный результат PoC: задача решаема, но сначала нужно привести данные в порядок.

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

Нормальная проверка ограничена по времени заранее — обычно двумя-шестью неделями. Ограничение не по объёму работ, а по календарю: это принципиально. Если срок истёк, а ответа нет, ответом считается «за это время подтвердить не удалось», и это тоже информация.

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

Отдельно про ожидания. В PoC нет обработки ошибок, нет прав доступа, нет масштабирования, нет тестов. Это не халтура, а осознанное сокращение: всё перечисленное не влияет на ответ по критерию, но занимает большую часть времени в настоящей разработке. Где в общем цикле разработки стоит такая проверка и что идёт после неё, разобрано в материале про этапы и жизненный цикл разработки.

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

Самая распространённая ловушка звучит безобидно: «раз оно уже работает, давайте просто допилим». Дальше в продукте оказывается код, написанный за две недели без обработки ошибок, без учёта прав, с захардкоженными путями к файлам и с прямыми запросами к базе, потому что так было быстрее.

Проблема даже не в качестве. Проблема в том, что PoC писался под другую задачу: доказать возможность на подготовленной выборке. Настоящая система должна работать на потоке, обрабатывать мусор, восстанавливаться после сбоя, отвечать на вопросы «почему такой результат» и жить годами. Это другая архитектура, а не тот же код с добавленными проверками.

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

Практический вывод для договорённостей: в задании стоит прямо написать, что результат проверки — знание и протокол, а не поставляемое программное обеспечение. Иначе через месяц начнётся разговор «мы же за это заплатили» — и он всегда неприятный.

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

Показательная цифра: по исследованию MIT Media Lab «The GenAI Divide: State of AI in Business 2025» — 300 с лишним публично раскрытых инициатив, 52 интервью, 153 опроса руководителей — 95% корпоративных пилотов на генеративном ИИ не дали измеримого эффекта на финансовый результат.

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

Что из этого следует для критерия. Кроме качества модели, в него закладывают эксплуатационные величины: стоимость одного запроса (при потоке в десятки тысяч обращений она определяет, окупается ли затея), время ответа, долю случаев с передачей человеку и то, что происходит при неверном ответе — насколько дорого он стоит и заметен ли вообще.

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

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

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

Защита от этого только одна — критерий с порогом, зафиксированный до начала. Когда есть число и есть порог, разговор занимает пять минут вместо двух совещаний.

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

Ориентиры по нашим проектам: ограниченная техническая проверка ложится в вилку технического консалтинга — 300–900 тыс. ₽, в зависимости от того, сколько данных нужно собрать и сколько внешних систем затронуть. Если сначала требуется разобраться в существующем контуре, аудит кода и архитектуры — 200–600 тыс. ₽.

Следующий этап после положительного ответа: минимальная работающая версия от 1 млн ₽, полноценная система под процесс от 1,7 млн ₽. Оценку делаем бесплатно — оценка проекта и состава работ по вашим вводным.

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

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

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

Поручить проверку тем, кто продаёт продолжение. Конфликт интересов здесь встроенный, и лечится он не доверием, а измеримым критерием и данными, которые проверяет заказчик. Формулировать порог должна сторона, которая платит.

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

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

Если задача пока описана словами «хотим автоматизировать» и рискованная часть даже не выделена, начинать стоит раньше — с концепции проекта: она превращает пожелание в перечень задач и рисков, из которых уже видно, что проверять.