AI projekt scope creep — miért csúszik el minden második AI bevezetés?

Miért más az AI projektek scope creep-je?

Hagyományos szoftverprojekteknél a scope creep főleg stakeholder kérésekből ered: valaki újabb funkciót akar, a csapat beleegyezik, a projekt csúszik. Ismert minta, ismert gyógyszer.

AI projekteknél van egy plusz dimenzió, ami mindent megváltoztat: maga a technológia generálja a scope-bővítési kísértést. Minden hónapban megjelenik egy jobb modell. Minden sprint után megjelenik egy újabb lehetséges use case. A benchmark-ok javíthatók, az integrációk bővíthetők, a prompt stratégiák finomíthatók.

Az eredmény: a csapat lelkesen, jóhiszeműen, folyamatosan bővíti a projektet — és soha nem ér el oda, hogy "kész". Ez nem lustaság vagy rossz szándék. Ez az AI projektek strukturális tulajdonsága.

Az AI scope creep három fő forrása

1. A modell-váltás kísértése

Az AI modellek fejlődési üteme példátlan. GPT-4o után jött az o1, utána az o3, közben a Claude 3.5, a Gemini 2.0, a DeepSeek R1. Minden modell-kiadásnál a csapat természetes impulzusa: "frissítsünk, ez jobb."

A probléma: minden modell-váltás nem egy apró technikai lépés. Szükségessé teszi a regressziótesztelést (az összes korábbi use case viselkedik-e ugyanúgy?), a promptok újraírását (az új modell prompt-érzékenysége eltér), és a teljesítményvalidációt. Egy "gyors modellcsere" 2–4 hetes munkát jelent.

Ha ezt minden negyedévben megcsinálod, a projekt soha nem éri el a production-ready állapotot.

2. A benchmark-hajsza

Az AI csapatok — különösen, ha műszaki hátterűek — hajlamosak a modell teljesítményét optimalizálni: pontosságot, visszahívási arányt, válaszminőséget javítani. Ez önmagában értékes. A baj ott kezdődik, amikor az optimalizálás az üzleti célt háttérbe szorítja.

Egy valódi példa a saját audit-munkámból: egy ügyfélszolgálati AI projektnél a csapat 6 hetet töltött azzal, hogy a modellek RAG-pontosságát 78%-ról 84%-ra javítsa. Közben az eredeti üzleti cél — az átlagos válaszidő csökkentése — nem változott, mert az AI-t még mindig nem vezették be éles rendszerbe.

3. Az "még egy feature" szindróma

Ez a legklasszikusabb scope creep forma — de AI projekteknél különösen erős, mert az AI természeténél fogva általánosítható. Ha a chatbot ügyfélkérdésekre válaszol, miért ne válaszolna belső HR kérdésekre is? Ha az összefoglaló modul e-maileket kezel, miért ne kezelhetné az értekezlet-felvételeket is?

Minden ilyen kérés egyenként ésszerű. Összességükben megtöbbszörözik a projekt komplexitását, a tesztelési igényt, és a szükséges adatintegrációkat.

AI projekt vs. hagyományos IT projekt: összehasonlítás

MVP-first az AI projektekben: hogyan csináld jól

Az MVP (Minimum Viable Product) koncepciója az AI projekteknél is működik — de pontosan definiálni kell, mit jelent "minimum viable" AI kontextusban.

Nem azt jelenti, hogy gyenge minőségű vagy befejezetlen rendszert adsz ki. Azt jelenti, hogy egyetlen use case, egyetlen felhasználói csoport, egyetlen mérhető üzleti kimenet — és semmi más.

Hogyan definiálj AI MVP-t:

1. Egyetlen use case-t válassz ki — a 12-ből, amit a stakeholderek felsoroltak. A kritérium: legyen mérhető, legyen fájdalmas (a jelenlegi folyamat valódi problémát okoz), és legyen izolálható (nem függ 5 másik rendszertől).
2. Definiálj "done" kritériumot — mi az a minimális teljesítmény, ami production-ready? Például: az AI 80%-os pontossággal válaszolja meg az ügyfélfoglalásokkal kapcsolatos kérdéseket, 15 másodperc alatt.
3. Blokkolj minden más kérést — a scope backlogba kerül, nem a sprintbe. "Jó ötlet, jövő iteráció."
4. Validálj éles körülmények között — nem sandbox, nem teszt-adatokkal. Valódi felhasználók, valódi kérdések, valódi mérés.

Scope freeze protokoll: hogyan védd meg a projekt határait

A scope freeze protokoll egy formális mechanizmus, amely megakadályozza a hatókör-tágulást. Nem bürokratikus akadály — hanem a projekt túlélésének feltétele.

A scope freeze protokoll elemei:

1. Írásos scope dokumentum — egyoldalas, pontosan definiált use case-ekkel, kizárásokkal ("ez a projekt NEM foglalkozik X-szel"), és aláírásokkal (projekt sponsor + tech lead + üzleti tulajdonos).
2. Scope backlog — minden új ötlet és kérés ide kerül, nem a sprint backlogba. Rendszeresen priorizáljuk, de nem automatikusan hajtjuk végre.
3. Scope change process — ha valaki mégis be akar vinni egy új elemet, formális értékelés szükséges: mekkora késést okoz, mi a megtérülése, melyik régi elemet váltja le.
4. Csak a projekt sponsor nyithat scope freeze-t — nem a tech lead, nem a felhasználó, nem a csapat. Ez csökkenti az ad hoc kérések nyomását.

Iteratív fejlesztés AI projekteknél: a gyakorlati keret

A vízesés modell AI projekteknél nem működik. Az ok egyszerű: az AI viselkedése csak éles tesztelés alatt derül ki, a követelmények nem ismerhetők meg előre, és a modell teljesítménye függ az adatoktól, amelyek csak az integráció után érhetők el teljesen.

Az iteratív AI fejlesztési keret, ami a saját projektjeimben működik:

• Sprint hossza: 2 hét — nem 1 (túl rövid az AI értékeléséhez), nem 4 (túl hosszú a visszajelzés nélküli munka)
• Sprint scope: fix a sprint elején, nem változik a sprint alatt
• Sprint cél: mindig üzleti kimenet, nem technikai fejlesztés ("ügyfél tud foglalást módosítani AI-on keresztül", nem "RAG pipeline kész")
• Demo minden sprint végén: valódi felhasználóval, valódi use case-szel — nem sandbox demonstráció
• Retrospektív: mi csúszott a scope-ba, amit nem kellett volna? Mi a következő sprint scope-ja?

Stakeholder elvárások kezelése: a három legfontosabb eszköz

A scope creep leggyakoribb forrása nem a csapat — hanem a stakeholderek, akik folyamatosan bővíteni akarják a projektet. Az elvárás-kezelés nem egy egyszeri feladat az indításnál — hanem folyamatos munka.

1. Elvárás-kalibrálás az indításnál

Mutasd meg a stakeholdereknek, mit tud és mit nem tud az AI — határokkal együtt. A legjobb módszer: egy 30 perces demo, ahol a rendszer nem csak a legszebb eseteket, hanem a kudarcokat is megmutatja. Ez beállítja a realisztikus elvárásokat.

2. Havi scope review

Havonta egy dedikált meeting: átnézzük a scope backlogot, priorizáljuk, és eldöntjük, mi kerül a következő iterációba. Ez adja azt az érzést, hogy a kérések "hallásra kerülnek" — anélkül, hogy automatikusan bekerülnének a projektbe.

3. A "nem most" szótár

Minden scope-bővítési kérelemre van egy standard válasz: "Jó ötlet. Felkerül a scope backlogra, és a következő iteráció tervezésekor értékeljük." Ez nem elutasítás — hanem átirányítás. A stakeholder hallva van, a projekt védve van.