Ce este un prototip?

În arhitectură nimeni nu toarnă fundația înainte de machetă; în software, echivalentul ei e prototipul: o machetă interactivă a aplicației — ecranele desenate și legate între ele (în unelte ca Figma), pe care poți apăsa, naviga și parcurge fluxurile ca și cum produsul ar exista — doar că în spate nu e nimic: fără cod, fără bază de date, fără logică. Rostul lui e economia brutală a corecțiilor: aceeași schimbare care în prototip costă o oră de design („mutăm pasul de plată înaintea datelor de livrare”) costă zile de dezvoltare în aplicația construită — iar erorile de concepție (fluxul care derutează, ecranul de care nu are nimeni nevoie, câmpurile care lipsesc) se văd abia la utilizare, deci sănătos e să existe ceva utilizabil înainte de a fi construit. Folosirea corectă are două fețe: cu utilizatorii reali (pui prototipul în mâna a 5-7 oameni din publicul țintă, le dai sarcini — „comandă produsul X”, „găsește factura din martie” — și taci: unde ezită, unde apasă greșit, ce nu găsesc — fiecare poticnire e o corecție ieftină; cinci utilizatori descoperă majoritatea problemelor mari, e statistica veche a domeniului) și cu echipa de dezvoltare — prototipul validat devine cea mai precisă specificație posibilă: ofertele pe prototip sunt sensibil mai exacte decât cele pe documente de cerințe, pentru că nimic nu descrie un produs mai clar decât simulacrul lui funcțional. De aici și locul lui firesc în proiecte: după clarificarea nevoii, înaintea dezvoltării — o etapă de zile-săptămâni și de cost mic, care disciplinează tot ce urmează. Confuzia de evitat în discuții: prototipul nu e versiune timpurie a produsului (aia e MVP-ul — real, funcțional, în piață) și nu verifică fezabilitatea tehnică (aia e PoC-ul); prototipul verifică forma: să fie clar, folosibil și dorit — înainte să devină scump.