De la idee la sistem

Ideile de produs nu apar sub forma unei specificații. De obicei vin dintr-o problemă reală, câteva exemple, o soluție intuitivă și multă grabă de a începe. Este firesc. Problemele apar când fiecare persoană completează golurile în felul ei, iar diferențele ies la suprafață abia după ce a început dezvoltarea.

Când intru într-un proiect nou, încerc mai întâi să aflu ce trebuie să se schimbe pentru utilizator și de ce merită construit produsul. Abia apoi discut despre ecrane, tehnologie sau funcționalități.

Acesta este și scopul unui sprint de arhitectură de produs.

Nu încep cu lista de funcționalități

„Avem nevoie de un asistent AI” descrie o posibilă soluție, nu problema. O formulare mai utilă ar fi: „Operatorul pierde douăzeci de minute ca să afle ce sursă susține o afirmație”. Acum știm cine are problema, ce face astăzi și ce ar însemna o îmbunătățire.

Poate că soluția va folosi AI. Poate că este suficientă o căutare mai bună, o regulă sau o integrare între două sisteme. Dacă alegem soluția înainte să înțelegem decizia pe care trebuie să o susțină, riscăm să construim foarte bine lucrul greșit.

Aceeași regulă se aplică unei platforme sau unei piețe digitale. Cuvântul „platformă” nu spune cine poate publica, cine aprobă, ce date sunt necesare și ce se întâmplă când un participant greșește. Aceste întrebări țin de produs, nu sunt simple detalii tehnice.

O hartă suficient de bună

Nu este nevoie de un document uriaș. Pentru prima versiune vreau răspunsuri clare la câteva întrebări:

1. Cine folosește produsul și cine mai este afectat?
2. Care sunt obiectele importante din domeniu și cine răspunde pentru ele?
3. Ce pași parcurge utilizatorul?
4. Din ce surse vin datele și câtă încredere putem avea în ele?
5. Ce reguli și permisiuni trebuie respectate?
6. Cum arată un eșec și cum revenim după el?

Aici apar contradicțiile care costă. O funcționalitate promisă „în timp real” poate depinde de o sursă actualizată o dată pe zi. Un pas care pare automat poate necesita o aprobare legală. O recomandare poate părea precisă chiar dacă datele pe care se bazează lipsesc.

Bucla de lucru

Folosesc o buclă simplă. Nu este o metodologie nouă și nici nu are nevoie de un nume pompos. Este doar ordinea în care încerc să nu sar peste întrebările importante.

Intenția spune ce vrem să schimbăm. Contextul descrie situația actuală și limitele cunoscute. Așteptările stabilesc ce trebuie să poată face produsul. Specificația și planul transformă aceste răspunsuri în decizii de lucru. Codul și testele arată dacă am înțeles corect.

La finalul fiecărei etape verific rezultatul față de intenția inițială. Dacă am învățat ceva nou, actualizez documentele înainte de următoarea etapă. Altfel, echipa ajunge să lucreze după o explicație veche a produsului.

Prima bucată trebuie să traverseze sistemul

O etapă bună nu înseamnă zece ecrane fără date reale și nici un serviciu de backend pe care nu îl folosește nimeni. Prefer o bucată îngustă, dar completă: preia o sursă, validează datele, aplică o regulă, arată rezultatul, păstrează decizia și permite corectarea unei erori.

Această bucată spune repede dacă legăturile dintre produs, date și arhitectură funcționează. Restul se poate extinde după ce avem un traseu real și verificat.

Versiunea unu nu trebuie să rezolve viitorul

În timpul proiectării apar aproape întotdeauna idei pentru versiuni viitoare. Le notez, dar nu le las să intre pe ascuns în prima livrare. Separ deciziile care ar fi greu de schimbat mai târziu de cele pe care le putem lua simplu acum.

Înainte de dezvoltare vreau un pachet compact: scop, utilizatori, vocabularul domeniului, fluxurile importante, sursele de date, limitele primei versiuni, riscurile, criteriile de acceptanță și primul pas de implementare.

Documentația nu este rezultatul final. Rolul ei este să îi ajute pe oamenii din produs, inginerie și operațiuni să vorbească despre același lucru și să poată contesta o decizie înainte ca ea să devină cod scump.