Трансформація естимації тестування з появою АІ

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Привіт, наш любий зацікавлений читач 🙌

Це знову я, Аня. Якщо ти читав мої попередні статті, то ти вже знаєш, що я люблю розбирати процеси до гвинтиків і збирати з них щось робоче. Але сьогодні мова піде не про промпти і скіли, а про АІшки в нашому житті 🙂
Сьогодні ми поговоримо про естимацію. А конкретніше про те, як AI змінив правила оцінювання настільки, що наші звичні підходи припинили працювати. Да-да, «а раніше було краще» — то може і так, але новий світ встановлює нові правила. Тож разом з тобою ми подумаємо над трансформацією вже традиційного для нас процесу естимації.
Перш ніж зануритися, давай пригадаємо трошки історії з якої все починалося.

⚠️ це буде дуже довга стаття, тому врахуй свої сили, а також зауваж що тут не буде мого звичного стилю викладання задля еокномії букав і твого часу⚠️

Story points: від задуму до сьогодення

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

1. Обсяг роботи — скільки сценаріїв, скільки перевірок, скільки середовищ.
2. Технічна складність — наскільки заплутана логіка, скільки інтеграцій задіяно, наскільки критичний функціонал, який вплив йде на систему та інше.
3. Невизначеність — наскільки зрозумілі вимоги, чи є залежності від інших команд, чи є ризик що скоуп зміниться.

Традиційно вимірювання складності було і є по шкалі Фібоначчі (1, 2, 3, 5, 8 і тд).
Принцип оцінювання задач полягає в тому, що задача на 8 поінтів не просто «трохи більша» за 5: зі зростанням оцінки зазвичай зростають невідомі, ризики та кількість взаємозв’язків.

Як вони поступово злились з часом?

Протягом часу цей підхід трошки розмився і переріс в оцінювання складності часу на виконання задачі. Або в оцінювання складності через статистику витрат часу і навпаки. Так або інакше, на практиці SP дуже часто починають пов’язувати з часовитратами.
Умовно, коли команда працює кілька спринтів, у неї з’являється статистика: «ми закриваємо 25 SP за спринт». Менеджер рахує: 5 людей × 10 днів 25 SP, отже 1 SP ≈ 2 людино-дні.
У частині традиційної manual QA-роботи окремі активності справді зручно рахувати лінійно: наприклад, 20 тест-кейсів × 30 хв 10 год. У стабільному процесі це могло створювати сильну практичну кореляцію між complexity, обсягом ручної роботи та часовитратами.
Таке поєднання не обов’язково було помилкою або знущанням над SP, воно часто працювало як практична адаптація в стабільному процесі, особливо коли основна частина роботи виконувалась людиною послідовно і способи виконання задач мало змінювались.

💡 Інсайт: Я б трохи гучно сказала, що з часом Story points перетворились на такий собі proxy для часу. Поки виконавець і процес були стабільними це працювало.

І шось таки сталося з цим підходом із появою AI?

Я бачу, що AI розірвав цю кореляцію. Складність задачі не змінилась, це так. Вона все ще зачіпає ті ж модулі, має ті ж сценарії і ті ж ризики, і так само оцінює складність.
Але чи може execution тепер виглядати зовсім інакше? Тих самих 20 тест-кейсів на які потрібно було умовно 8 год, тепер за хвилини може згенерувати АІ, чим економить дорогоцінний ресурс людини. Аналіз вимог на повноту AI теж може виконати за хвилини і знов виходить економія часу людини.
Що виходить? SP і complexity залишаються тими самими, а execution time та human load уже можуть бути зовсім іншими. І що відбувається на тих самих грумінгах або плануваннях, або ретро?
Через зменшений час виконання та змінене людське навантаження сама оцінка complexity може почати ставитися під сумнів: команда бачить, що подібна за SP задача тепер проходить значно швидше, і мимоволі починає змішувати complexity з execution time.
Відбувається така собі подвійна підміна: ставимо «8 SP» бо складність реально тягне на 8, але ж «чи точно „8 SP“, бо ми минулого разу ми подібну задачу закрили за день?». Знайомо?

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

✏️ Рахуватимемо саме зі сторони тестування, використовуючи стандартні та класичні процеси.

Одна задача: три виконання

Задача:

Нова функція фільтрації замовлень в адмін-панелі. Фільтри:

• за статусом (5 статусів),
• за діапазоном дат,
• за діапазоном суми.
  Комбіновані умови.
  Зачіпає:
• UI (форма фільтрів, таблиця результатів),
• API (нові query-параметри),
• базу даних.
  Суміжний функціонал: пагінація, сортування, експорт.

По складності оцінимо її як 5 story points, хай буде таким чином:

Скоуп тестування: однаковий для всіх трьох прикладів, адже задача та сама.
Артефакти: дерево вимог, матриця покриття, чекліст тестування, 54 тест-кейси, багрепорти (орієнтовно 6), тест-репорт.
Активності: грумінг, дерево вимог, матриця покриття, чекліст, тест-кейси, виконання тестів, E2E проходження, багрепорти, ретест багів, регресія суміжного функціоналу, тест-репорт.
Розподіл тест-кейсів:

Як змінюється виконання задачі:

Для прикладу порівняння візьмемо один і той самий шматок роботи: написання 54 тест-кейсів з таблички вище.

Ось тут, тільки на цьому шматочку роботи, вже чудово видно перший зсув: complexity тестового scope не змінилась, але спосіб виконання роботи змінився.
При цьому AI не обнуляє human time — creation переходить до агента, а людина витрачає час на review, verification і rework.

💡 Інсайт: AI змінює не складність, а структуру навантаження. Замість акценту на створення — акцент на верифікацію.
Продовжимо порівняння і подивимося, як змінюється виконання тестів.

Test execution & defect cycle:

В цей блок у нас входять виконання тестів, E2E, багрепорти, ретест і наша улюблена регресія.

Зведене порівняння:

Так, ти абсолютно вірно розумієш. Задача та сама, scope та complexity ті самі, а от execution reality у них зовсім різні. І Human Active Time теж звісно різні: 35 год 35 хв → 24 год 05 хв → 10 год 45 хв.

💡 Інсайт: Одні й ті самі 5 SP, а людське навантаження відрізняється втричі. Це і підводить до думки що одне число більше не описує реальність.

Яке моє бачення оновленого підходу до естимації

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

Що змінилось фундаментально?

Раніше ми оцінювали обсяг людської роботи. Тестувальник прикидав кожну свою дію, множив на кількість, рахував години, аргументував навантаження. Одна людина один потік роботи.
Час дорівнює зусиллю, зусилля дорівнює навантаженню. Одне число описує все.
Тепер задачу тестують «в парі» — тестувальник і його персональний джун. Вони між собою діляться роботою і навантаженням. Відповідно варто і чесно вимірювати навантаження обох учасників, правда ж? Час виконання та вартість кожного причетного до задачі. Так би мовити «С — справедливість».

Як трансформувалось навантаження людини?

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

• Думаємо над передумовами які дані мають бути в системі
• Формулюємо кроки (відкрити сторінку, вибрати статус, натиснути Apply і тд)
• Описуємо очікуваний результат (в таблиці тільки замовлення зі статусом «Новий» і тд)
• Перечитуємо, правимо формулювання

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

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

• Читає передумови чи правильно AI зрозумів контекст системи? Чи не вигадав неіснуючий статус?
• Перевіряє кроки, чи відповідають реальному UI? Чи не пропущено крок?
• Оцінює очікуваний результат, чи достатньо конкретний? Чи враховано пагінацію?
• Вирішує: прийняти, скоригувати чи переписати

Рев’ю одного такого простого кейсу разом із дрібними фіксами може зайняти приблизно десь 5–10 хвилин.
Але важливіша тут не сама цифра, а зміна фокусу.
Зосередження людини змінено. Тепер це акцент на валідації. Людина не створює, вона сапортить, оцінює і приймає рішення.

Часовитрати можуть коливатися, зменшуватися або збільшуватися, але навантаження точно змінилось.
Не варто впевнено стверджувати, що навантаження однозначно зменшилося або збільшилося, його структура просто стала іншою.
Фокус зі створення перейшов на валідацію і верифікацію. А це теж має свою специфіку: це вимагає критичного мислення, знання контексту та уваги до деталей які AI міг пропустити чи вигадати.
Тому я вважаю, що формула людського навантаження тепер складається з інших компонентів:
Effective Human Load Creation Execution Supervision Verification Investigation Rework

• Creation — створення артефактів або аналізу з нуля;
• Execution — пряме виконання тестових дій людиною;
• Supervision — нагляд за AI і корекція напряму роботи;
• Verification — review та валідація створених артефактів або результатів виконання;
• Investigation — exploratory/judgment-heavy робота, яку в конкретному контексті залишаємо людині;
• Rework — повторна робота після виявленої проблеми в результаті.

💡 Інсайт: Раніше переважна частина часу йшла на Creation та Execution. Тепер фокус зміщується до Verification та Investigation. Формула та сама, але пропорції вже зовсім інші.

Доречі схожий зсув видно і в матеріалах DORA (DevOps Research and Assessment, дослідницька програма Google Cloud): AI може прискорювати creation, але частина зекономленого часу перерозподіляється в auditing та verification.

А що тоді можна вважати навантаженням агента?

Для агента я б не використовувала той самий термін «навантаження», що і для людини. Кількість делегованих тест-кейсів або відсоток задач, які виконав AI, не показують людську capacity і не є аналогом EHL.
Для execution system важливіше окремо бачити:

• Machine Execution Time — скільки wall-clock часу агент реально виконував делеговану роботу;
• AI Leverage — яку частину цього типу роботи в принципі можна делегувати;
• Human Active Time / EHL — скільки людської capacity все одно спожила задача;
• Flow Time — скільки календарно зайняв спільний Human Agent process.

Тому ситуація «людина написала 5 кейсів і агент написав 5 кейсів» не дорівнює тому що їхнє навантаження 50/50. Один і той самий output може мати зовсім різну вартість у human time, machine time та verification.
Давайте спробуємо порівняти навантаження на прикладі одного тест-кейсу:

Ми отримуємо окремо час людини і окремо час агента. Але ці числа все одно не можна просто приплюсувати, тому шо частина роботи може виконуватись паралельно. Тому для нової моделі нам потрібні окремі Human Active Time, Machine Execution Time та Flow Time.

AI leverage: не всі задачі однакові для AI

А ось тут стає видно чому story points остаточно відриваються від часу. Дві задачі можуть бути однакові за складністю, обидві 5 SP але мати абсолютно різний AI leverage. Про що я кажу?
Задача з високим AI leverage:

• Стандартна CRUD логіка
• Детерміновані перевірки
• Багато structured context
• API з документацією
• Типова регресія

Для порівнюваного scope AI може забирати значну частину структурованої роботи, тому EHL може бути нижчим.
А задача з низьким AI leverage:

• Новий UX без аналогів
• Нечіткі вимоги
• Складні cross-system ефекти
• Потрібно exploratory testing
• AI постійно потребує корекції

Для порівнюваного scope більша частина роботи буде залишатися за людиною, тому EHL може бути вищим.

AI Tax: ціна використання AI

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

• AI Tax це людський час, який з’являється саме через використання AI: supervision, AI-specific verification та rework.
• Human cost with AI / EHL це весь активний людський час у AI-сценарії. Він може включати і AI Tax, і роботу, яку AI не виконує та яка залишається за людиною, наприклад Investigation.

Тому можна провести таку тотожність:
Net AI Gain Manual baseline — Human cost with AI (EHL).
Для кращого розуміння давай подивимося ще один приклад на тест-дизайні нашої задачі де повне залучення AI:

≈66% це наша економія саме людського часу в цьому прикладі. Тут AI Tax Human cost with AI, тому що вся людська робота в цьому конкретному шматку складається з verification та rework.
А тепер подивимося на виконання тих самих тестів з повним AI. Там картинка вже інша: Manual baseline = 11 год 50 хв, AI Tax (verification результатів) = 1 год 35 хв, але Human cost with AI = 2 год 35 хв. Чому різниця? Бо ще 1 година припадає на Investigation UI/UX перевірку, яку ми залишаємо людині через візуальний та продуктовий judgment.
Це не «податок» за AI, це робота, яку AI просто не виконує. Net AI Gain при цьому = 9 год 15 хв (≈78%).
Різні етапи, різний AI leverage, різний реальний gain, а одне число не описує нічого.

⚠️ Важливо: AI Tax і Human cost with AI це не одне й те саме.
AI Tax — це тільки overhead від використання AI (supervision verification AI-output rework).
Human cost — увесь активний людський час, включно з Investigation та іншою роботою, яку AI не виконує.

Зсув боттлнеку:

Є ще одна фундаментальна зміна. Раніше QA pipeline виглядав так:
Analyse → Design → Execute → Regression → Report
У багатьох manual-heavy QA-процесах Execute був одним із найдорожчих етапів, тому автоматизація тестів стала одним із головних інструментів оптимізації.
В AI-assisted процесі з’являється інший патерн: AI automation скорочують частину прямого Execute, а боттлнек може зміщуватися:
Context → Decision → Verification → Investigation
Коли значна частина детермінованого execution переходить до агентів, основна частина людської QA-capacity може зміщуватися від прямого виконання до judgment оцінки, рішень і валідації.

Доречі, DORA також бачить схожу картину: AI пришвидшує виробництво роботи, але додатковий output створює більше потреби в review та verification.

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

Розумю, шо ти вже трохи втомився вдумуватися в усі ці букави і цифри. Обіцію, залишилося лише головне 🙂

Модель: від одного числа до профілю задачі

Замість одного звичного числа story points задача тепер має профіль з кількох незалежних характеристик.
Важливо: story points тут не є початком формули, яка переводить complexity у години. Вони залишаються окремою історичною характеристикою складності, а EHL і Flow Time прогнозуються з поведінки подібної роботи в конкретній execution system.
У моделі є три основні результуючі осі:

Окремо враховуються характеристики execution context:

• AI Leverage — наскільки цей тип роботи піддається делегуванню AI;
• Risk / Confidence — які фактори можуть змінити прогноз і наскільки ми йому довіряємо.

⚠️ AI Leverage і Risk / Confidence не є четвертою та п’ятою оцінками задачі. Вони допомагають пояснити й прогнозувати EHL та Flow Time.

Знов на наших «кошенятках» розглянемо наочність:
Без AI:

Часткове AI:
У часткового AI формула EHL та сама, але його структура інша: AI допомагає з текстовою документацією (драфти ТК, багрепорти), а виконання тестів залишається за людиною.
Для цього прикладу EHL зручно показати двома блоками:

У Partial AI Human Active Time уже не дорівнює автоматично Flow Time: генерація AI може відбуватись окремо або паралельно з людською роботою, тому без повного timeline конкретне значення Flow Time тут не задаємо.
Повне AI:

Компоненти EHL тут не обов’язково є взаємовиключними на рівні кожної хвилини: у реальній роботі одна активність може одночасно містити елементи supervision, verification або rework. Для прикладу ми відносимо час до домінуючої функції, щоб не подвоювати його.
Подивися тепер на EHL: з 10 год 45 хв людського часу 8 год 25 хв = verification. Це близько 78% людської роботи — перевірка того що зробила машина.

На мій погляд це демонстрація того самого зсуву боттлнеку в дії.
І ось тут якраз добре видно парадокс нового світу:

У цьому прикладі 5 SP задача має більший EHL, ніж 8 SP. Це не суперечність: SP описують complexity, а EHL — людську capacity, яку реально споживає execution.

Чого ця модель не робить?

Наша модель не змішує SP та год. Стара логіка виглядала приблизно так: SP → приблизний час
У цій же моделі forecasting будується інакше: Work Profile execution context historical behaviour → EHL / Flow Time
Наприклад:

Тому historical base не варто будувати як таблицю SP AI Leverage X годин. Корисніше накопичувати фактичну поведінку повторюваних Work Profiles у своїй execution system і вже від неї прогнозувати EHL та Flow Time.

Від оцінки до прогнозування

А що далі з усією цією інформацією?

Story points продовжують відповідати на питання «наскільки складна задача», EHL і Flow Time прогнозуються окремо, на основі характеру роботи, execution context та історичної поведінки подібних Work Profiles.
Для capacity planning потрібен Effective Human Load. Для прогнозування термінів — Flow Time.
Machine Execution Time використовується всередині розрахунку Flow Time, але не є окремою оцінкою задачі.
Risk / Confidence не створює ще одну оцінку задачі.
Це контекст прогнозу: для знайомого Work Profile з доброю історією confidence буде вищим. Для нової інтеграції, нечітких вимог або великої кількості залежностей — нижчим, а прогноз доцільно давати ширшим діапазоном.

Як рахувати оцінку в новій моделі

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

• Human Active Time / EHL = скільки часу людина реально була зайнята роботою: аналізувала, виконувала, перевіряла, виправляла, приймала рішення.
• Machine Execution Time = скільки wall-clock часу агент реально виконував свою частину роботи.
• Overlap Time = час, коли людина і агент працювали паралельно.
• Waiting / Handoff Time = час, коли попередній етап уже завершений, але наступний виконавець ще не почав роботу.

Flow Time тут є результуючою величиною, повним календарним часом від старту активності до готового результату.
Ключове правило нової моделі: Human Active Time Machine Execution Time не дорівнює Flow Time, якщо робота хоча б частково виконується паралельно.
Приклад: 10 тест-кейсів батчами
Агент працює пакетами по 5 кейсів. Після того як перші 5 готові, він переходить до наступних 5, а тестувальник вже починає перевіряти першу частину.

І шо ми таки отримуємо?

• Machine Execution Time 10 хв
• Human Active Time 10 хв
• Overlap Time 5 хв (інтервал 5-10 хв, людина і агент працюють одночасно)
• Flow Time 15 хв

Якби ми просто склали час людини і агента, отримали б 20 хвилин і завищили б реальний календарний час. Насправді 5 хвилин роботи виконувались одночасно.
Для простого activity це можна описати формулою: Flow Time Human Active Time Machine Execution Time — Overlap Time Waiting / Handoff Time
Waiting / Handoff Time = час, коли попередній етап уже завершений, але наступний виконавець ще не почав.
Наприклад, агент завершив о 10:00, а тестувальник зміг почати лише об 11:30 — ці 1.5 години задача просто стояла. Навіть якщо AI дуже швидко виконує свою частину, delivery може залишатись повільним через черги на людську увагу.

Як рахувати складну задачу?

Для цілого тікета формула з Overlap вже стає занадто спрощеною, тому що в реальності можуть бути ланцюжки Human → AI → Human → AI, кілька паралельних потоків, повторні запуски, блокери та очікування.
Тому на рівні всієї задачі Flow Time треба рахувати через critical path — послідовність залежних кроків, яка фактично визначає календарну тривалість задачі.
Тобто ми не сумуємо весь час усіх учасників. Ми дивимось, які кроки були залежними, які йшли паралельно, де виникли очікування, і рахуємо найдовший фактичний шлях від старту до завершення.
Для розрахунку EHL і Flow Time ми використовуємо кілька робочих величин:

Саме це і є практична різниця нової моделі. Ми перестаємо намагатись втиснути складність, людське навантаження і календарний час в одне число.
Machine Execution Time, overlap і waiting/handoff тут не є окремими оцінками задачі — це величини, потрібні для розрахунку Flow Time.

Flow Time для основного прикладу

А тепер найцікавіше. Застосуємо щойно описаний підхід на практиці. Розрахуємо Flow Time для сценарію «Повне AI», де паралельна робота людини й агента найвиразніша.

Де виникає паралельність:
Фаза виконання тестів. Поки агент виконує сценарії через браузер та API (1 год 40 хв), тестувальник паралельно проводить ручну UI/UX перевірку (1 год) — judgment-heavy роботу, яку залишаємо людині або починає верифікувати результати вже завершених груп тестів (35 хв).

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

Overlap у кожній фазі:

• Test design: агент генерує наступні батчі тест-кейсів, поки людина ревʼюває попередні.
• Execution: агент виконує тести, поки людина проводить UI/UX перевірку і верифікує завершені групи.

Порівняння Flow Time для трьох сценаріїв:

Без AI Flow Time EHL, бо вся робота послідовна й виконується однією людиною.
У сценаріях із AI Machine Execution Time додає до Flow Time лише ту частину, яка не перекривається людською роботою: 5 хвилин для часткового AI, 10 хвилин для повного AI.
Реальний Flow Time буде вищим за рахунок Waiting / Handoff Time: очікування фіксів від розробки, черги на середовища, контекстні перемикання.
Наприклад, 2 години очікування на фікс багів додають 2 години до Flow Time будь-якого сценарію.

Що це показує?
Для окремої задачі машинна швидкість майже не впливає на календарний час — критичний шлях проходить через людську верифікацію. 2 години машинної роботи додали лише 10 хвилин до Flow Time, бо решта виконувалась паралельно з людиною.
Реальний виграш від швидкості агента проявляється не в Flow Time однієї задачі, а в capacity: менший EHL на задачу означає, що одна людина може обслуговувати більше задач за той самий період.

💡 Інсайт: Агент працював 2 години, але додав лише 10 хвилин до Flow Time. Решта йде паралельно з людиною. Швидкість агента окупається не на одній задачі, а на масштабі: менший EHL більше задач на людину.

Як команда може накопичити власну базу для прогнозування з таким підходом?

✏️ Це не єдина правильна схема, а приклад того як може бути.

Команда може згрупувати повторювані типи роботи у власні Work Profiles і поступово накопичувати для них фактичні EHL, Flow Time, AI Leverage та, за потреби, Waiting / Handoff Time або структуру EHL.
Наприклад, профілями можуть бути: existing API change, new UI flow, cross-system integration, regression-heavy change, exploratory feature.
Конкретний набір залежить від продукту і процесу команди.
Приклад: як із завершених задач може з’явитися historical baseline:
Припустимо, команда вже бачить повторюваний профіль Existing API change з High AI Leverage і вирішує подивитися на фактичну історію завершених задач цього типу.
Для простоти візьмемо 10 умовних спостережень і вже відсортуємо їх:

• EHL: 40, 45, 45, 50, 50, 55, 60, 80, 90, 100 хв.
• Flow Time: 60, 65, 70, 75, 80, 90, 100, 130, 150, 180 хв.

Для простого прикладу візьмемо nearest-rank (найпростіший метод розрахунку перцентилів: сортуємо за зростанням і беремо елемент на позиції ⌈P/100 × N⌉): для 10 значень P50 — 5-те значення, P80 — 8-ме. Тоді для цього Work Profile виходить:

• EHL P50 50 хв, EHL P80 80 хв;
• Flow P50 80 хв, Flow P80 130 хв.

Після накопичення історії база профілів може виглядати, наприклад, так:

Новий тікет тоді не оцінюється повністю з нуля. Якщо він справді схожий на вже відомий Work Profile, historical baseline стає стартовою точкою: P50 може показувати типовий сценарій, а вищий percentile більш консервативний planning forecast.
Якщо конкретна задача помітно відрізняється за ризиком, новизною або залежностями, краще не додавати вигаданий коефіцієнт на кшталт 30% за ризик.
Команда може знизити confidence, дати ширший діапазон або віднести таку роботу до іншого профілю, якщо історія показує, що вона поводиться інакше.
Якщо історії ще немає, можна почати з expert judgement і явно позначати такі прогнози як low confidence, а потім поступово замінювати припущення фактичними даними.
Також і планування спринту, то це вже не просто набрати приблизно звичну кількість SP у звичний проміжок часу.
Планування тепер фокусується на профілі кожної задачі та на прогнозі очікуваного людського навантаження й календарного часу.
Velocity в SP все ще може залишатися корисним історичним командним сигналом темпу роботи, але це не throughput. Для capacity planning у цій моделі використовується EHL, а для forecasting — історичні Flow Time.
Фактично команда отримує емпіричну AI-adjusted capacity model замість вигаданого коефіцієнта «AI збільшує продуктивність на 40%».

Як фіксувати EHL на практиці?

Принцип достатньо простий: фіксуй активність, а категоризуй потім
Не потрібно перемикати таймер між Supervision і Verification кожні 5 хвилин. Достатньо фіксувати що саме ии робив і скільки часу це зайняло на рівні природних робочих блоків, періодів, коли ти робив одне й те саме: ревʼю тест-кейсів, ручне тестування UI, виправлення кейсів після ревʼю, дослідницьке тестування.
Категоризацію по EHL-компонентах можна робити після завершення блоку або наприкінці дня.

Що варто фіксувати?
Приклад набору на один робочий блок:

Чого не треба трекати вручну?

• Machine Execution Time — отримується з логів агента або інструментів автоматизації.
• Overlap — видно з timeline: коли агент працював одночасно з людиною. Для більшості задач достатньо приблизної оцінки після завершення.
• Waiting / Handoff — фіксується як окремий запис: «задача чекала на фікс від dev — 2 год», «черга на staging — 40 хв».

Як це перетворюється на Work Profile?

Після ряду завершених задач одного типу з’являються дані для агрегації:

1. Зберіть EHL, Flow Time і структуру компонентів для кожної завершеної задачі.
2. Згрупуйте за типом роботи (Existing API, New UI flow, Cross-system integration тощо).
3. Подивіться на розподіл: яка частка Verification? Де Investigation? Де Rework?

Ці дані і формують historical baseline для Work Profile. Перші 5-10 спостережень дадуть орієнтир із lower confidence; з накопиченням прогноз стає точнішим.

Підсумуємо?

Все важке ми з тобою вже пройшли. Тепер просто будемо переварювати прочитане 🙂
Одновимірна естимація перестає бути достатньою, а сучасна AI-assisted команда тестування працює в трьох осях:

AI Leverage не є четвертою оцінкою і не змінює Complexity. Це характеристика execution context, яка допомагає пояснити та прогнозувати EHL і Flow Time.
Саме AI Leverage пояснює, чому однакова складність більше не означає приблизно однаковий human effort. Але це не коефіцієнт, який треба множити на SP. Forecast будується на історичній поведінці подібної роботи в конкретній execution system, а SP залишається окремою характеристикою complexity.

Висновки

Давай підсумуємо без зайвого бла-бла-бла. Що реально дає перехід від одновимірного SP до трьох осей?
Чотири прозорі відповіді замість однієї непрозорої. Замість одного числа, яке треба інтерпретувати контекстно, команда отримує чіткі відповіді на конкретні питання:

• Наскільки складна задача? → Story Points (complexity);
• Скільки людського часу це з’їсть? → Effective Human Load;
• Скільки це займе календарно? → Flow Time;
• Наскільки AI тут допомагає? → AI Leverage (High / Medium / Low).

AI Leverage — це не ще одна оцінка задачі. Це характеристика execution context, яка пояснює, чому дві задачі з однаковими SP можуть мати кратно різний EHL. І вона дає видимість для менеджменту: де інвестиції в AI-інфраструктуру окупаються, а де команда працює переважно вручну і це нормально.
Зараз дуже часто при оцінці задачі виконання АІ взагалі пропускається. Відповідно важко потім побачити залученість АІ, витрати на АІ, які задачі скільки АІ в середньому беруть на себе, + скільки гримнів ми додамо до вартості задачі і так далі. А якщо є ліміт на бюджети АІ? Наприклад, умовних 50$ на місяць і треба розкласти на які задачі їх краще витратити. То ось такий підхід чудово допоможе вивести на поверхню які реальні витрати часу, витрати АІ і звісно ж навантаження і активність людини.
Можливо скоро оцінювання пройде ще якусь трансформацію і новий курс, а на сьогодні, я бачу такий підхід достатньо релевантним 🙂

Що змінюється, а що ні?

Як може виглядати тікет?

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

Які метрики можна відстежувати?

А куди ж без метрик то, скажи? Ось кілька для прикладу, як можна згодом почати рахувати:

• EHL по Work Profiles — де людське навантаження передбачуване, а де ні;
• Flow Time vs EHL — де час «їдять» черги та handoff, а не сама робота;
• Verification Load % — яка частка EHL іде на верифікацію (маркер зрілості AI-процесу);
• Net AI Gain по типах роботи — де AI реально економить, а де створює overhead;
• AI Leverage розподіл — скільки задач High / Medium / Low, де інвестиції в AI-тулінг окупаються;
• Forecast accuracy — наскільки прогнози P50/P80 збігаються з фактом (калібровка моделі).

Давай розглянемо місця можливих гепів?

«Ми не будемо це трекати»
Найбільший ризик — adoption. Навіть із підходом «фіксуй активність — категоризуй потім», це додаткова дисципліна. А ми ж розуміємо, що більшість команд і звичайний time tracking ведуть зі скрипом.

Лайфхак: не намагайся впровадити все одразу. Почни з одного: просто фіксуй EHL факт після закриття задачі. Одне поле, без компонентів, без Flow Time.
Коли це стане звичкою, додай AI Leverage. Потім структуру EHL. Перші 2-3 місяці будуть мінімалістичними і це нормально.

«Ваші 78% через рік будуть іншими»
Так, будуть. AI-інструменти вже вчаться самоверифікації, і пропорції EHL будуть змінюватися. Verification може впасти вдвічі, а Investigation вирости.

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

«На грумінгу тепер обговорювати 5 параметрів?»
SP AI Leverage EHL Flow Time Confidence — це звучить як бюрократія. І якщо підходити формально то нею і стане.

Лайфхак: на грумінгу обговорюй тільки те, що відрізняється від baseline. Якщо задача типовий «Existing API change, High AI Leverage» — просто бери historical P80 і йди далі. Глибоке обговорення потрібне тільки для нетипових задач або задач із low confidence.
А також, ми ж завжди готуємося до грумінгу і у нас є можливість розкласти собі свою оцінку на атоми, а на грумі вже озвучувати саму оцінку.

Фуууххххххх. Вітаю тебе Ми з тобою дуже успішно пройшли цей мозковий штурм разом 💪

Після такої важкої активності додаю традиційну мотиваційну цукерку для настрою та натхнення 🙂

До нових зустрічей 🙌