Вайб документування вимог. Чи може ШІ назавжди змінити ваш спосіб створення документації?
- Yevhen Kliukin
- 5 бер.
- Читати 9 хв
Вступ
Генеративний та інший штучний інтелект активно та невпинно впроваджується у наше життя, у професійну буденність, стає невідʼємною частиною робочих процесів.
Бізнес-аналіз — не виняток. Зокрема, мій підхід до документування вимог за останні 6–9 місяців змінився докорінно. Якщо ще рік тому робота з AI для написання специфікацій була для мене експериментом — цікавим, але не системним — то сьогодні це просто буденність, щоденна робоча рутина. Значну частину вимог я більше не пишу у класичному розумінні — я їх надиктовую. Генеративний ШІ перетворює цю мову думок та інформації у структуровану, читабельну та придатну до роботи специфікацію.
Ця стаття — про практику, яку я називаю Vibe Documentation of Requirements як частину ширшого підходу Vibe Business Analysis — бізнес-аналізу в реальності генеративного ШІ.
Ну, а що? Андрей Карпати ввів поняття “вайб кодингу” як процес, коли ви описуєте натуральною мовою голосом, “задаючи вайб” на те, що хочете отримати, а LLM генерує потрібний код за вас і для вас. І у цій статті ви побачите, як цей принцип розповсюджується і на таке трудомістке і важливе завдання, як створення документації з вимог. Значить, у нас буде і вайб-документування і вайб-аналіз!
Як це виглядає? Я відкриваю чат і просто, голосом спілкуюся про вимоги, розказую деталі, нову інформацію, а AI-сервіс перетворює мої думки у готову специфікацію. Зі структурою, з критеріями прийняття, з потрібним рівнем деталізації.
Чому голос + AI — це зручно
Одна з ключових переваг сучасних чатів від розробників великих мовних моделей — можливість просто говорити. Не набирати текст, не форматувати, не думати про структуру речень. Ти просто розповідаєш, що має робити система, а сервіс перетворює це на структурований текст згідно з твоїми інструкціями.
Для мене основним інструментом тут є ChatGPT — і головна причина проста: він підтримує speech-to-text як англійською, так і українською мовою. Gemini та Claude поки не підтримують голос українською, але з англійською мовою комунікація і робота з ними будуються без жодних проблем.
Отже, сидячи за компʼютером, я просто натискаю мікрофон, кажу те, що маю на думці, і отримую розпізнаний текст, який далі обробляється моделлю.
Головне — сам принцип: ти говориш, AI документує. Це знімає величезний бар'єр, бо окрема рутина у документуванні — це часто не аналіз, а саме сісти й написати.
Але сам по собі голос — це лише вхід. Якість результату залежить від двох речей: правильного промпту і повноцінного контексту проєкту. Нумо розбиратися!
Готуємося: промпт для вимог, що працюють
За замовчуванням те, що генерують AI-сервіси без додаткових інструкцій — це сухо, відірвано від реальності, бракує деталей і структури. Вони не знають ваших стандартів якості. Поки ви їх не навчите.
Щоб наш цифровий асистент генерував якісні специфікації, а не просто «щось схоже на вимоги», потрібна підготовка. І перше, що має бути готове — це промпт, який описує фінальну структуру вимоги. По суті, це ваш шаблон, ваш стандарт якості.
Ось як виглядає приблизно структура, яку я використовую:
1. Загальний вступ — кілька речень, які пояснюють, про що ця функція. Певний контекст для того, хто читатиме специфікацію вперше.
2. Користувацька історія — сам зміст користувацької історії у класичному форматі. Who / What / Why — хто є користувачем, що саме він хоче зробити і навіщо. Це допомагає тримати фокус на цінності.
3. Критерії прийняття — і це найскладніша частина, яка заслуговує окремої уваги.
Що має бути в Acceptance Criteria
Для мене критерії прийняття — це чіткі очікування від системи, продукту чи функції, яку ми будуємо. Не абстрактне «система має працювати коректно», а конкретний опис того, що ми хочемо бачити на виході. З яких частин вони складаються:
Предметні деталі — назви полів, конкретні значення, формати даних
Логіка поведінки — що відбувається при певних діях, умови, розгалуження
Навігація — як користувач потрапляє в інтерфейс і як з нього виходить
Дані — які дані відображаються, звідки вони беруться, як оновлюються
Права доступу — хто має доступ до функціональності та на яких умовах
Граничні випадки — що відбувається при помилках, порожніх даних, нетиповій поведінці
Вимоги за межами обсягу (Out of Scope) — що ми тут точно не покриваємо
Але тут виникає закономірне питання: а як саме думати про ці деталі системно, щоб нічого не пропустити? Для цього я розробив фреймворк специфікації вимог — мисленнєву модель, яку детально описав у серії постів на своєму Телеграм-каналі. Це не шаблон документа, а скоріше чекліст для мислення — про що варто подумати, коли деталізуєш вимоги. Коротко про п'ять груп елементів:
Списки — таблиці перегляду та селектори вибору. Думаємо про джерело даних, сортування, групування, пагінацію, можливість експорту.
Поля — базовий будівельний блок інтерфейсу. Думаємо про тип даних, значення за замовчуванням, обмеження введення, валідації та повідомлення про помилки.
Групи — контейнери, що об'єднують елементи: форми, секції, сторінки, попапи. Думаємо про навігаційний шлях, умови відображення, стани, empty state.
Фільтри та пошук — механізми звуження даних. Думаємо про тип фільтра, значення за замовчуванням, залежності між фільтрами, логіку комбінування.
Функціональна логіка — як все взаємодіє: навігація, тригери (ручні й автоматичні), логіка обробки (CRUD, зміни статусів, бізнес-правила), імпорт/експорт.
Цей фреймворк — не список для галочки, а спосіб думати про вимоги системно, не пропускаючи важливого.
І все це можна і потрібно закласти у промпт. Чим детальніше ви опишете структуру очікуваного результату — тим ближчим до фінального вигляду буде те, що згенерує AI. Значну частину цих інструкцій я тримаю у користувацьких інструкціях (Custom Instructions) відповідного GPT (або Gem). Таким чином, я не просто уникаю повторення інструкцій (які кожен раз вставляти чи проговорювати було б, мʼяко кажучи, неефективно), а й отримую потрібні відповіді у одразу очікуваному форматі щоразу, коли “спілкуюся” з ШІ.
Контекст — ключ до якості
Промпт із структурою — це лише половина успіху. Друга половина — це контекст.
Коли ми говоримо про Custom GPT, Gem або автоматизацію через API — критично важливо, щоб інструмент був наповнений контекстом проєкту. Без цього AI буде вгадувати, додумувати, «галюцинувати» — і ви витратите більше часу на виправлення, ніж заощадите на генерації.
Що таке контекст у цьому випадку?
Це не пара речень «ми робимо CRM для малого бізнесу». Це повноцінний опис проєкту, який може включати:
BRD, Solution Vision або ж Business Case — загальне бачення рішення, його межі, ключові модулі, обмеження тощо
Первинний список вимог: верхньо- і середньорівнева структура, декомпозиція на епіки та фічі
Залежності, компоненти та інтеграції — системи, з якими продукт взаємодіє та обмінюється даними.
Сама задача початкової декомпозиції та визначення обсягу, створення загальних документів є рівнем вище, а також має бути вирішена раніше, до старту проєкту. Тут ми говоримо про ситуацію у фазі безпосередньої розробки, коли загальний обсяг вже визначений, і ваша задача — деталізувати конкретні користувацькі історії у повноцінні специфікації. Однак якось я на одному прісейлі сидів 2 години, надиктовував, що відбувається на 700 скрінах дизайну замовника (все, що було у нього на руках), і отримав дуже якісну декомпозицію — тож і тут вайб-документування працює.
Загалом, чим якісніший контекст ви надаєте AI — тим менше ітерацій знадобиться, щоб отримати результат, який можна одразу брати в роботу.
Поради щодо роботи з контекстом
Недостатньо просто завантажити документи в Custom GPT — важливо, щоб AI міг ефективно з ними працювати.
Змістовна сторона:
Структуруйте документи чітко — використовуйте заголовки, нумерацію, розділення на секції. AI значно краще орієнтується у документі з логічною ієрархією, ніж у суцільному потоці тексту.
Називайте сутності однаково — якщо у документі-джерелі модуль називається «управління користувачами», не називайте його у розмовах під час роботи з вимогами «модуль користувачів». Консистентність термінології зменшує «галюцинації», “непорозуміння” при генерації контенту.
Тримайте контекст актуальним — застаріла інформація часто гірше, ніж її відсутність. Якщо вимоги змінились, оновіть контекст, інакше AI генеруватиме специфікації на основі неактуальної інформації.
Не перевантажуйте — якщо завантажити все одразу (150 сторей, протоколи 20 зустрічей, листування), AI може «загубитися» у пріоритетах. Краще дати основне ядро контексту (візія + обсяг + структура вимог), а деталі додавати вже в конкретних розмовах.
Додайте глосарій — навіть короткий список ключових термінів проєкту з поясненнями суттєво покращує якість генерації, особливо якщо у проєкті є доменна специфіка.
Технічна сторона:
Формат має значення — прості текстові формати (.md, .txt) працюють краще, ніж складні .docx чи .pdf з таблицями та вкладеннями. Якщо у вас документація у Confluence чи Google Docs — експортуйте в Markdown перед завантаженням.
Контролюйте розмір — у кожного сервісу є обмеження на обсяг контексту (так зване «вікно контексту» або context window). Якщо документ завеликий, AI може просто проігнорувати його кінець. Краще розбити один великий документ на кілька логічних частин, ніж завантажити монолітний файл на 100 сторінок.
Виділяйте пріоритетну інформацію — те, що стоїть на початку документа чи розмови, AI зазвичай «пам'ятає» краще. Розміщуйте найважливіше — глосарій, ключові бізнес-правила, обмеження — ближче до початку.
Використовуйте розмітку — заголовки, списки, роздільники, markdown-форматування допомагають AI розрізняти секції та швидше знаходити релевантну інформацію. Можна навіть додавати мітки на кшталт [SCOPE], [GLOSSARY], [RULES] для навігації.
Оптимізуйте токени — вікно контексту вимірюється у токенах, і їх кількість обмежена. Використовуйте лічильники токенів (наприклад, від OpenAI), щоб розуміти, скільки «місця» займає ваш контекст. Очищуйте текст від зайвих слів, скорочуйте де можливо (наприклад, «&» замість «and»), прибирайте надлишкове форматування. Це як рефакторинг коду — прибираєте шум, залишаєте суть. Але тримайте баланс: контекст має залишатись читабельним для вас, бо його ще потрібно підтримувати та оновлювати.
Тестуйте, що AI «бачить» — після завантаження контексту поставте кілька перевірочних запитань: «Які модулі є в проєкті?», «Що означає термін X?». Якщо відповіді неточні — контекст потребує доопрацювання.
Виявлення
Варто трохи згадати про обробку результатів виявлення.
Інтеграція зустрічей з виявлення вимог — на момент написання статті ми поки що не дійшли до повної автоматизації інтеграції мітингів у процес генерування вимог. Але якщо ви транскрибуєте вимоги чи пишете протоколи вручну (мушу визнати, що сучасні сервіси вже навчилися це робити і робити якісно), наразі вистачає ctrl+c/ctrl+v цієї інформації для необхідного оновлення тої чи іншої специфікації вимог. Наші зустрічі БА часто покривають інформацію кількох вимог, сторей, специфікацій чи навіть епіків одночасно. Тут я є прихильником напівручного введення, тобто я генерую список ключових домовленостей та змін і потім шукаю тільки те, що релевантне для конкретної вимоги і прошу це інтегрувати.
Так само ви можете інтегрувати переписки з цими ж зацікавленими сторонами.
А якщо говорити про “вайб документацію”, то мій сценарій — я перечитую власні нотатки, кажу своєму ШІ-чату “слухай, була зустріч з X та Z, вони сказали, що … — інтегруй цю інформацію у вимоги”, а він змінює те, що треба.
Якщо ж нам потрібно інтегрувати у вимоги певну документацію — тут поки що складнувато, адже документи часто є великими та й мають багато того, що вам не потрібно для вашої специфікації. Якщо ви не можете щось надиктувати звідти, то рекомендую попрацювати з документами окремо. NotebookLM ідеально підходить для огляду великих документів і відповідає на запитання чітко в межах завантажених файлів.
Конфіденційність та приватність
Робота з AI-сервісами вимагає усвідомленого підходу до даних, які ви передаєте. В залежності від ситуації маємо на озброєнні три прості правила:
Користуватися корпоративними ШІ-сервісами — практично всі популярні провайдери рішень на основі LLM надають для компаній спеціально адаптовані рішення, що гарантують приватність та безпеку даних, захист від навчання моделей на цих даних.
Уникати розміщення у ШІ-чатах дані, що мають певний рівень унікальності (продукти чи особливості, яких практично немає на ринку), зберігають комерційну таємницю (ціни, списки контрагентів тощо), або містять персональні дані (клієнтів, користувачів) або просто є критичними для безпеки ваших інформаційних систем (API-ключі, паролі). Важливе застереження: навіть якщо ШІ-компанії гарантують вам захист інформації, ніхто не гарантує, що завтра їх зламає купка хакерів і таки дістанеться до неї.
Анонімізувати дані. Як і раніше, це особливо актуально у ваших приватних акаунтах ШІ-сервісів. Не використовуйте реальні назви компаній, продуктів, людей тощо. Заміняйте їх на “Продукт А”, “спонсор продукту - Тарас Шевченко” (якщо його звісно реально так не звати))
Сіра реальність
Звісно, нікуди не зникають галюцинації та непотрібний контент у відповідях. Часто опісля отримання вимог я надиктовую зміни. Тут варто точно пояснювати, що саме потрібно змінити і де в уже сформованих вимогах.
Gemini, наприклад, сприймає мої інструкції занадто буквально, переписуючи всі вимоги замість одного шматка (і затираючи гарно початково сформулювані ним вимоги). ChatGPT ж робить зміни “точково” за моїми голосовими командами — тут лайк.
Але інколи розуміння не приходить, і легше щось дописати самому. Інколи діалог заходить не туди — ШІ “пливе”, втрачає контекст, розуміння понять і генерує дивні речі. На щастя, це стає все рідше і рідше з розвитком моделей.
ШІ все ще помиляється. Наприклад, я попросив ChatGPT видалити блок критеріїв прийняття після того, як ми перенесли його вміст в інший розділ. GPT видалив, але кілька пунктів не переніс. Я це помітив лише по одному з них, а перевіряти довелося всі двадцять. То ж будьте пильними з цими пройдисвітами)
А ще прогрес не стоїть на місці, і багато ще проблем буде вирішено — наприклад, файли інструкцій/«скіли» типу claude.md.
Висновок
Отже, чи може ШІ назавжди змінити спосіб створення документації? Так — але не замість вас, а разом із вами. Vibe Documentation — це не про делегування мислення машині — це про прискорення формалізації думки, зміну підходу до взаємодії з комп'ютером. Ви все ще відповідаєте за рамку, за структуру, за повноту, за здоровий глузд і за бізнес-цінність. Але замість того, щоб витрачати енергію на механічне написання, ви концентруєтеся на аналізі, уточненнях, рішеннях. ШІ не знімає відповідальність бізнес-аналітика — він підсвічує, де ця відповідальність справді лежить. І якщо навчитися працювати з ним системно — з промптом, контекстом і дисципліною — документування перестає бути виснажливою рутиною і стає швидким, майже розмовним процесом мислення.
А як ви зараз документуєте вимоги — і чи пробували вайб-підхід?
Новини та статті з бізнес-аналізу:
