Discovery Sprint de 2 săptămâni: structura care scoate orice proiect AI din PoC-purgatory

Un termen pe care îl auzim prea des în 2026: „PoC purgatory”. O echipă a investit luni într-un proiect AI care nu trece bariera de la prototype la producție. Banii sunt cheltuiți, demo-ul rulează, dar nimeni nu pornește implementarea reală. Cauza nu este lipsa de capacitate tehnică; este lipsa unei decizii arhitecturale clare. Echipa nu știe sigur ce să implementeze, ce model să folosească, ce arhitectură de date, cum să măsoare succesul.

Discovery Sprint-ul de 2 săptămâni cu cost fix este formatul pe care l-am dezvoltat ca antidot. Două săptămâni, livrabile clare, decizie arhitecturală asumată. Articolul descrie structura sprint-ului, ce se întâmplă în fiecare zi, ce iese la final, și de ce formatul cu cost fix este cheia.

TL;DR

• PoC purgatory apare când nu există o decizie arhitecturală asumată în scris.
• Discovery Sprint-ul livrează: spec arhitectură, decision matrix justificat, PoC funcțional pe un caz real, plan de implementare cu efort estimat.
• Costul fix elimină ezitarea: clientul cunoaște exact ce primește, noi cunoaștem exact ce livrăm.
• Structura sprint-ului: săptămâna 1 audit + decizie, săptămâna 2 PoC + plan.
• Output-ul nu este un slide deck. Este un document tehnic plus cod funcțional.

De ce PoC-uri rămân în limb

Trei cauze frecvente:

Lipsa de decizie scrisă. Echipa a încercat trei abordări, fiecare cu rezultate parțiale. Nimeni nu a scris definitiv „mergem cu abordarea X, motivele sunt Y”. Fără document, decizia rămâne mereu deschisă, iar implementarea reală nu pornește.

Lipsa de aliniere cu business. Echipa tehnică a scos un PoC care arată bine, dar nu este clar cine îl folosește, cum aduce valoare, cu ce KPI se măsoară. Management-ul vede o demo, întreabă „și acum?”, echipa nu are răspuns.

Lipsa de plan realist. PoC-ul rulează cu date sintetice, fără auth, fără audit, fără monitoring. Distanța de la prototype la producție se subestimează la 50% din timpul real necesar. Echipa nu vrea să accepte estimarea reală.

Discovery Sprint-ul forțează deciziile, alinierea și planul. Nu construiește totul; construiește punctele de inflexiune care permit restul.

Structura sprint-ului — săptămâna 1

Ziua 1 — Workshop initial (4-6 ore)

Cu stakeholders technic și business prezenți. Agenda:

• Definirea problemei de business pe care AI ar trebui să o rezolve. Ce KPI se mișcă?
• Mapping-ul utilizatorilor: cine beneficiază, cum măsurăm satisfacția, ce alternative au?
• Constrângeri non-funcționale: latency, cost budget, compliance (GDPR, sectoriale), hosting (cloud / on-prem / mixt).
• Ce există deja: date, modele, infrastructure, echipă internă cu skill-uri AI.
• Out-of-scope: ce nu vom rezolva în acest sprint și de ce.

Output: charter de proiect de 2-3 pagini semnat de toți.

Zilele 2-3 — Audit tehnic

Echipa noastră face audit pe trei direcții paralele:

Audit de date. Ce date există? În ce format? Cât sunt curate? Au labels? Sunt suficiente pentru ce vrem să facem? Aici descoperim problemele clasice: date împrăștiate în 5 sisteme, label-uri inconsistente, duplicate, lipsa de versionare.

Audit de cod. Dacă există un PoC anterior, citim codul. Ce model folosește, cum gestionează context, cum face evaluation. Identificăm ce putem reutiliza, ce trebuie rescris.

Audit de infrastructură. Unde va rula? Există GPU, vector DB, monitoring? Echipa internă poate opera? Care sunt restricțiile de rețea?

Output: trei rapoarte scurte (3-5 pagini fiecare) cu findings și recomandări.

Zilele 4-5 — Decision matrix

Pe baza auditului, construim opțiuni arhitecturale concrete (nu abstracte). Pentru un caz tipic AI:

• Opțiunea A: model SaaS (Claude/OpenAI) + RAG cu pgvector
• Opțiunea B: model self-hosted (Llama/Qwen) + RAG cu Qdrant
• Opțiunea C: fine-tuning model mic + cache pentru latency

Pentru fiecare: cost initial, cost lunar la scale așteptat, latency estimat, calitate așteptată, complexitate operațională, conformitate.

Decision matrix se prezintă către client în meeting de o oră. Discutăm trade-off-uri, alegem împreună o direcție. Nu se semnează doar; se discută.

Output: document de decizie arhitecturală de 5-8 pagini, cu opțiunea aleasă și motivele.

Structura sprint-ului — săptămâna 2

Zilele 6-9 — PoC pe caz real

Acum implementăm. Nu un demo cu date sintetice; un PoC cu date reale ale clientului pe un caz concret bine definit. Exemple:

• Pentru un asistent juridic: 50 de documente reale, 30 de queries reale (pe care echipa le folosește azi manual)
• Pentru un agent de suport: 100 de tichete istorice, 20 categorii de clasificare, target 90% accuracy
• Pentru un sistem de recomandare: catalog real, 50 de utilizatori cu istoric, target precision la top-5

PoC-ul rulează pe arhitectura aleasă în săptămâna 1. Nu este production-ready: lipsesc auth, audit, scaling. Dar este funcțional pe date reale.

Demonstrăm zilnic la stakeholders, cu output efectiv. Iterăm pe baza feedback-ului.

Output: cod PoC într-un repo dedicat, cu README și instrucțiuni de rulare.

Zilele 10 — Evaluation

Evaluare pe set fix de queries reale:

• Acuratețe / precision / recall (în funcție de sarcină)
• Latency p50/p95
• Cost per query
• Calitate calitativă (un reviewer uman citește 30 de output-uri)

Output: raport de evaluation de 2-3 pagini cu cifre concrete.

Zilele 11-12 — Plan de implementare

Pe baza PoC-ului și a evaluării, construim plan de implementare detaliat pentru a duce PoC-ul în producție:

• Lista de feature-uri lipsă (auth, audit, monitoring, error handling, fallback)
• Estimare per feature (zile-om)
• Dependențe externe (provider, infrastructure, integrations)
• Risk register cu mitigări
• Plan de rollout (pilot, validation, scale-up)
• Cost lunar estimat la steady state
• KPI de monitorizat post-launch

Output: plan de implementare de 8-12 pagini cu efort total estimat.

Ziua 13-14 — Final readout și transfer

Meeting final cu management plus echipa tehnică. Prezentăm:

• Demo PoC pe caz real
• Raportul de evaluation
• Decizia arhitecturală asumată
• Planul de implementare cu efort

Predăm tot materialul (cod, documente) la echipa internă a clientului. Răspundem la întrebări. Stabilim, dacă e cazul, cum continuăm noi în implementare (sub formă de proiect distinct, nu inclus în sprint).

Output: tot materialul predat plus o discuție de Q&A de 2-3 ore.

De ce cost fix

Costul fix al sprint-ului are două motive critice:

Pentru client. Ezitarea care alimentează PoC purgatory este lipsa de control pe buget. Costul fix elimină incertitudinea: clientul știe exact cât plătește pentru ce livrabile clare. Risc minim, decizie ușoară de aprobat.

Pentru noi. Costul fix ne forțează să fim eficienți. Două săptămâni este timp scurt pentru audit + decizie + PoC + plan. Nu putem îneca în deliverables nesfârșite. Concentrarea pe ce contează este built-in în format.

Pricing-ul exact depinde de complexitate, dar este în zona unui proiect mic-mediu. Pentru orice client serios, costul este recuperat în prima lună de implementare datorită planului bun.

Ce nu este Discovery Sprint

Pentru claritate:

• Nu este un workshop de strategie AI generală. Lucrăm pe un caz concret.
• Nu este o implementare în producție. Producția se face în proiect separat.
• Nu este un audit security/compliance complet. Auditul este la nivelul deciziei arhitecturale.
• Nu este un training pentru echipa internă. Predăm material, nu cursuri.

Patru rezultate tipice ale sprint-ului

Bazat pe sprinturile noastre, output-ul tipic este unul din patru:

1. „Da, mergem”. Clientul aprobă planul, începem implementarea (sau o face echipa lor). Cazul cel mai frecvent (60%).

2. „Da, dar într-o altă direcție decât am crezut”. PoC-ul a arătat că abordarea inițială (fine-tuning, RAG complex, framework specific) nu este cea potrivită. Sprint-ul a salvat clientul de săptămâni de muncă în direcție greșită (25%).

3. „Nu acum”. Auditul a arătat că datele nu sunt gata, sau echipa internă nu are capacitate. Sprint-ul a evitat un proiect care ar fi eșuat. Clientul investește în prerequisite (data quality, hiring) și revine peste 6-12 luni (10%).

4. „Această problemă nu necesită AI”. Uneori auditul descoperă că problema se rezolvă cu o regulă sau un script simplu. Onestitatea aici este crucială. Clientul economisește bani pe care nu i-ar fi cheltuit util (5%).

Toate cele patru sunt rezultate bune. Singurul rezultat prost este PoC purgatory — și asta este ceea ce sprint-ul previne.

Concluzie executivă

Pentru orice CTO sau director de inovație care are un proiect AI blocat în PoC purgatory: sprint-ul de 2 săptămâni este vehiculul cel mai eficient pentru a debloca decizia. Cost predictibil, livrabile clare, decizie asumată.

Pentru CAI Technology, formatul este o disciplină internă: ne forțează să gândim, să decidem și să livrăm. Pentru clienți, este modul cel mai rapid de a obține un plan tehnic real fără luni de incertitudine.

Articole conexe

• RAG vs fine-tuning în 2026
• Cost-aware LLM routing
• Pillar Consulting — assessment AI
• Pillar IRIS — agentul orchestrator CAI Technology

Surse externe

• „The Phoenix Project” — Gene Kim — referință standard pentru de ce sprint-uri scurte funcționează
• Google Design Sprint guide — origini metodologice ale sprint-ului structurat
• „Lean Startup” — Eric Ries — context pentru build-measure-learn aplicat în AI
• NIST AI Risk Management Framework — referință pentru audit-ul de risc în decizii arhitecturale AI
• „Crossing the Chasm” — Geoffrey Moore — context pentru de ce PoC-urile nu sar singure în producție

Următorul pas

Dacă echipa dvs. are un proiect AI blocat sau pe punctul de a porni și vreți să discutăm dacă un Discovery Sprint se potrivește, vă oferim o consultație inițială de 30 minute fără cost.