Демо - это записанный маршрут. Данные подобраны, объём маленький, путь ведёт от одной кнопки к другой, и всё на нём уже один раз работало - иначе бы его никто не показывал. Это не обман, это природа показа.
Проблема начинается в тот момент, когда из показа делают приёмку. Подписывают, что работа выполнена, счёт уходит, а первые настоящие данные приходят только потом. Разницу между тем, что видел заказчик, и тем, что происходит в понедельник утром, потом никто не разбирает как дефект - её разбирают как дополнительные работы.
Эта статья о том, как выстроить приёмку так, чтобы эта разница вышла наружу раньше, чем поставят подпись.
Демо падает. Узнать об этом должен подрядчик, а не вы
Начнём с собственного опыта, потому что он неприятный.
6. 8. 2026 у нас упал показ у клиента. Собственная запись того дня звучит дословно: «куда ни ткнул, везде либо ошибка, либо error», а генерация документа ждала около десяти минут. Речь шла о системе, которая готовит договорную документацию, - то есть о работе, где под результатом кто-то подписывается.
Четырьмя днями позже, 10. 8. 2026, та же система прошла показ всему офису клиента и этап был выставлен в счёт. Между этими двумя днями не менялись ни техзадание, ни объём работ. Изменилось то, что первый прогон прошёл вживую и нашёл то, что нужно было найти.
Из этого следует единственное практическое правило, и оно распространяется на кого угодно, включая нас: первый боевой прогон где-то произойти обязан. Вопрос лишь в том, произойдёт он у подрядчика на ваших данных до подписи или у вас после неё.
Объём - это другая задача, чем показ. И выясняется это в первую неделю
Второй пример из нашего собственного продукта, поэтому его можно описать конкретно. В системе Jobsi для кадровых агентств есть модуль, который читает паспорта и техпаспорта с фотографии.
Технологию мы выбирали 29. 11. 2025 и выбрали дороже. От более дешёвого машинного распознавания мы отказались из-за того, как эти фотографии выглядят на самом деле: люди снимают их с рук, в машине, за рулём. На демонстрации это работало.
В боевую работу это пошло 17-19. 2. 2026. 23. 2. 2026 клиенты жаловались, что скан идёт долго и падает с ошибкой - то есть в течение нескольких дней. Речь шла не о новом дефекте. Дело было в том, что изменился способ использования: вместо отдельных документов в систему пошли пачки. Решение в итоге было не в замене технологии, а в изменении сценария - пакетная асинхронная обработка вместо ожидания одного документа за другим.
Эти две даты стоит сравнить. От выбора технологии до того падения прошло почти три месяца, и выглядит это как долгий срок на проверку. От боевого запуска прошло четыре дня - и решает именно второй промежуток, потому что только там появилась нагрузка, которой раньше неоткуда было взяться.
Вывод для приёмки: функция, которая прошла на одном документе, не проверена. Проверена она тогда, когда проходит на стольких документах, сколько в пик засыпете вы, - и в том же ритме.
Что «на ваших данных» означает практически
Фраза «хотим видеть это на своих данных» звучит само собой разумеющейся, а на практике из неё получается выгрузка десяти красивых записей. Они ничего не доказывают, потому что красивые записи пройдут и через самую плохую интеграцию.
Образец для приёмки составляют намеренно, и в нём четыре группы:
- Худшие реальные записи, а не средние. Самое длинное название, отсутствующий регистрационный номер, диакритика в поле, где её по мнению подрядчика быть не должно, два адреса у одной фирмы, позиция одновременно со скидкой и с наценкой.
- История, а не только новые записи. Данные, введённые пять лет назад, имеют другую структуру, чем данные с прошлой недели, потому что вводил их другой человек по другим привычкам.
- Объём пика, а не средний день. Когда вам за один день приходит сто пятьдесят позиций, тестируют сто пятьдесят позиций. Не пятнадцать.
- Одновременность. Два человека работают в один момент, сценарий идёт посреди этого, и кто-то одновременно меняет запись, которая как раз переносится.
Последний пункт пропускают чаще всего, а его последствия при этом ищут тяжелее всего, потому что они не повторяются по команде.
Приёмка - это протокол, а не впечатление от показа
Показ заканчивается фразой «выглядит хорошо», и ею потом можно оправдать что угодно. Протокол приёмки заменяет её четырьмя столбцами, которые читаются и через полгода:
Пример:
| Что проверяли | На каких данных | Результат | Кто и в какой срок исправит |
|---|---|---|---|
| Создание документа | 150 позиций, пик | прошло | - |
| Документ с изменением после переноса | 12 записей за прошлый год | не прошло | подрядчик, 12. 9. |
Протокол делает три вещи одновременно. Он определяет, что считается готовым. Он отделяет дефект от дополнительных работ, потому что дефект - это то, что было в протоколе и не прошло. И он даёт обеим сторонам список, который можно отмечать, вместо споров о том, что было обещано на встрече.
Одна фраза в протоколе нужна всегда: что произойдёт, если сценарий упадёт в боевой работе. Кто это увидит, где это появится и в какой срок подрядчик будет на месте. Без этого приёмка подписана на состояние, которое держится один день.
Когда приёмку сделать нельзя и что делают вместо неё
Иногда реальные данные подрядчику дать вообще нельзя - они персональные, они под соглашением о неразглашении, или их выдача сама по себе риск. Тогда приёмка на демо - не решение, а аварийный режим, и уменьшить его можно двумя способами:
- Обезличенный образец с сохранённой структурой. Имена заменяются, длины, форматы, пробелы и отсутствующие значения остаются. Большинство ошибок в интеграциях как раз про структуру, а не про содержание.
- Приёмка у вас, на вашей машине, с вашим человеком за клавиатурой. Подрядчик смотрит, но не нажимает. Этот формат вскрывает и то, что технически работает, а в работе непригодно.
Пять вопросов, которые стоит задать перед подписанием приёмки
Они работают на кого угодно, включая нас, и ответы запросите письменно.
- На каких данных работало то, что я сейчас видел, - на моих или на ваших?
- Сколько записей прошло за один прогон и сколько вы ждёте в пик у меня?
- Что произойдёт с незавершённой записью, если сценарий упадёт посередине?
- Какие из моих исключений вы пока не видели и что мы с ними сделаем, когда они появятся?
- Кто узнает об ошибке раньше - вы или мы?
Показ отвечает на вопрос, работает ли это. Приёмка отвечает на вопрос, работает ли это у вас. Это два разных вопроса, и за второй платят.
Ту же логику мы раньше описали при подключении интернет-магазина к бухгалтерии, где она заканчивается фразой, которую здесь разворачиваем целиком: прежде чем подписать, требуйте показать это на ваших данных, а не на демо (Shoptet API и подключение к Pohoda).
Пришлите нам образец, а не описание
Когда запрашиваете автоматизацию у нас, требуйте приёмку на своих данных и напишите это в запросе. Это сэкономит обеим сторонам: мы выясним объём раньше, чем будем писать цену, а вы выясните, видели ли мы такую нагрузку раньше.
Что мы автоматизируем и в каком объёме, вы найдёте в разделе автоматизация; подключение к корпоративным системам мы описываем отдельно в разделе CRM и ERP.
Напишите на info@lamapixel.com или звоните +420 775 599 009.
