Демо - це записаний маршрут. Дані дібрані, обсяг малий, шлях веде від однієї кнопки до другої, і все на ньому вже один раз працювало - інакше б його ніхто не показував. Це не обман, це природа показу.
Проблема починається тієї миті, коли з показу роблять приймання. Підписують, що роботу виконано, рахунок іде, а перші справжні дані надходять лише потім. Різницю між тим, що бачив замовник, і тим, що стається в понеділок уранці, потім ніхто не розбирає як дефект - її розбирають як додаткові роботи.
Ця стаття про те, як вибудувати приймання так, щоб ця різниця вийшла назовні раніше, ніж поставлять підпис.
Демо падає. Дізнатися про це має підрядник, а не ви
Почнемо з власного досвіду, бо він неприємний.
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.
