Discovery în patru săptămâni

Majoritatea fondatorilor care scriu studioului au o idee de produs credibilă tehnic, dar nedefinită arhitectural. Știu ce ar trebui să facă produsul. Nu știu cum ar trebui construit, cum ar trebui să arate stratul AI sau unde trece linia dintre ce poate fi validat ieftin și ce nu.

Discovery răspunde la aceste întrebări. Nu produce cod. Produce un plan tehnic validat.

Mai jos: cum funcționează — ce se întâmplă în fiecare dintre cele patru săptămâni, ce rezultă și de ce structura este exact aceasta.

De ce Discovery și nu un prototip

Impulsul de a prototipa devreme este de înțeles. Un lucru care funcționează convinge mai mult decât un plan: e mai ușor de arătat unui investitor, mai ușor de dat utilizatorilor, mai plăcut de ținut în mână.

Problema este că un prototip construit pe o arhitectură nevalidată este o demonstrație frumoasă a ceva ce poate nu se susține la scară, poate cere decizii greșite în fundație sau poate rezolva o problemă care nu este cea reală.

Costul reconstrucției după un prototip nu este costul prototipului. Este costul prototipului plus costul refacerii, plus frecarea organizațională a schimbării unei direcții pe care toată lumea o considera deja stabilită.

Discovery face munca ce previne refacerea scumpă. Nu încetinind lucrurile, ci făcând ca prima investiție serioasă în cod să meargă în direcția potrivită.

Rezultatul este suficient de concret încât să îl dați unui co-fondator tehnic sau altui studio și să se construiască după el. Dacă planul devine brief pentru o dezvoltare ulterioară cu studioul, primul sprint începe în săptămâna a cincea — cu arhitectura deja decisă.

Săptămâna întâi: harta domeniului

Prima săptămână este despre domeniu, nu despre tehnologie.

Studioul ține două sesiuni cu fondatorul și cu experții relevanți. Scopul este harta domeniului: un model formal al entităților, fluxurilor și relațiilor cu care va lucra produsul. Nu un model de date — un model al domeniului. Ce obiecte există în această lume? Prin ce stări trec? Cine acționează asupra lor și de ce?

Sesiunea este deliberat low-tech: hârtie, tablă sau un instrument simplu de diagrame. Nu este o colectare de cerințe, ci o explorare structurată a ceea ce expertul știe — și a ceea ce presupune fără să observe.

Distincția contează, pentru că cunoașterea expertului este de obicei implicită. Un coordonator de turism stomatologic știe că planul de tratament se schimbă atunci când consultația dă un diagnostic diferit de cel presupus la trimitere — dar nu a trebuit niciodată să explice asta unui sistem software, deci nu a trebuit niciodată să o facă explicită. Sesiunea de cartografiere o face explicită. Nu pentru că studioul va construi fluxul „schimbare de plan la diagnostic” în săptămâna a doua, ci pentru că arhitectura trebuie să îl poată primi.

La finalul primei săptămâni harta domeniului este un artefact comun: fondatorul a citit-o, a corectat unde modelul studioului s-a depărtat de înțelegerea lui și a aprobat-o. De acolo încolo este sursa de adevăr pentru restul Discovery-ului.

Rezultatul săptămânii: harta domeniului, validată.

Săptămâna a doua: proiectarea stratului AI

A doua săptămână aplică harta domeniului asupra întrebării de arhitectură AI.

Având domeniul — entități, fluxuri, utilizatori, date — cum arată stratul AI? Nu este o întrebare despre ce furnizor de AI să alegeți. Este o întrebare despre ce face AI-ul în modelul de operare al produsului.

Cadrul este diagnosticul propriu al studioului, din cinci întrebări, și cele patru niveluri de capabilitate în care le sortează; sunt expuse în Agent-Native, nu „AI-powered”. Pentru fiecare flux semnificativ din harta domeniului, sesiunea din săptămâna a doua întreabă: ce nivel de capabilitate agentică cere acest flux?

Nivelul 1 (completare): AI-ul generează un rezultat pe care un om îl verifică și îl aprobă înainte să producă efecte
Nivelul 2 (orchestrare): AI-ul coordonează mai mulți pași dintr-un flux, cu aprobare umană în puncte definite
Nivelul 3 (autonomie într-un domeniu): AI-ul acționează în numele utilizatorului, în limite date, fără aprobare pas cu pas
Nivelul 4 (coordonare multi-agent): mai mulți agenți specializați lucrează la obiective comune, cu jurnal de audit și rezolvarea conflictelor

Răspunsul diferă de la un flux la altul în același produs. Confirmarea unei rezervări poate fi nivelul 3; o schimbare de plan de tratament poate fi nivelul 2, cu aprobare umană explicită în punctul schimbării. Proiectul stratului AI atribuie fiecărui flux semnificativ nivelul lui și fixează pentru el modelul de autorizare, definițiile uneltelor și cerințele de stare.

Aceasta este sesiunea care scoate cel mai des la iveală presupuneri pe care fondatorul nu știa că le are. „AI-ul se ocupă de cereri” — înseamnă nivelul 2 (AI-ul redactează răspunsul, omul aprobă) sau nivelul 3 (AI-ul trimite răspunsul fără verificare)? Răspunsul schimbă și arhitectura, și modelul de răspundere al produsului.

La finalul săptămânii a doua, proiectul stratului AI este un document care descrie fiecare flux semnificativ, nivelul lui și cerințele arhitecturale care decurg.

Rezultatul săptămânii: proiectul stratului AI.

Săptămâna a treia: constrângeri și riscuri

A treia săptămână testează harta domeniului și proiectul stratului AI pe constrângerile — tehnice, de reglementare, operaționale și organizaționale — în care proiectul va trăi.

Constrângeri tehnice: sistemele cu care produsul trebuie să se integreze, formatele de date care nu pot fi schimbate, cerințele de infrastructură care nu se negociază. De reglementare: cerințe privind locul de stocare a datelor, obligații sectoriale, prevederi aplicabile din AI Act. Operaționale: ce poate întreține echipa, ce poate finanța fondatorul, ce termen are primul rezultat. Organizaționale: cine decide, cine aprobă schimbările de scop, cine este disponibil pentru studio în timpul dezvoltării.

Sesiunea este construită ca să scoată la suprafață conflictele dintre arhitectură și constrângeri. Dacă proiectul stratului AI cere date în timp real, iar API-ul terț are o latență de douăzeci și patru de ore, acesta este un conflict. Dacă arhitectura presupune un agent autonom de nivel 3 într-un domeniu unde reglementarea cere supraveghere umană, acesta este un conflict.

Un conflict descoperit în săptămâna a treia costă mai puțin decât unul descoperit în săptămâna a șasea de dezvoltare. Registrul de riscuri consemnează fiecare conflict: în ce constă, cât de grav este, ce variante de rezolvare există și pe care o recomandă echipa. Fondatorul citește registrul și ia deciziile înainte de săptămâna a patra.

Rezultatul săptămânii: harta constrângerilor și registrul de riscuri.

Săptămâna a patra: planul

A patra săptămână produce lucrul pentru care a fost gândit tot angajamentul: planul tehnic validat.

Planul adună harta domeniului, proiectul stratului AI, harta constrângerilor și deciziile luate pe riscuri într-un program de lucru etapizat și coerent. Conține:

Consemnarea deciziilor de arhitectură. Fiecare decizie semnificativă luată pe parcursul Discovery-ului, cu alternativele considerate și motivul alegerii. Este versiunea citibilă de om a fișierului design.md din OpenSpec — scrisă pentru fondator și pentru viitorii interlocutori tehnici, nu doar pentru agenții care vor lucra după ea.

Etapizarea livrării. O succesiune de etape, fiecare cu un rezultat concret, o estimare de efort și o dependență de etapa anterioară. Etapizarea este gândită ca valoarea să apară devreme: prima etapă produce ceva ce fondatorul poate arăta — și, în același timp, duce spre arhitectura completă.

Tripletul OpenSpec pentru prima etapă. proposal.md, design.md și tasks.md, complete. Dacă dezvoltarea continuă cu studioul, tripletul merge la orchestrator ca primă sarcină. Dacă fondatorul duce planul în altă parte, tripletul funcționează ca brief tehnic pentru primul sprint.

Nivelurile de încredere. Fiecare secțiune a planului poartă unul: ridicat (studioul a mai construit așa ceva, tiparul este cunoscut), mediu (abordarea este solidă, dar contextul adaugă variabile), scăzut (direcția este corectă, dar Discovery-ul a scos la iveală întrebări care vor cere iterații). Secțiunile cu încredere scăzută nu sunt un eșec al Discovery-ului. Sunt recunoașterea onestă că la unele întrebări răspunde doar construcția.

Rezultatul săptămânii: planul tehnic validat — decizii de arhitectură, etapizare, tripletul OpenSpec pentru prima etapă și nivelurile de încredere.

Ce nu este planul

Planul nu este o specificație fixă pe care studioul se obligă să o construiască literal. Planul este cea mai bună gândire arhitecturală disponibilă înainte ca vreo linie de cod să ruleze. Când codul rulează, apare informație nouă: API-ul terț se comportă altfel decât spune documentația, cerința de reglementare se dovedește mai specifică decât se presupunea, expertul care intră în săptămâna a cincea știe ceva ce nu a spus expertul din prima.

Planul supraviețuiește primului contact cu implementarea pentru că este construit pe presupuneri validate — cartografierea domeniului, proiectul stratului AI, cartografierea constrângerilor. Nu supraviețuiește acelui contact neschimbat, pentru că niciun plan nu o face.

Nivelurile de încredere sunt mecanismul care gestionează asta. Secțiunile cu încredere ridicată se schimbă foarte puțin. Cele medii se revizuiesc la finalul primei etape. Cele scăzute trebuie să se schimbe — acolo Discovery-ul a marcat cinstit limita a ceea ce se poate ști înainte de construcție.

Ce prinde o hartă a domeniului: un exemplu dintr-o lucrare reală

Un exemplu din munca studioului, cu precizarea spusă direct: a fost un proiect cu scop fix, nu un Discovery. Este aici pentru că arată la ce folosește sesiunea din prima săptămână, nu pentru că ar fi relatarea unui Discovery pe care l-am condus.

Catalogul VSThermo Moldova prezintă o gamă de profile termoizolante pentru ferestre, pentru un distribuitor. Nouă produse. Modelul evident al unui catalog de produse: nouă pagini și o listă.

Ce conține domeniul în realitate este un album de compatibilitate cu cincizeci și una de sisteme de ferestre, legat de produse în ambele sensuri — de cinci ori și jumătate mai multe sisteme decât produse. Iar direcția căutării este inversul instinctului de vânzător: clientul vine știind sistemul pe care îl are deja montat și caută ce profil i se potrivește. Nu „iată cele nouă produse ale noastre”, ci „aveți sistemul acela, deci vă trebuie profilul acesta”.

Este o singură propoziție de cunoaștere a domeniului și decide forma catalogului: entitatea portantă nu este produsul, ci compatibilitatea produs–sistem. O construcție care ar fi modelat nouă produse și ar fi adăugat compatibilitatea ca un câmp la fiecare ar fi dat un site care funcționează și răspunde la altă întrebare.

Cunoașterea expertului este așa în mod implicit. Un distribuitor care răspunde de ani la telefon la întrebarea „se potrivește la ce am eu?” nu a trebuit niciodată să explice unui sistem software că întrebarea merge în direcția aceasta — deci nu a făcut-o niciodată explicită. Sesiunea din prima săptămână există exact pentru a o face explicită înainte ca arhitectura să presupună contrariul.

Discovery face această muncă în cele patru săptămâni dinaintea primei linii de cod. Într-un proiect cu scop fix se întâmplă și ea, dar sub presiunea termenelor, iar costul greșelii se măsoară în refacere, nu într-o diagramă revizuită.

Este Discovery punctul potrivit de pornire

Discovery este punctul potrivit de pornire pentru majoritatea solicitărilor care ajung la studio. Dacă aveți o problemă de produs care cere un strat AI arhitectural — nu un chatbot alăturat, ci angajamentul de a construi AI-ul ca strat de operare al produsului — și vreți să înțelegeți cum arată construcția corectă înainte de a investi în ea, Discovery este făcut pentru dumneavoastră.

Lucrul începe după un apel scurt în care verificăm că este treaba noastră. Apelul este gratuit. Discovery înseamnă patru săptămâni cu scop fix. Prețul se fixează atunci când se fixează scopul: cifra concretă o spunem după apel, nu înainte.

Pe site oferta se numește diagnostic de creștere — aceeași muncă, descrisă dinspre client.

FAQ

Cât costă Discovery?

Prețul se fixează atunci când se fixează scopul. Cifra concretă o spunem după apelul scurt în care verificăm că este treaba noastră — nu înainte: o estimare dată înainte de a înțelege forma problemei este o presupunere cu virgulă. Acolo unde scopul chiar nu poate fi definit dinainte, spunem asta și lucrăm în regim de timp și materiale, în loc să mimăm un preț fix.

Ce primesc la final?

Un plan tehnic validat: harta domeniului, proiectul stratului AI, un program de lucru etapizat cu estimări de efort, tripletul OpenSpec pentru prima schimbare și un registru de riscuri cu niveluri de încredere. Planul este făcut ca să poată fi folosit: este suficient pentru ca un co-fondator tehnic să îl evalueze, pentru ca alt studio să lucreze după el, pentru ca fondatorul să discute cu un investitor în termeni tehnici concreți.

Garantează Discovery o colaborare ulterioară?

Nu. Discovery este o lucrare de sine stătătoare. Planul vă aparține și îl folosiți cum decideți: cu studioul, cu altă echipă sau ca bază pentru a găsi un co-fondator tehnic. Este făcut să fie util în toate trei cazurile — de aceea se încheie cu o specificație, nu cu o ofertă comercială.

De ce aveți nevoie din partea mea?

Acces la experții relevanți — de obicei fondatorul plus una-două persoane care cunosc detaliul operațional al problemei — pentru patru sesiuni structurate în patru săptămâni, de aproximativ o oră și jumătate fiecare. Documentația existentă, cercetarea de utilizatori, constrângerile tehnice pe care le aveți. Și disponibilitatea de a vorbi concret despre ce trebuie să facă produsul, nu doar despre ce va deveni cândva.

De ce patru săptămâni și nu două?

Primele două săptămâni scot la iveală presupuneri despre care nici studioul, nici fondatorul nu știau că sunt presupuneri. Următoarele două le testează pe constrângeri și le transformă în plan. Un Discovery de două săptămâni dă un plan sigur, dar netestat. Unul de patru săptămâni dă un plan sigur și testat. Diferența se vede în felul în care planul supraviețuiește primului contact cu implementarea.

De citit mai departe

Agent-Native, nu „AI-powered” — diagnosticul de capabilitate pe care Discovery îl aplică în săptămâna a doua
Metoda OpenSpec în producție — metodologia după care merge dezvoltarea de după Discovery