Când un proiect software dezamăgește, analiza de după se uită de obicei la livrare: estimări, viteză, perimetru scăpat de sub control, echipă. Uneori asta este explicația reală.
Mai des, rezultatul a fost decis cu luni înainte, în câteva discuții pe care nimeni nu le considera tehnice. Faza de discovery este momentul în care aceste discuții au loc în mod deliberat.
Ce este faza de discovery
Discovery este o etapă scurtă și concentrată, înainte de dezvoltare, în care deciziile de business, de produs și tehnice care modelează proiectul sunt luate și scrise. Nu este o amânare și nici un document de dragul documentului: valoarea ei stă în deblocarea dezvoltării și în evitarea greșelilor care costă mult mai târziu.
Patru decizii care modelează un proiect
- Perimetrul scris ca rezultate, nu ca funcționalități. „Reducem timpul de la cerere la ofertă” îi spune echipei ce să protejeze când se strâng termenele; „un generator de oferte cu export PDF” nu.
- Presupunerea cea mai riscantă, testată prima. Orice proiect se sprijină pe ceva neverificat: calitatea datelor, un API extern, o migrare, acceptarea utilizatorilor. Testată în prima săptămână e ieftină; descoperită la final, nu.
- Arhitectura aleasă conștient. Baza de date, modul de randare, felul în care funcționează identitatea și permisiunile: sunt scumpe de schimbat și merită o justificare scrisă.
- O definiție agreată a succesului. O propoziție care spune ce trebuie să obțină prima versiune previne multă dezamăgire mai târziu.
Ce trebuie să producă discovery
- Descrierea problemei și rezultatul de măsurat, cu cifra care va arăta succesul.
- Utilizatorii și traseele lor principale, inclusiv cele rare, dar importante.
- Perimetrul primei versiuni, cu o listă explicită a ce rămâne pe dinafară.
- Riscurile și presupunerile principale și felul în care este testată fiecare.
- Arhitectura și alegerile tehnologice, cu motivele din spatele lor.
- Un plan de livrare, cu etape și o estimare pe baza căreia echipa ta poate decide.
Cine ar trebui să participe
Discovery eșuează discret atunci când lipsesc oamenii potriviți. Din partea ta și a furnizorului, e nevoie de:
- Persoana care decide bugetul și prioritățile, măcar la început și la revizia finală.
- Oamenii care rulează procesul sau servesc clienții azi, pentru că ei știu unde sunt problemele reale.
- Cine se ocupă de sistemele și datele existente, chiar dacă nu va construi nimic.
- Din partea furnizorului: oamenii care vor proiecta și construi produsul, nu doar un vânzător sau un analist.
Cum decurge un discovery, pas cu pas
- Stabilești obiectivul și întrebarea la care trebuie să răspundă discovery, pe o pagină.
- Discuți cu oamenii care folosesc, rulează și plătesc procesul și te uiți la instrumentele și documentele reale cu care lucrează.
- Descrii cum se desfășoară munca azi, inclusiv datele: unde se află, cine le modifică și cât de curate sunt.
- Testezi direct presupunerea cea mai riscantă, printr-o verificare tehnică rapidă sau un prototip pe care îl pui în fața utilizatorilor.
- Definești perimetrul primei versiuni și arhitectura, cu motivele din spatele fiecărei alegeri.
- Estimezi, planifici etapele și revizuiești totul cu oamenii care decid.
Cum judeci rezultatul
Un discovery este bun dacă trece câteva verificări simple:
- O persoană nouă poate înțelege proiectul din rezultate într-o oră.
- Fiecare element din prima versiune poate fi legat de rezultatul pe care îl servește.
- Fiecare risc important are un responsabil și o metodă de testare.
- Estimarea își declară presupunerile, deci știi ce ar schimba-o.
- Echipa ta ar putea preda planul altui furnizor și l-ar putea folosi în continuare.
Ce nu ar trebui să fie
- Un document lung pe care nu îl mai citește nimeni după aprobare.
- Un exercițiu doar de design, care ocolește întrebările tehnice și cele despre date.
- O etapă de vânzare a cărei singură concluzie este „construim tot”.
Cât durează
De obicei săptămâni, nu luni. Este intenționat scurtă: suficient cât să răspundă la întrebările care altfel ar apărea în mijlocul dezvoltării și suficient de scurtă cât proiectul să nu își piardă ritmul.
Când poți sări peste ea
- Modificarea este mică și bine înțeleasă, de exemplu o pagină nouă sau o integrare cu un API documentat.
- Ai deja specificații clare, validate cu utilizatorii și verificate tehnic.
- Proiectul repetă ceva ce echipa ta a mai construit, pe aceeași tehnologie.
Întrebări frecvente
Poate altă firmă să construiască pe baza rezultatelor din discovery?
Ar trebui să poată. Un discovery bun produce un plan pe care echipa ta sau orice furnizor competent îl poate executa. Această independență face parte din valoarea lui.
Discovery înlocuiește un caiet de sarcini detaliat?
Înlocuiește tipul de caiet de sarcini scris înainte ca cineva să fi testat părțile riscante. Detaliile fiecărei funcționalități se lucrează mai bine în timpul dezvoltării, pe baza deciziilor luate în discovery.
Discovery înseamnă același lucru cu un prototip?
Nu chiar. Un prototip poate fi unul dintre instrumentele folosite în discovery, ca să testezi o presupunere cu utilizatorii, dar discovery acoperă și perimetrul, datele, arhitectura și planul.
Ce facem dacă discovery arată că nu merită construit?
Atunci și-a făcut treaba. Să afli înainte de dezvoltare că un proiect nu se va amortiza este cea mai ieftină cale posibilă de a afla.
