Продукт і вимоги

Від «зробіть застосунок» до підтвердженого результату

«Нам потрібен застосунок для запису на консультації». Це може бути точний опис потреби, а може бути лише перше рішення, яке спало замовникові на думку.…

Глава 7Заморожене українське видання

«Нам потрібен застосунок для запису на консультації». Це може бути точний опис потреби, а може бути лише перше рішення, яке спало замовникові на думку. Перш ніж рахувати екрани й оцінювати розробку, варто з'ясувати, що відбувається до запису, хто веде розклад, чому люди не приходять і чого саме бізнес хоче досягти.

Навчальний результат

Після глави ви зможете відрізнити проблему від запропонованого рішення, користувача від покупця, а докази від припущень; оцінити основні ризики продукту; вибрати найдешевшу доречну перевірку; визначити, чи варто починати розробку; передати команді висновки й перелік того, що ще невідомо, для оформлення вимог.

Глави 1–5 дають контекст продукту, коду, виконання програми, історії змін і рецензування в GitHub; глава 6 показує, як фіксувати й передавати узгоджену роботу в Jira. Тут з'ясуємо, чи правильно визначено саму проблему і що варто робити далі. У главі 8 висновки discovery перетворяться на вимоги й сценарії, а глава 70 розглядає економіку студії.

Discovery — не зустріч перед початком коду

Discovery — робота, що допомагає вирішити, яку проблему варто розв'язувати, для кого і яким способом. Delivery — проєктування, розробка, перевірка, випуск і підтримка обраного рішення. Ці види роботи чергуються: discovery не завершується раз і назавжди перед delivery. Нові дані під час використання продукту можуть показати, що проблема інша, припущення не справдилося або з'явилася краща альтернатива.

Тереза Торрес описує безперервне дослідження як регулярні невеликі дослідницькі кроки команди разом із клієнтами, спрямовані на бажаний результат. Це її методичний орієнтир, а не універсальне правило «інтерв'ю обов'язково щоп'ятниці» для кожної студії. Результати дослідження мають регулярно впливати на рішення команди. Так команда спирається на свіжі дані, а не на спогади про давню передпроєктну сесію. Торрес пояснює зв'язок дослідження з рішенням, що будувати.

Опис державної програми сервісів Джона Вотерворта також наводить стратегії участі дослідників і регулярного вивчення користувачів упродовж життєвого циклу сервісу. Це приклад роботи урядової команди, а не універсальний календар для приватної студії (Waterworth, “8 strategies that worked for us”).

Discovery охоплює три близькі, але різні питання:

Потреба: чого людина намагається досягти й що заважає?
Рішення: який спосіб може усунути перешкоду, і як перевірити, що спосіб працює?
Здійсненність: чи може команда безпечно побудувати й підтримувати цей спосіб з наявними часом, уміннями, даними, договорами та системами?

Дослідження потреб не є синонімом технічного пошуку. Наприклад, інженер може перевірити, чи дозволяє чинний сервіс читати доступні години. Це дає дані про здійсненність конкретного підходу, але не доводить, що клієнтам потрібен новий застосунок. Планування реалізації допомагає розкласти вже обрану роботу, але також не доводить, що проблема важлива.

Discovery зменшує невизначеність до рівня, достатнього для наступного рішення; воно не обіцяє повної певності. Дослідження може закінчитися рішенням продовжити, обмежити першу версію, перевірити ще одне припущення або зупинитися. В офіційному посібнику уряду Великої Британії завершення discovery пов'язане з рішенням, чи виправдано рухатися далі з огляду на цінність і вартість можливого сервісу; зупинитися після дослідження — нормальний результат, якщо це економить марну роботу. Посібник про discovery описує державні цифрові послуги, тому його приклади треба адаптувати до приватної студії.

Проблема — це не назва функції

Фраза «зробіть календар і сторінку профілю» описує можливий інтерфейс. Щоб зрозуміти проблему, треба дізнатися:

хто саме намагається щось зробити і в якій ситуації;
що людина робить зараз;
де виникають затримка, помилка, невпевненість або зайві витрати;
як люди обходять перешкоду;
що стається, якщо нічого не змінювати;
кому ще ця проблема створює роботу чи ризик;
якої зміни в поведінці або результаті потребує організація.

Корисне формулювання проблеми може мати таку будову:

Коли [ситуація], [конкретна роль] намагається [досягти результату]. Зараз ця людина [наявний спосіб або обхід], але [конкретне тертя] призводить до [наслідок для користувача чи організації]. Ми ще не знаємо [важливе припущення].

Це не бланк для механічного заповнення. Його мета — не допустити, щоб назву рішення підставили замість опису реального досвіду. GOV.UK радить перевіряти наперед задане рішення і переформульовувати його як проблему; такий крок може відкрити альтернативи, зокрема іншу інформацію, процес або сервіс. Посібник також наголошує на фіксації того, що не входить до проблеми.

Наприклад, «потрібна інтерактивна карта» — це вибір засобу. За ним може стояти потреба швидко знайти найближче місце прийому. Але ще треба встановити, чи люди шукають його на мапі, чи телефонують працівникові, чи губляться через незрозумілий графік і чи важливий саме пошук адреси. Якщо виявиться, що адреси вже легко знайти, а проблема в неможливості перенести запис, нова карта не допоможе.

Jobs To Be Done: поступ, якого прагне людина

Jobs To Be Done (JTBD — «робота, яку людина намагається виконати») — підхід, що пояснює вибір через обставини й бажаний поступ, а не лише через вік, професію чи список функцій. Людина «наймає» товар або послугу, коли це допомагає їй зробити потрібний крок у конкретній ситуації. Цей поступ може бути функціональним, емоційним і соціальним. Christensen Institute пояснює JTBD через обставини, сили зміни та види поступу.

У записі на консультацію функціональний поступ може звучати так: «знайти час, який не конфліктує з роботою». Емоційний: «бути впевненим, що запис справді підтверджено». Соціальний: «не виглядати ненадійним перед колегами, яких я запросив». Це не готові факти про будь-якого клієнта; це можливі напрями дослідження.

JTBD корисний, бо дозволяє побачити альтернативи, які не схожі на ваш продукт. Людина, що хоче перенести консультацію, може телефонувати, писати листа, просити колегу передати повідомлення, пропускати її або чекати відповіді. Конкуренція за бажаний результат — не лише між двома застосунками; вона включає всі звичні способи й варіант нічого не змінювати.

Не перетворюйте JTBD на магічне речення, яке нібито відкриває приховану правду. Це лінза для запитань, а не доказ. Потрібно перевірити контекст розповідями людей, спостереженням, наявними даними та малими експериментами.

Хто користується, хто платить, хто вирішує

У невеликому проєкті ці ролі часто виконує одна людина. У складнішому вони відрізняються. Слово «клієнт» саме по собі не пояснює, чий досвід треба поліпшити та хто може затвердити витрати.

Сегмент — група людей або організацій із подібною ситуацією чи проблемою. «Усі клініки» надто широко, якщо різні типи консультацій, правила запису й відповідальні ролі відрізняються.
Користувач — людина, яка виконує роботу через сервіс: наприклад, відвідувач, що бронює час.
Покупець або замовник — сторона, що обирає рішення та погоджує його придбання; це може бути керівник клініки.
Платник — особа або організація, з коштів якої оплачують систему чи послугу. В організації це часто бухгалтерія або власник бюджету.
Адміністратор — людина, яка налаштовує розклад, правила чи доступи й обробляє винятки.
Зацікавлена сторона — людина або група, на яку вплине рішення: ресепшн, фахівці, керівництво, служба підтримки, юридична чи технічна команда.

Не варто припускати, що покупець автоматично представляє користувача. Керівникові може бути важлива заповненість календаря, консультантові — час на підготовку до зустрічі, клієнту — просте перенесення, адміністраторові — менше ручного узгодження. Усі ці інтереси можуть бути законними, але не тотожними.

Шлях користувача (англ. user journey) — послідовність дій, контактів і рішень людини в контексті цілого завдання. Для запису це може бути: дізнатися про консультацію → перевірити умови → знайти час → підтвердити → отримати нагадування → прийти або перенести → отримати подальшу інформацію. На кожному кроці можуть бути вебсторінка, дзвінок, лист, особисте повідомлення або робота працівника. Шлях — не перелік екранів: екран показує лише частину взаємодії.

Посібник GOV.UK рекомендує досліджувати весь досвід користувача, включно з підтримкою, офлайновими кроками й працівниками, які надають послугу. Він окремо нагадує про потреби людей з інвалідністю, різний рівень цифрової впевненості та доступу до інтернету. Опис дослідження користувачів у discovery подає спостереження, розмови, аналітику й журнали підтримки як різні джерела навчання.

Гіпотеза, припущення й доказ

Припущення — переконання, яке впливає на рішення, але ще не підтверджене достатніми даними. Гіпотеза — конкретне твердження про те, що має статися за певних умов і який результат ми побачимо, якщо воно правдиве. Доказ — матеріал, який підтримує або послаблює твердження: безпосереднє спостереження, свідчення людини чи запис. Висновок пояснює, як команда тлумачить цей матеріал; у главі 8 у PRD окремо позначають спостереження, свідчення, висновки, припущення й рішення.

Щоб висновок можна було перевірити, розділяйте записи на п’ять категорій:

Спостереження: що команда безпосередньо побачила, виміряла або перевірила; зазначте джерело, хто й коли зібрав дані та контекст.
Свідчення: що конкретна людина повідомила про власний досвід; зазначте, хто сказав, коли й за яких обставин. Переказ інтерв’ю — це свідчення, а не безпосередньо спостережена поведінка.
Висновок: як команда зараз тлумачить спостереження, свідчення й записи.
Припущення: переконання, яке впливає на рішення, але ще потребує перевірки.
Відкрите питання: чого ще не знаємо і що може змінити рішення.

«Люди хочуть нагадування» — поки припущення. «У вибірці за визначений період у журналах видно певну кількість скасувань у день зустрічі» — спостереження, якщо відомі період, джерело й спосіб підрахунку. «Нагадування зменшать кількість пропусків» — гіпотеза. Після запровадження нагадувань може знадобитися порівняння відповідних груп і перевірка, чи зміни спричинили саме нагадування, а не сезонність, інший склад відвідувачів або паралельна зміна процесу.

Для кожного запису залишайте шлях до первинного матеріалу: нотатки, часовий період аналітики, версію інтерфейсу, звернення підтримки чи підсумок тесту. Не перетворюйте слова одного учасника на потребу всього ринку. Повторення того самого припущення в трьох звітах не створює три незалежні докази.

Що можуть показати різні методи

Інтерв'ю допомагає зрозуміти обставини, мову людини, її цілі, чинні способи й причини вибору. Запитуйте про конкретну минулу подію, а не про те, чи користувалася б людина ще не створеним продуктом: намір не доводить майбутньої поведінки або готовності платити. Наприклад: «Розкажіть про останній раз, коли ви переносили консультацію. Що зробили спочатку?»

Спостереження показує реальні кроки, обхідні шляхи, переривання та предмети, якими людина користується. Працівник може називати процес «двома кліками», а під час спостереження паралельно звіряти паперовий календар, пошту й таблицю. Проте одне спостереження не показує, наскільки проблема поширена. Присутність дослідника теж може змінити поведінку, тому контекст треба записати.

Поведінкові дані — записи про те, що люди роблять у продукті чи сервісі: початок і завершення запису, скасування, помилки, час до підтвердження. Вони можуть показати частоту та послідовність подій, але зазвичай не пояснюють причину. Якщо багато людей залишили форму на кроці вибору часу, причина може бути в порожніх слотах, незрозумілому тексті, збої, потребі спитати роботодавця або іншій обставині. Не збирайте зайві персональні дані; використовуйте лише показники, потрібні для рішення, і перевіряйте однаковість підрахунку до й після змін.

Звернення до підтримки й записи внутрішньої роботи вказують, де люди просять допомогу, що доводиться виправляти й скільки ручної роботи створює процес. Але не всі незадоволені звертаються: тиша не доводить відсутності проблеми. Категорії звернень також можуть бути неповними або застарілими.

Опитування здатне зібрати відповіді багатьох людей, але формулювання впливають на відповіді, а самовідбір учасників може перекосити вибірку. Опитування про намір не доводить майбутню дію. Воно корисніше для конкретного питання, де потрібна кількість відповідей, ніж як заміна спостереженню за досвідом.

Прототип — спрощене представлення майбутнього сервісу, від паперових екранів до інтерактивної демонстрації. Спостереження за тим, як людина виконує конкретне завдання на прототипі, може виявити незрозумілий текст, помилкове очікування чи невдалу послідовність. Воно не доводить, що люди куплять продукт, що інтеграція працює, що система безпечна або що її можна підтримувати. Вибирайте прототип, який відповідає саме на поставлене питання. Офіційний посібник з якісного тестування застерігає, що контрольоване завдання може не відображати реальне використання, та описує обмеження вибірки й контексту.

Стів Круг радить спостерігати за конкретним завданням, а не лише питати про враження від ідеї. Попросіть людину знайти вільний час і перенести зустріч. Якщо вона вагається між «Змінити час» і «Скасувати запис», уточніть підпис або наслідок дії й повторіть те саме завдання. Детальніше про ясність вибору йдеться в главі 8 Круг про різницю між usability-тестом і фокус-групою, уривок книжки про ясність вибору.

У розділі 4 книжки Don’t Make Me Think, Revisited Круг пояснює, що важить не сама кількість переходів, а розумове зусилля й невпевненість, які супроводжують кожен вибір. У прототипі запису людина має без здогадів розуміти різницю між «Змінити час» і «Скасувати запис» та наслідок натискання. Якщо учасники вагаються, спростіть формулювання або покажіть наслідок до підтвердження, а потім повторіть те саме тестове завдання. Це приклад уточнення, яке виникає зі спостереження за поведінкою, а не з голосування про те, який напис подобається.

Спочатку визначте питання, а потім метод. «Чи розуміють люди значення кнопки?» можна перевірити коротким тестом прототипу. «Чому люди скасовують консультацію?» потребує інтерв'ю, даних та, можливо, спостереження. «Чи варто підтримувати цю функцію?» вимагає також перевірки бізнесових і технічних умов.

Під час досліджень пояснюйте людям, що саме відбувається, просіть згоду на запис, обмежуйте доступ до нотаток і прибирайте персональні дані, якщо вони не потрібні. Якщо людина тестує прототип, оцінюють продукт і сценарій, а не її кмітливість. Посібник GOV.UK про модероване тестування радить давати нейтральні завдання, більше слухати й зберігати особисті дані безпечно.

Що команда випустила й що змінилося

Output — те, що команда створила або випустила: наприклад, екран вибору часу. Outcome — зміна для користувача чи організації, яку команда хотіла досягти: наприклад, більше людей приходять на призначені консультації або менше часу працівник витрачає на перенесення записів.

Output можна порахувати після завершення роботи. Outcome треба перевірити за поведінкою чи результатом у реальному контексті. Випуск десяти функцій ще не означає, що комусь стало легше. Успіх не варто визначати лише за кількістю екранів, закритих задач чи написаних рядків коду.

Чотири ризики Cagan

Марті Каган називає чотири ризики продукту. Для кожного сформулюйте питання, зберіть відповідний доказ і залучіть фахівця, який може його оцінити. За Каганом, менеджер продукту відповідає за цінність і бізнес-життєздатність, дизайнер — за зручність, а провідний інженер — за технічну здійсненність. На ранньому етапі вони працюють разом. У малій студії одна людина може поєднувати ролі, але треба оцінити всі потрібні аспекти Це розподілення та визначення ризиків пояснені в статті Cagan.

Ризик	Запитання	Що може підтримати висновок	Типова хибна підміна	Чия компетенція потрібна
Цінність	Чи важлива ця проблема і чи оберуть люди запропонований спосіб?	Нещодавній досвід, частота проблеми, вже застосовані обхідні шляхи, поведінкові дані; тест реальної готовності діяти, коли це доречно	«Людям сподобався макет» або «я сам так користувався б»	Менеджер продукту разом із дослідником і командою
Зручність використання	Чи зрозуміє людина, як виконати важливе завдання?	Спостереження за цільовими користувачами, які самостійно виконують конкретне завдання; видимі помилки, сумніви та завершення	«Екран виглядає сучасно» або «кнопка є»	Дизайнер продукту й дослідник
Технічна здійсненність	Чи може команда створити й підтримувати це з наявними технологіями, навичками й часом?	Перевірка критичних технічних припущень, доступності даних і зовнішніх сервісів, залежностей, вартості підтримки та ризиків	«Схожий продукт існує» або «агент здатен написати код»	Провідний інженер із командою
Бізнес-життєздатність	Чи працює рішення разом із продажами, витратами, договорами, правом, підтримкою й довірою?	Погодження з платником і власником бюджету, перевірка моделі витрат і доходів, каналів залучення, операційної роботи та обмежень	«Якщо користувачам подобається, бізнес автоматично виграє»	Менеджер продукту разом із відповідальними за бізнес і операції

Доказ має відповідати питанню. Інтерв'ю може підтримати висновок про контекст проблеми, але не замінює технічної перевірки інтеграції. Прототип може виявити труднощі використання, але не підтверджує, що платник погодить бюджет. Зелений технічний прототип не доводить ринкового попиту.

Команди часто перевіряють лише зручність, бо її легко спостерігати. Каган застерігає: реакція на готовий дизайн не доводить цінності й не знімає ризику бізнес-життєздатності. Немає універсального тесту або фіксованої кількості розмов, яка автоматично знімає ризики. Запитайте, що має бути правдою для цього рішення і який доступний доказ змінить наступний крок.

Кейс SEEK показує зміну процесу, а не універсальний рецепт. У власному описі команди, яку консультувала Тереза Торрес, вона розповідає про перехід від нерегулярного discovery й приблизно п'яти-шести інтерв'ю на квартал до щотижневих інтерв'ю та явного переліку ризикованих припущень для перевірки. Це самозвіт учасників описаного кейсу, а не незалежне вимірювання ефективності: він показує, як може змінитися робочий процес, але не доводить причинного бізнес-ефекту (Torres, кейс SEEK).

Повністю розібраний приклад 1. «Потрібен застосунок для запису»

Ситуація. Власниця консультаційної клініки просить мобільний застосунок із профілем, календарем, нагадуваннями, оплатою та оцінками. Її команда часто шукає в листуванні підтвердження часу, а консультанти повідомляють про пропущені зустрічі. На цьому етапі причина пропусків і масштаби втрат невідомі.

Увесь цей приклад — ілюстративний сценарій із вигаданими даними, а не звіт про реальну клініку чи проведене дослідження.

Проблема до дослідження. Перше формулювання звучить як «потрібен застосунок». Команда спершу уточнює, хто бронює час, хто його підтверджує, хто може змінити запис, хто відповідає за календар і які випадки створюють найбільше роботи. Вона просить показати не персональні дані, а поточний процес від першого запиту до завершеної консультації.

У цьому сценарії з'ясовується, що:

відвідувач хоче знайти прийнятний час і бути впевненим, що він заброньований;
адміністратор веде два розклади й вручну звіряє їх;
консультант втрачає підготовлений час, коли людина не приходить;
власниця ухвалює рішення про витрати;
команда ще не знає, чому люди не приходять і чи хочуть вони самі бронювати онлайн.

Можливе формулювання проблеми: «Коли людина домовляється про консультацію, їй потрібно знати, що час підтверджений, і мати зрозумілий спосіб перенести зустріч. Зараз підтвердження проходить через кілька каналів, а працівники вручну звіряють зміни. Ще невідомо, чи саме плутанина збільшує кількість пропусків». Це описує роботу й відкриту гіпотезу, а не обіцянку, що застосунок зменшить пропуски.

Дія. Команда відокремлює спостереження від пояснень і збирає доступні підсумки скасувань та пропусків за погоджений період. З дозволу клініки вона спостерігає за ручним записом без перегляду персональних даних, окремо розмовляє з відвідувачами, адміністраторами й консультантами та переглядає чинний календарний сервіс. Період і визначення «пропуску» треба записати, бо від них залежить базова величина.

Паралельно команда формулює outcome: «зменшити частку призначених консультацій, що завершуються пропуском, не збільшуючи ручний час на один запис». Спершу вона вимірює базовий рівень і погоджує, як його рахувати. Вигадувати початкове число чи довільну ціль до доступу до даних не можна.

Перевірка чотирьох ризиків.

Ризик	Що саме перевіряє клініка
Цінність	Зіставити випадки пропусків, дзвінки й перенесення, щоб з'ясувати причину та її важливість для відвідувачів і клініки. Схвалення власниці саме по собі попиту не доводить.
Зручність	Поспостерігати, як відвідувачі знаходять час, розуміють підтвердження й переносять зустріч на прототипі; оцінки команди замало.
Технічна здійсненність	Перевірити доступ до календаря, правила постачальника та синхронізацію без подвійних бронювань. Інтеграція в іншому проєкті не гарантує доступу тут.
Бізнес-життєздатність	Підтвердити власника бюджету, повну вартість, обробку винятків, спосіб вимірювання користі й потребу згоди на повідомлення. Висока оцінка інтерфейсу цих питань не закриває.

Тут менеджер продукту не може одноосібно підтвердити всі аспекти. Дослідник допомагає побачити поведінку й контекст; дизайнер виявляє труднощі у взаємодії; інженер оцінює доступи, синхронізацію та підтримку; керівник клініки підтверджує бізнесові й операційні умови. Агент може допомогти з кодом, але не замінює цих перевірок і не перетворює припущення на факт.

Альтернативи. До власного застосунку можна порівняти:

налаштувати наявний сервіс онлайн-запису;
додати просту сторінку доступних годин до чинного сайту;
підключити календар клініки до готової системи запису;
провести обмежений ручний пілот підтверджень і перенесень;
змінити інструкцію адміністратора або шаблон листа, якщо головне тертя — не інтерфейс;
не змінювати систему, якщо проблема рідкісна або вартість виправлення перевищує очікувану користь.

Власна розробка має сенс, коли дослідження виявляє конкретну потребу, готові альтернативи не покривають важливого контексту, платник приймає витрати, а команда здатна підтримувати результат. Не створюйте продукт лише тому, що його можна швидко згенерувати.

Результат і наступний крок. У вигаданому дослідженні команда бачить, що пропуски часто стаються після зміни графіка, а повідомлення не завжди доходить до потрібної людини. Цього недостатньо, щоб виправдати окремий мобільний застосунок. Спершу варто перевірити на обмеженій групі повідомлення з явним підтвердженням і простий спосіб перенести зустріч, а також з'ясувати, чи підтримує це чинний сервіс. Після пілоту порівняйте узгоджені показники з базовим рівнем і зафіксуйте відмінності між групами та періодами.

Чому та коли це рішення може не підійти. Воно зменшує ризик витратити кошти на непотрібний мобільний продукт і перевіряє проблему ближче до реального процесу. Але якщо користувачі працюють без інтернету, мають різні потреби доступності або чинний сервіс не дозволяє безпечно синхронізувати записи, сторінка чи повідомлення можуть не вирішити задачу. Короткий тест не доведе, що користувачі залишатимуться з продуктом через рік або що зміни пояснюються тільки новим способом запису.

Розмова з клієнтом: діагноз перед рецептом

У переліку дванадцяти принципів Блера Еннса є діагностика перед рекомендацією, вибір клієнтів і рання розмова про гроші. Для студії це орієнтир доброчесного продажу експертної роботи, а не привід приховувати ціну, тиснути на клієнта чи відмовляти всім без готового бюджету. Авторська сторінка The Win Without Pitching Manifesto.

Діагностика до рецепта означає, що студія спершу розуміє ситуацію, доступні дані, ризики й межі, а тоді пропонує обсяг і рішення. Це не безкоштовне стратегічне проєктування на першій розмові. Коротка вступна розмова може з'ясувати взаємну відповідність, але повний аудит, дослідження, вимоги й дизайн є окремою роботою, для якої треба визначити оплату та результат.

Приклади коректних запитань:

«Розкажіть про останній раз, коли клієнт не прийшов або переніс консультацію. Що сталося від першого повідомлення до завершення ситуації?»
«Що ви вже пробували змінити? Що відбулося після цього?»
«Як ви сьогодні рахуєте пропущені зустрічі та час на ручне узгодження?»
«Хто бронює час, а хто змінює розклад? Хто адмініструє винятки?»
«Хто користуватиметься системою, хто погоджує рішення, хто затверджує витрати й хто оплачуватиме підтримку?»
«Які строки чи зовнішні залежності вже зафіксовані?»
«Який бюджетний діапазон можна розглядати і хто його підтверджує? Якщо діапазону поки немає, що вам потрібно знати перед таким рішенням?»
«Які критерії дадуть підставу продовжити, а за яких обставин варто зупинитися або обрати інший шлях?»

Запитання про бюджет пояснюйте метою: зрозуміти доступні варіанти, повну вартість і повноваження на рішення, а не тиснути на клієнта чи підлаштувати оцінку під приховану межу. Зафіксуйте, хто ухвалює рішення та які дані ще потрібні; не трактуйте відсутність готового бюджету як доказ, що проблема неважлива.

Не просіть клієнта розкрити чужі медичні чи платіжні відомості; для першого діагнозу достатньо опису процесу, знеособлених підсумків і дозволених зразків. Не примушуйте клієнта до конкретного бюджету чи невідповідної послуги. Поясніть, навіщо питаєте, і дайте можливість не відповідати.

Платну діагностичну роботу можна обмежити предметом і тривалістю: наприклад, розібрати наявний шлях запису, провести узгоджені розмови, перевірити ключові гіпотези й підготувати рішення з альтернативами та відкритими питаннями. Це дає клієнтові корисний результат, навіть якщо наступним рішенням буде не замовляти розробку в цієї студії.

Кваліфікація — перевірка відповідності між проблемою, досвідом студії, доступом до потрібних учасників, бюджетом, строками й ризиками. Це не оцінка гідності клієнта. Можна чесно сказати: «За описом ми поки не знаємо, чи потрібна вам розробка. Пропонуємо коротку оплачувану діагностику; після неї ви отримаєте висновок із варіантами. Якщо з'ясується, що готовий сервіс краще відповідає потребі, ми це теж зафіксуємо». Можна відмовитися, якщо клієнт просить безкоштовно підготувати повне рішення, не допускає користувачів до дослідження або очікує результату, якого команда не може відповідально гарантувати.

Окремий платний етап не потрібен заради самого ритуалу. Якщо потребу вже перевірено, обсяг малий і рішення можна безпечно відкотити, може бути доречно одразу оцінити реалізацію. Діагностика виправдана, коли ціна помилки або невизначеність достатні, щоб окрема робота дала клієнту корисний результат незалежно від того, кого він найме для наступного кроку.

Позиціонування за проблемою, а не лише за технологією

Девід К. Бейкер пов'язує експертність із повторюваним досвідом і позиціонуванням для клієнтів, яким потрібна саме ця компетенція та які мають мало замін. Це авторська теза, а не незалежне порівняльне дослідження. Опис The Business of Expertise на авторському сайті.

Позиціонування корисно будувати навколо поєднання:

Кому допомагає студія: наприклад, невеликим клінікам, сервісним організаціям або внутрішнім операційним командам.
Яку повторювану проблему вона розуміє: запис, обробка винятків, узгодження між кількома системами, керування доступами.
Який підтверджений досвід дає перевагу: приклади виконаних робіт, розуміння регуляторного чи операційного середовища, перевірені методи діагностики.
Що клієнт може перевірити до покупки: ясний спосіб роботи, зрозумілі межі, приклади релевантних результатів і чесне обговорення ризиків.

«Ми працюємо з React» називає інструмент. Воно не пояснює, для кого команда корисна і яку складність уміє зменшити. «Допомагаємо клінікам із двома й більше локаціями зменшити ручне узгодження записів» уже називає тип клієнта й проблему, але це ще не доказ компетентності. Позицію треба перевіряти на реальних проєктах, здобувати досвід і звужувати або змінювати, якщо попит і здатність допомогти не підтверджуються.

Спеціалізація теж має ризик. Надто широка позиція робить студію схожою на багатьох інших, а надто вузька може залишити замало придатних клієнтів або обмежити нові можливості. Не вигадуйте «нішеву експертність» із красивого слогана; називайте реальні повторювані проблеми та докази, на яких ґрунтується рекомендація. Тут ідеї Бейкера про закономірності й позиціонування застосовано до діагностики продукту; це адаптація, а не переказ книжки.

Повністю розібраний приклад 2. Дві студії, один бриф

Нижче — ілюстративний діалог, не реальний клієнтський лист і не дослідження. Обидві студії отримали однаковий запит: «Потрібен мобільний застосунок для запису. Хочемо бачити макет п'яти екранів і оцінку вартості до п'ятниці».

Студія А: торг за ставку й безкоштовні екрани

Клієнт: «Потрібен мобільний застосунок для запису. Можете швидко надіслати макет?»

Студія А: «Так. Надішліть логотип. Ми зробимо п'ять екранів безкоштовно, а розробку порахуємо за годинами. Який бюджет ви маєте на увазі?»

Клієнт: «Поки не знаю. Хотілося б, щоб застосунок зменшив кількість пропусків».

Студія А: «Тоді додамо нагадування і рейтинг консультанта. Це допоможе переконати людей приходити».

Що сталося. Студія погодилася з рішенням до розуміння причин пропуску. Вона без доказів приписала нагадуванню бажаний ефект і запропонувала функцію рейтингу, якої замовник не називав. П'ять екранів можуть виглядати переконливо, але не відповідатимуть на запитання про користувачів, календарі, оплату, правила перенесення, вартість підтримки чи вимірювання результату.

Питання про бюджет саме по собі доречне; проблема в тому, що воно стало торгом за ціну без розуміння роботи. Безкоштовний макет також може підштовхнути до передчасного рішення й залишити студію з неоплаченою роботою. Це не означає, що кожна безкоштовна розмова є неправильною. Ризик виникає, коли без оплати виконується повна експертна робота, за яку клієнт прийшов найняти фахівців.

Студія Б: діагностика, відповідність і межі

Клієнт: «Потрібен мобільний застосунок для запису. Можете швидко надіслати макет?»

Студія Б: «Можемо оцінити, що потрібно дізнатися до макета. Ви згадали кількість пропусків: розкажіть про останній випадок, коли консультацію пропустили. Що відбувалося до зустрічі?»

Клієнт: «Адміністратор телефонує ввечері, але не завжди встигає. Дехто змінює час листом. Ми не знаємо, хто вже підтвердився».

Студія Б: «Чи можна на ознайомчій зустрічі побачити знеособлений приклад поточного процесу та обговорити його з адміністратором? Чи маєте ви підсумки запланованих, скасованих і фактично відвіданих консультацій за однаковий період?»

Клієнт: «Так, можна залучити адміністратора. Дані треба буде підсумувати».

Студія Б: «Хто бронюватиме, хто змінюватиме розклад і хто погоджує витрати? Який бюджетний діапазон уже можливий, навіть якщо остаточної суми ще немає?»

Клієнт: «Я власниця й затверджую бюджет. Не маю погодженого діапазону, доки не розумію, чи потрібен новий застосунок».

Студія Б: «Зрозуміло. Тоді зараз не пропонуватимемо повну розробку. Можемо окремо погодити коротку оплачувану діагностику: розібрати процес, перевірити дані й альтернативи, сформулювати ризики та рішення. Наприкінці ви матимете документ, з яким зможете рухатися далі з нами або звернутися до іншого постачальника. Повні макети й специфікацію до неї не готуватимемо».

Клієнт: «Мені треба порадитися з адміністраторами та зрозуміти ціну».

Студія Б: «Добре. Домовимося про короткий наступний дзвінок після цієї розмови. Якщо доступу до даних або людей бракуватиме, ми скажемо, що саме не зможемо встановити; не будемо видавати припущення за аудит».

Рішення. Студія Б не нав'язала діагностику: вона пояснила її результат, ціну, строк і питання, яких вона не зніме. Студія перевірила відповідність досвіду й запиту, роль платника, доступ до людей і невідомий бюджет. Діагностика має бути корисною сама по собі й дати клієнту свободу обрати наступного виконавця.

Результат у сценарії. Клієнт погоджує оплату за обмежену діагностику після отримання її обсягу, вартості, строку й переліку результатів. Якщо з'ясується, що готовий календар покриває потребу, рекомендацією може бути його налаштування, а не власна розробка. Якщо клієнт хоче лише безкоштовні екрани, студія може ввічливо відмовитися; це захищає час команди й не є покаранням клієнта.

Чому і коли такий підхід не підходить. Якщо замовник уже перевірив сценарій, має тверді вимоги, відомий бюджет і зрозумілий обсяг, пряма оцінка може бути доречною. Окремий етап також зайвий, якщо його вартість більша за ризик малого й зворотного рішення. Принцип — не додавати платну діагностику як ритуал, а не брати відповідальність за повне рішення без потрібного контексту й згоди клієнта.

Зв'язок із позиціонуванням. Якщо студія неодноразово допомагала клінікам узгоджувати записи між локаціями й бачить повторювані причини пропусків, цей досвід може стати справжньою спеціалізацією. Вона зможе ставити точніші питання й швидше відрізняти проблему графіка від проблеми повідомлень. Але не слід заявляти такий досвід до його здобуття: ринкова реакція має перевірити, чи ця відмінність справді цінна для покупців.

Наступний крок: перевірити ризик перед витратами

Discovery не має на меті складати список усіх можливих функцій. Його результат — обґрунтований вибір того, куди вкладати час і кошти далі. Почніть із гіпотез, хибність яких найсильніше змінить рішення:

Наслідок помилки: якщо припущення хибне, наскільки серйозною буде помилка?
Невизначеність: наскільки мало ми знаємо про це зараз?
Вартість перевірки: як дешево й безпечно зібрати інформацію, що змінить рішення?

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

Варіанти можуть бути такі:

Розробити власне (англ. build) — коли продуктова відмінність важлива, жодне придбання чи інтеграція її не забезпечує, а команда може підтримувати результат.
Придбати готове (англ. buy) — коли потреба стандартна, а вартість, правила, конфіденційність, умови постачальника та можливість виходу з сервісу прийнятні.
Інтегрувати чинний сервіс — коли потрібна нова взаємодія між системами, і її можна безпечно реалізувати без дублювання всього продукту.
Змінити процес — коли ручне повідомлення, нове правило підтвердження або ясніша інструкція перевіряють потребу швидше й дешевше за програму.
Не будувати — коли проблема надто рідкісна, користь не виправдовує витрати, інша команда вже її вирішила або потрібні умови недоступні.

Порівнюйте повну вартість, а не лише перший рахунок: ліцензія, налаштування, міграція, підтримка, навчання, договори, ризик постачальника, обслуговування даних і майбутні зміни. Власна розробка дає більше контролю, але створює обов'язок підтримувати її. Готова система пришвидшує старт, але може мати обмеження. Ручний процес дешевший для малого тесту, але може не витримати постійного великого обсягу.

MVP і межі першої версії

MVP (Minimum Viable Product — мінімально життєздатний продукт) — найменше повноцінне рішення, яке допомагає людині виконати важливу роботу й дає змогу спостерігати за результатом. Це не набір урізаних екранів і не дозвіл запускати ненадійний сервіс. Для запису перша версія має надійно показувати підтверджений час, не створювати подвійних бронювань і пояснювати, як перенести зустріч.

Scope — погоджений обсяг першої роботи; non-goals — те, що поки не входитиме або не перевірятиметься. Явні межі не дають списку ідей непомітно стати обіцянкою першого випуску.

Приклад обсягу для сценарію запису може включити одного типу консультацію, один календар, підтвердження бронювання, перенесення й вимірювання частки відвіданих зустрічей. Поза межами можуть бути багатолокаційна система, оцінки консультантів, програма лояльності, особиста медична картка та автоматичне виставлення рахунків. Це не універсальний шаблон і не рекомендація для реального медичного сервісу; кожну межу треба обґрунтувати контекстом, законом, ризиком і даними.

MVP відрізняється від прототипу. Прототип може бути одноразовим і непридатним для реальної роботи; він перевіряє ідею чи зручність. MVP працює з реальним процесом, тому до нього треба застосовувати вимоги до якості, безпеки, доступності, підтримки й даних. Водночас «мінімальний» означає обмежений обсяг, а не мінімальну турботу про людину.

Повністю розібраний реальний приклад. Від припущення до іншого сегмента

thoughtbot описує роботу із засновником Полом Янгом над ідеєю Tremor для продуктових команд. Перша гіпотеза була, що командам бракує контексту, тож вони будують функції замість рішень для ринку. Після сегментації, розмов і перевірки прототипу перше коло спростувало частину припущень і виявило перспективну групу, яку не обрали спочатку. Студія повідомляє про понад 30 інтерв’ю, уточнення проблеми й зміну сегмента; у її підсумку ідею описано як краще позиціоновану для залучення співзасновників та інвестицій. Кейс thoughtbot.

Послідовність роботи. Перша гіпотеза пов'язувала проблему з нестачею контексту в продуктових командах. Студія сегментувала потенційних клієнтів, записала припущення про потреби, дослідила, як люди вже передають контекст і вимоги та де звичні інструменти не допомагають. Потім сформулювала проблему й гіпотезу, підібрала учасників, створила прототип і сценарій перевірки. Перше коло спростувало частину припущень і відкрило перспективний сегмент, який спочатку не обрали; наступні розмови зосередилися на якісному дослідженні без нового прототипу. У підсумку студія повідомляє про понад 30 розмов із фахівцями, потенційними клієнтами та людьми поруч із проблемою, змінене формулювання проблеми й позицію «готові шукати співзасновників та інвестиції».

Це звіт виконавця, а не незалежна оцінка: повні нотатки, склад вибірки й фінансові дані не опубліковані. Він підтримує твердження про зміну гіпотези й наступного кроку, але не доводить, що інвестиції були залучені, що Tremor став комерційно успішним або що метод дасть такий самий результат в іншому контексті. Приклад корисний саме тим, що команда переглянула початковий сегмент замість того, щоб підтверджувати його за будь-яку ціну.

Штучний інтелект у дослідженні: помічник для доказів, не їхнє джерело

Штучний інтелект (ШІ; англ. AI — Artificial Intelligence) — назва групи комп'ютерних методів, які можуть створювати текст, класифікувати матеріал, знаходити повтори або відповідати на запитання. ШІ може допомогти впорядкувати вже зібрані нотатки, знайти суперечності й запропонувати запитання для наступної розмови. Це можливі робочі гіпотези для перевірки в обраному сервісі, а не гарантовані функції кожної моделі чи підтверджені результати дослідження:

згрупувати звернення підтримки, якщо є дозвіл на обробку й збережено контекст;
відокремити цитати від редакторського переказу, якщо кожен результат перевіряють за джерелом;
перетворити вже зібрані нотатки на список тем для подальшого порівняння;
знайти суперечності між двома наданими підсумками;
запропонувати майбутні запитання, що допоможуть перевірити припущення.

Можна попросити інструмент підсумувати документ, порівняти дві його редакції або знайти фрагменти за темою, але результат треба звіряти з першоджерелом. Цитата без перевіреного місця в записі не стає свідченням, а зручний список тем не показує їхньої частоти у всій аудиторії.

Перш ніж довіряти такому процесу, спробуйте його на невеликому знеособленому наборі: попросіть для кожної теми навести точний фрагмент і файл-джерело, позначити суперечності й явно написати «у матеріалі не знайдено», якщо підтвердження немає. Перевірте кожен фрагмент у первинній нотатці, подивіться, чи не зникли протилежні випадки та голоси окремих груп. За результатом вирішіть, чи скорочує інструмент ручний пошук без втрати контексту. Навіть Research із вебцитатами допомагає знайти джерело, але не переносить відповідальність за висновок на модель.

OpenAI й Anthropic описують роботу з файлами та дослідницькі функції в окремих продуктах. Доступ залежить від плану й налаштувань, а документація не гарантує точності: модель, яка не була на інтерв'ю, може вигадати факт, цитату чи посилання. Перевіряйте кожне узагальнення за оригіналом: OpenAI про завантаження файлів і точність ChatGPT; Anthropic про завантаження файлів, Research і помилкові відповіді.

Передавайте моделі лише ті матеріали, які дозволено обробляти в обраному сервісі. Не вставляйте без дозволу імен, контактів, медичних, платіжних чи інших конфіденційних даних. Зберігайте оригінальні нотатки й розрізняйте слова учасника, висновок дослідника та текст моделі. Людина перевіряє узагальнення й ухвалює рішення; порядок роботи з AI-чернеткою PRD наведено в главі 8.

Повністю розібраний приклад 3. Десять вигаданих відгуків

Увесь цей приклад ілюстративний. Він не описує реальні інтерв'ю або відгуки.

Ситуація. Команда ще не мала розмов із користувачами. Замовник просить AI «згенерувати десять переконливих відгуків користувачів», щоб показати, що консультації обов'язково треба бронювати онлайн. Модель створює десять правдоподібних історій: люди не додзвонилися, пропустили зустріч, хотіли перенести її або не отримали нагадування.

Помилка. Якщо команда підписує ці фрази «результат інтерв'ю», вона вигадує метод, учасників і факти. Відгуки не стають доказом навіть тоді, коли вони схожі на правдиві розповіді. Не можна наводити їх у презентації, специфікації чи оцінці попиту як голос клієнта.

Чесна дія. Команда прибирає з чернетки всі десять «відгуків» і позначає їх як синтетичні сценарії, створені моделлю. Їх можна перетворити на неперевірені питання: «Що трапляється, якщо не вдається додзвонитися?», «Як ви востаннє переносили зустріч?» і «Як дізналися, що бронювання підтверджено?». Потім команда планує справжні розмови й спостереження, перевіряє доступні дані, фіксує згоду й джерело кожного твердження та оновлює висновок.

Підсумок для замовника, написаний людиною:

«Попередні десять текстів були згенеровані моделлю. Вони не походять від користувачів і не є доказом попиту. Ми видалили їх із розділу доказів. Наразі потреба в онлайновому бронюванні не підтверджена. Наступний крок — перевірити останні випадки запису з адміністраторами й відвідувачами та порівняти їх із доступними даними. Після цього ми зможемо запропонувати, що варто перевірити далі».

Це формулювання зберігає довіру, не приховує помилку й точно вказує, чого ще не відомо. Якщо вигадані відгуки вже передали клієнту чи використали в рішенні про бюджет, виправлення має потрапити до тих самих людей і документів.

Передавання в роботу без втрати невизначеності

Висновки discovery переходять у PRD (Product Requirements Document — документ вимог до продукту). Детальну структуру розглянуто в главі 8; документ збирає рішення, очікувану поведінку й обмеження так, щоб команда могла планувати реалізацію, і не повинен перетворювати неперевірені припущення на твердження. У передаванні після discovery корисно зберегти:

Рішення і причину: будувати, придбати, інтегрувати, змінити процес, дослідити далі чи зупинитися; на які дані спиралося рішення.
Бажаний результат: кому має стати краще, який показник зміниться, який базовий рівень є і як буде виміряна зміна.
Користувачів і ролі: хто користується, хто платить, хто адмініструє, хто погоджує та чиї інтереси ще впливають на систему.
Проблему й шлях: контекст, наявні способи, труднощі, наслідки, винятки та потреби доступності.
Докази: посилання на джерела, часові рамки, вибірки й спостереження; без вигаданих цитат і цифр.
Припущення і невідоме: що ще треба перевірити, чому це важливо і який висновок може змінитися.
Чотири ризики: цінність, зручність, здійсненність і життєздатність; для кожного — наявний доказ, залишкове питання, відповідальна компетенція і наступна перевірка.
Межі: перша цільова група, сценарії в обсязі, виключення, договори, дані, доступність, безпека, зовнішні залежності й бюджетні межі.
Наступний крок: його власник, потрібний результат, строк перегляду й умова зупинитися або змінити план.

Наприклад: «Поки не розробляти власний застосунок. Для одного типу консультацій перевірити чинний календар і ручне підтвердження. Ми знаємо, що кілька каналів ускладнюють звірку, але не знаємо, чи це спричинює пропуски. Зіставити наявні дані за погоджений період і поспостерігати за перенесенням запису. Якщо чинний сервіс підтверджує запис без зайвої ручної роботи й не створює критичного ризику для приватності, порівняти його вартість із власною розробкою; якщо причина пропусків інша — переглянути гіпотезу».

Discovery триває й після випуску: зміна постачальника, процесу клініки чи складу користувачів може змінити ризики й початкову гіпотезу.

Короткий підсумок

Починайте з досвіду людей і наслідків, а не з назви функції. Розділяйте спостереження, слова учасника, висновок і припущення; перевіряйте кожен ризик відповідним методом та фахівцем. Погодьте бюджет і межі діагностики, а потім порівняйте готовий продукт, інтеграцію, зміну процесу й бездіяльність із власною розробкою. Передайте команді рішення, докази, невідоме й умови перегляду. Текст моделі не є свідченням клієнта.

Джерела та подальше читання

Посилання перевірено 23 вересня 2026 року. Вебсторінки й функції продуктів можуть оновлюватися; нижче вказано, для яких тверджень вони слугують джерелом та де проходить межа висновку.

GOV.UK Service Manual: How the discovery phase works, опубліковано 04.08.2016, оновлено 21.06.2021; User research in discovery, опубліковано 18.11.2016; Using moderated usability testing, опубліковано 21.02.2017, оновлено 03.10.2017; також Usability testing: qualitative studies, опубліковано 30.01.2020. Переглянуто 23.09.2026. Використано для переформулювання наперед заданого рішення як проблеми, методів, повного шляху користувача, нейтральних завдань і меж контрольованої перевірки. Посібники створені для державних цифрових послуг; приклади треба адаптувати до приватної студії.
John Waterworth, “User research for government services: 8 strategies that worked for us”, 21.01.2015; переглянуто 23.09.2026. Першоджерельний підсумок програми державних сервісів про участь дослідників і команди в життєвому циклі. Не використовується як універсальне правило частоти для приватної студії.
Marty Cagan, The Four Big Risks, стаття від 04.12.2017; переглянуто 23.09.2026. Це авторське пояснення ризиків цінності, зручності, здійсненності та бізнес-життєздатності й пов'язаних ролей. Стаття відсилає до Inspired; повний текст книжки тут не читався.
Teresa Torres, Everyone Can Do Continuous Discovery—Even You! Here’s How, авторський матеріал про Continuous Discovery Habits, 02.08.2023; переглянуто 23.09.2026. Використано її визначення малих регулярних активностей команди для досягнення результату як методичний орієнтир, не універсальне правило частоти.
Teresa Torres, Taking Continuous Discovery to the Next Level at SEEK, Product Talk, 10.04.2019; переглянуто 23.09.2026. Авторка описує команду, яку консультувала, та її перехід від нерегулярного discovery й приблизно п'яти-шести інтерв'ю на квартал до щотижневих інтерв'ю та явної перевірки припущень. Це самозвіт консультантки й команди, не контрольоване дослідження чи доказ причинного бізнес-ефекту.
Christensen Institute, Jobs to Be Done Theory, актуальна сторінка авторського інституту; переглянуто 23.09.2026. Використано для пояснення поступу, обставин і функціонального, соціального та емоційного вимірів. JTBD у главі — лінза для формування запитань, а не самостійний доказ потреби.
Blair Enns, The Win Without Pitching Manifesto, офіційна сторінка книжки без дати публікації; переглянуто 23.09.2026. Використано оприлюднений перелік принципів про діагностику перед рекомендацією, вибір клієнтів, ранню розмову про гроші й межі безоплатного рішення. Повний текст книжки не читався; сценарій у главі є застосуванням із власними застереженнями, а не цитатою.
David C. Baker, The Business of Expertise, авторський опис книжки без дати на сторінці; переглянуто 23.09.2026. Підтримує авторську тезу про повторюваний досвід, розпізнавання закономірностей і позиціонування. Це сторінка автора, не незалежне порівняльне дослідження; повний текст книжки не читався.
Steve Krug, Don’t Make Me Think, Revisited: A Common Sense Approach to Web (and Mobile) Usability, 3-тє видання, New Riders, 2014, 212 сторінок; [уривок, розділ 4](https://sensible.com/downloads/DMMT-Revisited-sample-chapter.pdf), переглянуто 23.09.2026. Розділ підтримує пояснення неоднозначного вибору та зайвого розумового зусилля, але не є повною книжкою. Додатково “You say ‘potato,’ I say ‘focus group’”, 22.03.2022, відрізняє спостереження за реальним користуванням від розмови про думки чи реакції на ідеї.
thoughtbot, Validating a market opportunity with product teams: Paul Young, дату публікації на сторінці не вказано; переглянуто 23.09.2026. Першоджерельний опис студії про сегментацію, зміну гіпотези й сегмента та понад 30 розмов. Компанія, що виконувала роботу, сама описує результат; повні нотатки, склад вибірки й фінансові дані не наведені, тому кейс не підтверджує інвестиційного чи комерційного успіху.
OpenAI Help Center: Uploading files and audio to ChatGPT і Does ChatGPT tell the truth?, переглянуто 23.09.2026 і повторно звірено 10.10.2026; сторінка файлів перенаправляє зі старого URL на поточний. Довідка про файли описує приклади підсумовування, порівняння документів і пошуку цитат, які можна випробувати на дозволених матеріалах; вона також просить звіряти важливі дані за оригінальним записом. Доступність залежить від продукту, плану, робочого простору й налаштувань; приклади запитів не гарантують точності результату.
Anthropic Help Center: Upload files to Claude, опубліковано 23.07.2026; Use research on Claude, опубліковано 02.06.2026; incorrect or misleading responses, опубліковано 16.03.2026; переглянуто 23.09.2026 і повторно звірено 10.10.2026. Використано для типів підтримуваних файлів і меж їхнього аналізу, Research з внутрішнім контекстом та вебом за ввімкненого пошуку й попередження перевіряти важливі твердження. Наявність цитати в відповіді не гарантує, що джерело підтримує висновок; сторінки також не гарантують повноти чи правильності аналізу.