Construim sisteme reducând incertitudinea pas cu pas.

Înainte de funcționalități există un context de business, oameni care fac munca astăzi, sisteme deja instalate, reguli scrise și nescrise, constrângeri reale și decizii care încă nu au fost luate. Toate acestea determină ce se poate construi și în ce ordine.

Prima etapă nu produce ecrane și nici estimări. Produce o formulare a problemei pe care toată lumea implicată o recunoaște — inclusiv părțile inconfortabile.

Lista de funcționalități apare oricum. Întrebările de mai jos decid însă dacă acea listă rezolvă ceva sau doar digitalizează o problemă existentă.

Un sistem pe care îl poți desena este un sistem pe care îl poți discuta. Harta nu este documentație decorativă: este instrumentul cu care se negociază scope-ul.

Starea curentă nu este un diagnostic negativ. De multe ori este soluția rațională la constrângerile de acum câțiva ani. Ce s-a schimbat între timp sunt volumele, cerințele și numărul de sisteme care trebuie să comunice.

Harta descrie ce există. Arhitectura decide ce se construiește: unde sunt granițele, cine deține fiecare zonă, cum circulă datele și ce se întâmplă când ceva cedează.

Diagrama este doar reprezentarea. Valoarea stă în deciziile din spate: ce se separă, ce se cuplează, ce stare există unde și ce se întâmplă când o parte cedează. Fiecare dintre ele are un cost și un compromis explicit.

Un increment care conține doar interfața, sau doar backend-ul, nu poate fi testat cu date reale. Un increment care traversează toate nivelurile poate fi folosit — și, deci, contrazis de realitate.

Construcția atinge simultan frontend, backend, date, API-uri, integrări, workflow-uri, AI și infrastructură. Nu pentru că sunt la modă împreună, ci pentru că o verticală funcțională le traversează pe toate.

Documentul rămâne necesar: fixează deciziile și contractele. Dar ipotezele despre comportament, volum și utilizare se verifică abia când cineva folosește sistemul.

Validarea nu este o etapă la final. Este un semnal care traversează toate celelalte etape: o ipoteză despre proces se verifică în Map, una despre integrare în Architect, una despre utilizare în Build.

Nu întrebăm dacă interfața place. Întrebăm dacă omul care are treaba de făcut o duce la capăt, cu informația pe care o are, fără să iasă din sistem.

Traseul fericit este cel mai ușor de construit și cel mai puțin interesant. Sistemul se judecă după ce face când o integrare nu răspunde, când datele sunt incomplete sau când două operațiuni se suprapun.

Un răspuns bun la o întrebare aleasă cu grijă nu spune nimic despre comportamentul pe o mie de cazuri reale. Unde folosim AI, evaluăm lanțul întreg: context, sursă, formă a răspunsului, acțiune și verificare umană.

Nu sunt aprobări administrative și nu opresc lucrul. Sunt puncte în care verificăm dacă ipoteza pe care urmează să construim mai departe este încă validă — pentru că de la acel punct devine scumpă de schimbat.

Un sistem care nu poate fi livrat repetabil, urmărit în funcționare și repus în funcțiune după un incident nu este terminat, indiferent cât de complet este funcțional. Deciziile de operare se iau devreme, nu după prima lansare.

Distanța dintre un sistem care rulează local și un sistem pe care o organizație se poate baza este formată din decizii concrete: configurație, acces, date, vizibilitate și reacție la eșec.

Momentul lansării este și momentul în care oamenii își schimbă modul de lucru. Introducerea graduală reduce simultan riscul tehnic și rezistența operațională.

Lansarea nu încheie procesul. Din acel moment sistemul produce informație despre el însuși, iar acea informație reintră în Understand, Map și Architect — de data aceasta cu date, nu cu ipoteze.

Bucla de mai jos nu are un punct final. Fiecare rotație pornește din utilizare și se întoarce în utilizare, cu o schimbare în plus care a fost decisă pe baza a ceva observat.

Cele șapte etape rămân aceleași în orice proiect. Ce se schimbă este unde stă incertitudinea — și, deci, unde se concentrează efortul și validarea.

Nu contează cum se numesc rolurile în fiecare organizație. Contează ca fiecare tip de decizie să aibă un proprietar identificabil și un moment în care se ia.

Rezultatele de mai jos nu sunt o listă de livrabile contractuale. Sunt formele obișnuite în care rămâne cunoașterea acumulată, ca să nu depindă de memoria cuiva.

Un document care descrie ce face fiecare buton se învechește în două săptămâni. Un document care explică de ce sistemul este împărțit așa rămâne util ani.

Fiecare dintre liniile de mai jos traversează toate cele șapte etape. Dacă apare abia înainte de lansare, devine o listă de corecții — nu o proprietate a sistemului.

Intrări reale, un ciclu care se rotește, o validare care traversează totul, patru linii transversale și trei ieșiri — dintre care una este următoarea iterație.

Etapele spun în ce ordine se reduce incertitudinea. Capabilitățile spun cine construiește efectiv fiecare strat al sistemului.