PRD TEHNIC
Definiție
PRD vine de la product requirements document, adică documentul care descrie ce trebuie să facă un produs, pentru cine, în ce condiții și cum se recunoaște că e gata. Nu e un termen de inteligență artificială, ci o practică veche din dezvoltarea de software, dar a devenit brusc relevantă pentru oameni fără pregătire tehnică: în vibe coding, calitatea rezultatului depinde aproape integral de claritatea cererii, iar un PRD e forma disciplinată a cererii. Confuzia frecventă e că ar fi un document lung și formal; pentru o unealtă internă, o pagină e suficientă și mai utilă decât zece.
Un PRD folositor răspunde la cinci întrebări și se oprește acolo: ce problemă rezolvă unealta și pentru cine, ce primește la intrare și ce livrează la ieșire, ce trebuie să se întâmple când datele sunt greșite sau lipsesc, ce nu face unealta, și cum verifici că funcționează corect. Ultimele două sunt cele omise sistematic și cele care produc cele mai multe reluări. Fără lista lucrurilor pe care unealta nu le face, modelul completează singur cu presupuneri; fără criteriul de verificare, nu ai cum să spui dacă rezultatul e bun, ci doar dacă pare bun.
În practică, PRD-ul e ceea ce transformă vibe coding-ul dintr-o conversație lungă într-un proiect. Scris înainte, e cererea pe care i-o dai modelului și, în același timp, criteriul față de care judeci ce primești. Păstrat lângă unealtă, e explicația pentru colegul care o preia și pentru tine peste un an. Un asistent poate să îl scrie el, la cerere, pornind de la descrierea ta, iar exercițiul cel mai valoros e să îl citești și să corectezi ce a înțeles greșit. Neînțelegerile apar acolo, pe o pagină, nu după trei ore de cod.
Exemple practice
- O pagină înainte de prima linie de cod: ce fișiere intră, ce iese, ce se întâmplă la un rând invalid, ce nu face unealta, cum verific rezultatul.
- Secțiunea cel mai des omisă și cea mai utilă: „unealta nu face”. Fără ea, modelul completează cu presupuneri rezonabile, dar care nu sunt ale tale.
- PRD-ul păstrat lângă unealtă, în folderul proiectului: colegul care o preia peste un an înțelege în cinci minute ce ar fi reconstituit din cod în două ore.
Întrebări frecvente
Nu e prea mult formalism pentru un script de treizeci de linii?
Pentru un script rulat o dată, da. Din momentul în care unealta o va folosi și altcineva sau o vei rula lunar, o pagină scrisă înainte costă mai puțin decât a treia reluare a cererii.
Pot să îl scriu cu ajutorul asistentului?
Da, și e chiar recomandat: îi descrii problema, îți scrie documentul, iar tu îl citești și corectezi. Partea valoroasă e lectura, fiindcă acolo vezi ce a înțeles greșit, cât timp corectarea costă o frază.
Ce nu trebuie să lipsească din el?
Criteriul de verificare și lista lucrurilor pe care unealta nu le face. Restul se poate deduce sau completa pe parcurs; aceste două secțiuni, dacă lipsesc, produc o unealtă care pare corectă și nu poate fi verificată.