Product→Engineering з AI: scoring неоднозначності специфікації

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

Чому шов product→engineering ллє?

Бо спека — це артефакт, а спека рідко пишеться під споживача. PM пишуть спеки у PM-формі: результати, user stories, "must/should/could". Інженери читають у інженер-формі: інтерфейси, edge-cases, режими відмови, acceptance criteria. Розрив трансляції — це місце, де живе rework.

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

Традиційний фікс — "більше зустрічей до планування" — не масштабується і не ловить режими відмови, які інженери ще не озвучили. AI-scoring відпрацьовує за 30 секунд, ловить easy-to-miss розриви і звільняє людську розмову для складних.

Які шість вимірів неоднозначності?

Ці шість покривають ~90% spec-rework, що я бачу в SMB-командах. Кожен оцінюється 1-5 AI-агентом, що читає спеку; пороги тригерять розмову до kickoff, не блокер.

Definition: Вимір неоднозначності — категорія недо-специфікації, що емпірично корелює з rework, якщо лишається невирішеною до імплементації.

1. Ясність результату — описаний user-observable success state, чи лише фіча?
2. Покриття edge-cases — записані "що, якщо порожньо / 10 000 / офлайн"?
3. Конкретність acceptance criteria — машинно-перевіряються чи якісні?
4. Поверхня залежностей — названі upstream-сервіси, дані, downstream-споживачі?
5. Форма даних — input/output схема явна, чи інженер виводить?
6. Rollout & reversal — стратегія фіче-флагів, порядок деплою, шлях відкату — визначені?

Спека з оцінкою ≥4 за всіма шістьма — готова до інженерії. Спека з 1-2 за будь-яким одним виміром — це rework-раунд, що чекає бути зашиплений.

Промпт-скорер (copy/paste)

Цей промпт AI-агент запускає на PM-спеці до того, як kickoff заплановано. Аутпут йде PM-у, не інженерам — щоб PM володів фіксом.

SPEC AMBIGUITY SCORE — v1
Прочитай прикріплену спеку. Оціни кожен вимір 1-5.
Цитуй рядок спеки, що зумовив оцінку.

ВИМІРИ
1. Ясність результату
2. Покриття edge-cases
3. Конкретність acceptance criteria
4. Поверхня залежностей
5. Форма даних
6. Rollout & reversal

Для кожного виміру виведи:
- Score (1-5)
- Цитата (дослівна, до 200 знаків)
- Одне речення причини оцінки
- Одне речення "що зробить це 5"

Потім блок підсумку:
- Загальна готовність: GREEN (всі ≥4) | YELLOW (будь-яка 3) | RED (будь-яка ≤2)
- Топ-3 фікси за rework-ризиком
- Час на фікс: хвилин

Без перефразування. Без коментаря поза структурою.

Вимога "Цитата (дослівна)" — це механізм довіри. Без неї AI вигадує критики, що не заземлені в тексті спеки, і PM розумно ігнорує аутпут.

Tool tip (Course for Business): Промпт — легке. Складніше — навчити PM-ів і інженерів використовувати без перетворення на гейт або зброю. У нашій 6-week program принцип Augment, don't replace найважче приземлюється саме на цей шов: AI оцінює, людина володіє резолюшеном. Shoulder-to-Shoulder hot seats у тижні 3 — для парного PM-eng ревʼю неоднозначностей, і до тижня 5 більшість команд інтегрують scoring у існуючий spec-шаблон. Прогуляйся програмою: https://course.aiadvisoryboard.me/business.

Коли в spec-workflow запускається scoring?

Два моменти. Перший: PM завершив draft спеки, до будь-якого інженерного ревʼю. PM сам запускає AI-score, фіксить, що може, тоді посилає далі. Другий: ліц-інженер прочитав спеку, до sprint planning. Другий прохід ловить те, що пропустили обидва.

Запускати пізніше — після kickoff — занадто пізно. Сенс scoring — не знайти неоднозначність для post-mortem, а зловити її до того, як вартість виправлення зросте у 10 разів.

Team scan (що AI-champions репортують після тижня 1)

• Adoption: 7 з 9 PM запускають score на кожній спеці до дня 5
• Use case: rollout & reversal — найнижчий бал у команді; більшість спек пропускали деталь фіче-флагу
• Заощаджений час: 4-6 інженерних годин на спеку на YELLOW; 12+ на RED
• Один named AI-champion в продуктовій команді, ратио ~1:15
• Spec-шаблон оновлений: 6 хедерів вимірів, не лише score
• Інженери перестали читати спеки в ізоляції; обсяг pre-kickoff Q&A впав
• Поради "як перевести в 5" приймаються PM-ами дослівно у 60-70% випадків
• 2 RED-спеки впіймані до спринту, що зайшли б у rework
• Вартість AI-прогону на спеку: <$0.05 — не питання бюджету
• Опір senior-PM-ів обробив champion у тижні 2 (як augment, не аудит)

Micro-case (що змінюється за 7-14 днів)

Продукт-компанія на 140 людей з 6 PM і 18 інженерами розкотила scoring неоднозначності. До: близько 30% спринт-capacity йшло у mid-sprint rework, що в standups трасувався до spec-розривів. Тиждень один: PM-и оцінили 14 спек, 3 GREEN, 8 YELLOW, 3 RED. 3 RED — це ті самі, на які ліц-інженери вже бурчали, але тепер був структурований артефакт, на який тицьнути, а не vibe. До тижня три: лише 1 RED-спека дійшла до kickoff (з типових 4-5). Час mid-sprint rework впав приблизно на третину. Глибший ефект: PM-и почали писати спеки інакше з самого початку — додавали rollout-секції за замовчуванням, називали залежності inline — бо інтерналізували виміри, які score все одно перевірятиме.

Note on this case: Це ілюстрація — на основі типових патернів у компаніях 30-500 людей, не один клієнт. Числа — заокруглені діапазони, не гарантії.

Tool tip (Course for Business): Чому це приземляється в одних SMB і відскакує в інших — справа в дисципліні розкочки, не промпта. Наша 6-week program використовує ратио AI Champions (1:15-20), щоб у кожній команді був хтось, хто веде тижневе ревʼю: які спеки потрапили в RED, які фікси спрацювали, який вимір повертається. Без цієї ролі scoring стає ще одним дашбордом, який ніхто не відкриває. Бронюй 30-хв мапінгову розмову: https://course.aiadvisoryboard.me/business.

FAQ

Чи не зсуває це роботу з інженерії на PM? Частково — так, і це правильно. YELLOW-фікс коштує PM 15 хвилин, а інженерії — 4 години. Співвідношення тримається.

А якщо спеки в Notion / Jira / shared doc — це важливо? Ні. AI-агент читає, що паститься. Деякі команди вмонтовують це у doc-інструмент; інші — в чат. Форма інтеграції не змінює цінність.

Чи може AI сам писати фікси? Для вимірів 2, 4, 6 (edge cases, залежності, rollout) — частково так. Для 1 і 3 (результат і acceptance) — людина має вирішувати, бо AI не знає продуктової стратегії. Augment, don't replace.

Чи не перестануть інженери ретельно читати спеки, якщо AI оцінив? Це режим відмови, який треба моніторити. Score — не заміна інженерному судженню; це інструмент тріажу. Фрейми: "AI ловить easy-розриви, щоб ми сфокусували людський прохід на складних".

Це те саме, що design-to-development? Поруч, але інше. Design→dev має власні виміри (reuse компонентів, покриття станів, accessibility) — окрема стаття.

Висновок

Rework у SMB-інженерії — не проблема дисципліни і не проблема скілу. Це проблема якості спеки вище за течією, де інженери не можуть її закрити. AI-scoring неоднозначності ловить розриви на 7-10 днів раніше — за копійку на спеку.

Візьми одну спеку з беклогу цього тижня. Прокатай через 6-вимірний промпт. Подивись, що випливає. Тоді зроби score стандартним кроком до kickoff.

Якщо хочеш, щоб кожен співробітник зашипив свою першу AI-автоматизацію за пʼять днів — забронюй 30-хв дзвінок, і ми мапнемо перший тиждень твоєї команди: https://course.aiadvisoryboard.me/business.