AI може скоротити частину роботи над прототипом і допомогти перевірити вузьку бізнес-ідею до повної розробки. Але цінність такого експерименту визначає рішення, яке ви зможете прийняти після нього: чи потрібен продукт клієнтам, чи допомагає новий процес і чи можна підключити необхідні дані. Одна демонстрація не дає відповіді на всі ці запитання.
Наприклад, клієнтський портал може виглядати переконливо, але головне питання залишиться відкритим: чи будуть клієнти ним користуватися замість дзвінка менеджеру?
Перш ніж просити команду розробити прототип, варто визначити, що саме він має допомогти з’ясувати.
Почніть із рішення, яке потрібно прийняти
Спробуйте завершити речення: «Після цього експерименту ми зможемо вирішити, чи варто…»
Можливо, йдеться про інвестицію в портал, автоматизацію повторюваної роботи або підключення нового продукту до наявної системи. Для кожного рішення потрібні свої свідчення.
| Запитання | Що перевіряти | Чого прототип сам собою не доводить |
|---|---|---|
| Чи є попит? | Готовність клієнта до конкретного зобов’язання, наприклад платного пілота | Привабливий екран не доводить готовність платити |
| Чи корисний новий процес? | Чи виконує представник цільової аудиторії потрібне завдання | Успішна демонстрація не доводить регулярного використання |
| Чи можлива інтеграція? | Чи вдається підключитися до необхідних даних у контрольованому тесті | Один успішний запит до API не доводить надійність робочої системи |
Оберіть невизначеність, яка справді може змінити рішення про інвестицію. Іноді спочатку достатньо розмов із клієнтами або послуги, яку команда надає вручну. Прототип доречний тоді, коли взаємодія з робочим прикладом дасть інформацію, яку складніше отримати іншим способом.
Яку роботу може прискорити AI
Агент для програмування може допомогти створити невеликий інтерфейс, підключити документований API у тестовому середовищі, підготувати приклади даних і перевірки. Завдяки цьому команда може раніше випробувати окремий сценарій, не розробляючи всю систему.
Залиште чіткі межі: один тип користувача, одне завдання, одне джерело даних і зрозумілий очікуваний результат. Такий фрагмент простіше реалізувати й оцінити, ніж загальне прохання «зробіть платформу».
При цьому самому продукту AI може бути не потрібний. Команда може використовувати AI для розробки звичайного порталу або інструмента звітності. Потреба в AI-агенті всередині продукту — окреме питання.
Чому не варто планувати бюджет за обіцянкою «у кілька разів швидше»
Дослідження вивчають різні інструменти, команди й види роботи. В аналізі трьох польових експериментів Microsoft Research використання помічника для доповнення коду збільшило кількість завершених завдань. Це не означає таке саме скорочення вартості нового бізнес-продукту.
В оновленні METR за лютий 2026 року автори описують проблеми відбору учасників і вимірювання часу в пізнішому експерименті. А в опитуванні за травень 2026 року окремо розглядають суб’єктивну оцінку швидкості та цінності виконаної роботи. Відповіді учасників не встановлюють причинний ефект.
Наш практичний висновок: рахуйте весь експеримент — постановку, реалізацію, перевірку з користувачем, аналіз і виправлення. Оцінюйте, яке рішення стало можливим. Кількість згенерованого коду сама цього не показує.
Розділіть критерії для прототипу та робочої системи
Прототип має відповісти на погоджене запитання. Робоча система має підтримувати реальний процес у визначених умовах.
| Частина роботи | Для вузького експерименту може бути достатньо | Для робочої системи потрібно визначити |
|---|---|---|
| Користувачі й дані | Запрошені учасники та синтетичні або погоджені приклади | Права доступу, відповідальних за дані та правила їх обробки |
| Інтеграції | Одного контрольованого сценарію через тестовий API | Авторизацію, обробку збоїв, ліміти й узгодження даних |
| Якість | Перевірок, пов’язаних із гіпотезою | Критерії якості й повторні перевірки після змін |
| Відповідальність | Власника експерименту | Розгортання, моніторинг, підтримку й реагування на збої |
В обох випадках потрібні відповідні обмеження. Назва «прототип» не дозволяє відкривати реальні клієнтські дані чи надавати агенту необмежений доступ.
В інженерному матеріалі Anthropic про тривалу розробку застосунків також описано значення структури роботи й оцінювання результату. Це досвід виробника інструмента, а не гарантія ціни чи строку для вашого проєкту.
Умовний приклад: чи знайде клієнт статус без менеджера?
Уявімо компанію, менеджери якої регулярно відповідають на запитання про статус заявок. Виникає ідея клієнтського порталу. Приклад умовний: він не описує клієнта Madency, отриманий результат або комерційну оцінку.
Перше припущення: клієнт зможе сам знайти поточний статус і зрозуміти наступну дію, не звертаючись до менеджера.
Для перевірки можна реалізувати один сценарій із підготовленими записами. Запросіть представників цільової аудиторії знайти статус і пояснити, що вони робитимуть далі. Спостерігайте, де їм потрібна допомога та чи відповідає інформація на їхнє запитання. З’ясуйте, як вони використали б цей інструмент у звичній роботі.
До тесту домовтеся, які спостереження виправдають наступну інвестицію. Наприклад, команда може продовжити лише якщо учасники виконують завдання без підказок і правильно пояснюють наступний крок. Визначте, як записуватимете результати та які суперечливі відгуки стануть підставою змінити рішення або зупинитися. Це можливі критерії тесту, а не заявлені результати.
Якщо перевірка невдала, спочатку розберіться з причиною. Можливо, незрозумілі назви статусів, ненадійні вихідні дані або клієнту потрібна розмова, якої портал не замінить. Додавання функцій не обов’язково усуне проблему.
Після успішного тесту виникне наступне питання: чи користуватимуться порталом регулярно? Підключення реальних записів, розмежування доступу та підтримка потребуватимуть окремої роботи. Зручність одного сценарію ще не доводить попит на платний продукт.
Визначте межі витрат на перевірку
Експеримент потребує часу інженерів, уваги користувачів, використання інструментів і перевірки результату. Обмежте цю роботу до початку реалізації.
Короткий опис експерименту має містити:
- Користувача й проблему: хто її відчуває та як вирішує зараз.
- Припущення: що саме може змінити ваше рішення.
- Свідчення: що, з ким і за яких умов перевірятимете.
- Дані та дії: що прототип може читати або змінювати.
- Межі: погоджений обсяг, ресурси, відповідального та момент зупинки для аналізу.
- Наступне рішення: продовжувати, змінити підхід, перевірити інше припущення або зупинитися.
Врахуйте перевірку згенерованого коду та виправлення. Якщо експеримент залежить від недоступних даних або кількох неперевірених інтеграцій, звузьте його чи спершу з’ясуйте ці обмеження. Для порівняння кандидатів стане у пригоді оцінка першого процесу для AI.
Як перейти від висновків до погодженого обсягу розробки
Використайте спостереження для наступної оцінки. Що спрацювало? Чого користувачі не зрозуміли? Яких даних або правил доступу бракувало? Які частини прототипу варто залишити, а які — замінити?
У Madency Discovery за $500 допомагає визначити процес, дані, обмеження й обсяг впровадження. Це не обіцянка розробити будь-який прототип за $500. Вартість Етапу розробки визначається після погодження обсягу робіт. Якщо договір на розробку підписано протягом 60 днів після фінального звіту Discovery, його вартість одноразово зараховується в оплату Етапу розробки.
Подальші зобов’язання пояснюють процес роботи, розбір вартості AI-агента та AI-підтримка після запуску.
Принесіть один повторюваний робочий процес або вузьке продуктове припущення на коротку розмову. Визначимо, чи варто починати з Discovery.