Критерии провала пилотного проекта: почему их видно до старта
Модель может отвечать разумно, а итог пилота всё равно окажется нечем объявить: прогон шёл на примерах, отобранных исполнителем, запускал его инженер исполнителя на своём стенде, а сотрудник, ради которого всё затевалось, увидел систему в день приёмки. Ни одно из этих условий не про качество нейросети, и ни одно не выясняется по ходу — все они известны в день постановки задачи.
Отсюда деление между двумя разными записями. Одна — про содержание работы: что именно система должна делать, какой величиной это меряется и при каком её значении итог считается неудачным. Она делается до старта и подписывается обеими сторонами, иначе на приёмке спорят не о том, прошло число порог, а о том, каким этому порогу быть. Как формулировать задачу, метрику и порог так, чтобы результат нельзя было перетолковать, разобрано отдельно: когда AI-пилот считать неудачным. Вторая запись — про устройство самой проверки, и она здесь. Порог она не заменяет: цифра, снятая на приёмке, ничего не значит, пока не названо, чья это выборка, чьи руки и чей сервер. Что вообще стоит брать в пилот и на чём спотыкаются внедрения — тоже отдельный разговор: как внедрить нейросеть в бизнес.
Чек-лист приёмки: семь пунктов и что считается провалом
Пункты проверяются на самой приёмке, а согласуются до старта. Третья колонка — это и есть критерий провала: она написана так, чтобы ответ «не прошло» не требовал обсуждения.
| Пункт приёмки | Как проверяется | Что считается провалом |
|---|---|---|
| Выборка | Прогон идёт на данных, которые собрала ваша сторона и не показывала до настройки | Результат показан на примерах, отобранных исполнителем |
| Руки | На приёмке работает ваш сотрудник — тот, кто будет работать с системой дальше | Без инженера исполнителя запуск не воспроизводится |
| Контур | Прогон идёт там, где система будет жить: ваш сервер, ваши доступы | Приёмка на стенде исполнителя, перенос отложен на «потом» |
| Отказ | Видно, где система не взялась за случай и куда этот случай ушёл дальше | Отказов не видно: поток выглядит обработанным целиком |
| База сравнения | Тот же кусок потока прошли и прежним способом — есть с чем сравнить | Сравнивать не с чем: как было раньше, никто не замерял |
| Повторный прогон | Ту же выборку прогоняют второй раз, расхождение между прогонами записывают | Прогон был один, устойчивость результата неизвестна |
| Остаток | Выгрузка, разметка и журнал отказов остаются у вас независимо от итога | Материал пилота живёт только у исполнителя |
Три пункта, которые нельзя проверить задним числом
Отказ — это результат, а не пропуск
Система, которая на сомнительном случае останавливается и передаёт его человеку, ведёт себя правильно — но только если этот случай виден и у него есть адресат. На приёмке отказ проверяется не разговором, а списком: какие случаи ушли человеку и кто их принял. Провал здесь — когда отказ молча превращается в ответ. Задним числом это не восстановить: молчаливый отказ следа не оставляет — в отчёте случай числится наравне с остальными, и по итоговой выгрузке уже не отделить разобранное от пропущенного. Список отказов либо ведётся во время прогона, либо его не из чего собрать. Само правило — нет ответа в материалах, вопрос уходит человеку, а не додумывается — описано в статье про чат-бота, который не выдумывает ответы.
База сравнения снимается до пилота, а не после
Ответ на вопрос «стало лучше или нет» складывается из пары замеров. Если прежний порядок работы не замерили до начала, то после окончания замерять уже нечего: люди привыкли к новому, а старый процесс параллельно никто не вёл. Поэтому кусок потока на время пилота проходят двумя путями сразу. Близкий режим — когда система готовит черновик, а сотрудник проверяет и правит — описан в статье про автоматизацию бизнес-процессов нейросетью; он даёт контроль, но базу сравнения всё равно приходится снимать отдельно и заранее.
Повторный прогон — самый дешёвый пункт списка
Он не требует ни новой настройки, ни новых данных: ту же выборку прогоняют ещё раз и смотрят, совпал ли вывод. Расхождение между двумя прогонами — такая же часть результата, как сам результат: оно показывает, на что можно опереться при решении, а что придётся перепроверять каждый раз. В списке этот пункт стоит потому, что после приёмки его уже не сделать — выборка разойдётся, настройки поменяются.
Как пункт списка превращается в критерий провала
В протоколе у каждой строки четыре части. Без последней это не критерий, а пожелание.
- •Условие — что должно произойти: «прогон на отложенной выборке проведён вашим сотрудником»,
- •Способ проверки — чем это подтверждается: выгрузка с датой, журнал запусков, подпись под протоколом,
- •Дата — назначена до начала работ и не двигается молча,
- •Последствие — что попадает в протокол, если условие не выполнено: пункт помечен непройденным, названа причина, и тут же сказано, повторяется прогон или приёмка закрывается без этого пункта.
Пункт, на который в день постановки задачи ответа нет, — это уже сработавший критерий провала. Его либо снимают из списка явно и с объяснением, либо признают условием остановки: выборку не собрали — пилот не начали. Протокол приёмки отвечает только на вопрос, прошёл пункт или нет. Как стороны расходятся после ответа «нет» — кто объявляет остановку, как считается сделанное и что передаётся заказчику — это уже предмет договора, и он разобран отдельно: точка останова проекта.
Когда пункт снимают
Список не универсален, и снятый пункт — нормальная ситуация, если это сделано открыто и до старта.
- •Система по договорённости работает на стороне исполнителя — пункт про контур снимается, но его место занимает вопрос о доступе и о том, что будет с работой, если доступ пропадёт,
- •Процесс новый, истории по нему нет — отложенную выборку взять неоткуда. Тогда предметом пилота становится сбор данных, и так и записывают, а не подменяют демонстрацией,
- •Прежнего порядка не существовало вовсе, работа просто не делалась — базу сравнения снимают, а вместо неё считают, сколько случаев дошло до конца без участия человека.
Снятый пункт перестаёт быть критерием провала. Именно поэтому снимать его нужно до старта, а не на приёмке, когда он не прошёл.
Два файла, которые появляются только на приёмке
Пункт про отказ и пункт про повторный прогон отличаются от остальных тем, что не просто дают отметку «прошло или нет», а производят файл, которого до приёмки не существовало. Журнал отказов — перечень случаев, за которые система не взялась, с адресатом каждого: по нему видно, какие места процесса остаются людям, принят пилот или нет. Запись двух прогонов на одной выборке — это расхождение между ними: где на вывод можно опереться сразу, а где его придётся перепроверять руками. Ни тот, ни другой файл не собирается задним числом и не заменяется словами на встрече, поэтому оба пункта и стоят в списке до старта.
Сам список из семи пунктов — это развёрнутый ответ на один из вопросов, которые мы предлагаем задавать любому подрядчику: при каких условиях вы сами скажете, что затея не взлетела. Он и остальные вопросы того же списка, а заодно и состав того, что передаётся заказчику, — от исходников и среды сборки до выгрузки данных в открытом формате — собраны в разделе что мы делаем и что остаётся у вас.
Частые вопросы
Чем приёмка пилота отличается от демонстрации?
Демонстрация отвечает на вопрос, умеет ли система делать заявленное, и готовит её исполнитель. Приёмка отвечает на другой вопрос: выдержит ли она ваш поток в ваших руках и в вашем контуре. Поэтому на приёмке меняются выборка, место и человек за клавиатурой, а не набор функций.
Кто собирает выборку, на которой проверяют пилот?
Ваша сторона. Исполнитель вправе сказать, в каком виде нужны данные и какого объёма, но сами случаи отбирает не он — иначе прогон показывает подготовленность примеров, а не работу системы. Выборку собирают до настройки и до приёмки не показывают.
Система отказалась обрабатывать часть потока — это провал?
Сам отказ — нет, он бывает правильным поведением. Провалом считается невидимый отказ: случай не обработан, но в отчёте выглядит как обработанный, и у него нет адресата. На приёмке проверяется список таких случаев и то, кто забирает их дальше.
Можно ли записать критерии провала, если подобных проектов у нас не было?
Да: пункты списка описывают процедуру проверки, а не отраслевой опыт — кто собирает выборку, кто проводит прогон, где он идёт и что остаётся. Числовой порог качества в этот список не входит. Он относится к содержанию задачи, назначается до старта и записывается вместе с метрикой — этот разговор разобран отдельно, в материале о том, когда AI-пилот считать неудачным. Незнакомая отрасль мешает назвать порог, но не мешает заранее записать, на каких данных и чьими руками его будут проверять.
Обязательно ли проводить приёмку на своём сервере?
Если после пилота система должна работать внутри вашей сети — да: перенос — отдельная работа, и пилот на чужом стенде её не проверяет. Если по договорённости система остаётся на стороне исполнителя, пункт снимается, но его место занимает вопрос о доступе: что будет с работой, если доступ к чужому контуру пропадёт.