Cum de a scurta o cerere personalizată fără a scrie o specificație tehnică.

Un scurt de dezvoltare nu are nevoie pentru a începe cu o diagramă de bază de date. Ea trebuie să explice un loc de muncă pe care cineva ar trebui să fie în măsură să completeze și rezultatul de afaceri are nevoie de ea.

Scopul primului scurt este de a face proiectul discutabil. Puteți lăsa alegerile tehnice deschise în timp ce sunt precise despre munca pe care aplicația trebuie să o susțină.

Începe cu un utilizator și o sarcină

Construieşte un portal şi defineşte un tip de software. ? Lasa un client aprobat să prezinte o cerere de servicii şi vezi progresul său.

Numeşte utilizatorul, acţiunea şi rezultatul. Apoi identifică cine se ocupă de cealaltă parte a procesului. În acest exemplu, un membru al personalului trebuie să revizuiască cererea şi să-şi actualizeze statutul. Asta înseamnă că rezumatul conţine deja două roluri diferite şi o înregistrare comună.

Evitați pornirea cu o aplicație pentru toată lumea. Diferite utilizatori pot avea nevoie de permisiuni diferite, ecrane și informații. Decide care rol contează cel mai mult în prima versiune.

Explică ce se întâmplă astăzi.

Descrieți pașii actuali în limba obișnuită. Poate o informație despre e-mailurile clienților, un membru al personalului o copiază într-o foaie de calcul și o altă persoană trimite o actualizare a progreselor. Starea în care apare confuzie sau efort repetat, fără a presupune software-ul va rezolva fiecare problemă din jur.

Un exemplu redactat al formei sau înregistrării actuale poate fi mai util decât o prezentare lustruită. Eliminați informațiile personale și detaliile confidențiale înainte de a le împărtăși.

Descrieţi o călătorie completă

Urmați un record reprezentativ de la început până la sfârșit. Ce începe? Ce informații este necesar? Cine ia următoarea decizie? Ce marchează ca completă?

Include una sau două excepţii importante. O cerere poate fi incompletă, un revizor o poate respinge sau un utilizator poate avea nevoie pentru a corecta o greşeală. Aceste cazuri ajută la diferenţierea unei aplicaţii de lucru de o demonstraţie a traseului ideal.

Nu aveți nevoie pentru a inventa fiecare eveniment rar în acest stadiu. Concentrează-te pe excepțiile care ar opri fluxul principal de lucru de la a fi util.

Denumire date și dependențe

Listați înregistrările importante: utilizatori, cereri, produse, rezervări, fișiere sau un alt set de informații. Explicați de unde provin și cine este responsabil pentru menținerea acestora.

Pentru o integrare, numeşte celălalt serviciu şi furnizează documentaţia sa atunci când este disponibil. bază Conectaţi-vă la întrebările noastre majore deschise. Detaliile utile sunt cele care trebuie să se mişte, în ce direcţie şi după ce eveniment.

Identificați dacă proiectele, conținutul produsului, accesul la cont sau regulile de afaceri sunt deja disponibile. Materialele lipsă nu sunt automat blocante, dar au nevoie de un proprietar și un loc în plan.

Defineşte prima versiune utilă

Separa livrarea de bază de ideile ulterioare. Un prim portal ar putea sprijini crearea unei cereri, revizuirea și prezentarea statutului. Message, raportarea avansată și o aplicație mobilă ar putea fi discuții mai târziu decât cerințe nerostite ale primei construcții.

Aceasta nu este o instrucţiune pentru a construi ceva incomplet. Fluxul de lucru ales ar trebui să funcţioneze de la început până la sfârşit. Graniţa este între fluxurile de lucru complete, nu între un ecran atractiv şi logica de care are încă nevoie.

Scrie un exemplu de acceptare

Încercați o propoziție cineva ar putea testa:

Un client aprobat poate depune o cerere, poate vedea statutul său după semnarea și vizualizarea numai propriile cereri. Un membru autorizat al personalului poate actualiza statutul, iar clientul vede această schimbare.

Aceasta este o cerinţă ilustrativă, nu o descriere a unui proiect client existent. Ea face comportamentul aşteptat mult mai clar decât un portal modern şi sigur. Posibilul domeniu de aplicare poate rafina permisiunile şi cazurile de margine.

Adăugați constrângeri practice

Menționați calendarul dorit, fie că este vorba de o preferință sau de o dată externă fixă, precum și intervalul bugetar, dacă este cunoscut. Spuneți persoana care poate aproba deciziile și explica cum vor fi furnizate proiectele sau feedback-ul.

Cine va detine gazduirea si conturile? Are nevoie un alt dezvoltator de a primi codul? Aceste intrebari afecteaza livrarea chiar si atunci cand nu apar pe un ecran.

Un scurt pe care îl puteți folosi

Vrem să construim: aplicarea sau fluxul de lucru. Utilizatorii principali sunt: oamenii şi rolurile. Acestea trebuie: sarcina principală și rezultatul finalizat. Astăzi acest lucru se întâmplă prin: procesul actual. Prima versiune trebuie să includă: fluxul de lucru complet esențial. Trebuie să se conecteze la: sistemele și documentația cunoscute. Avem deja: proiecte, conținut, conturi sau date de exemplu. Încă indecis: întrebări de rezolvat. Calendar, buget și factor de decizie: constrângerile practice.

Utilizați câteva propoziții clare pentru fiecare parte. Scurt este un punct de plecare pentru definirea proiectului, nu un test pe care trebuie să-l treci înainte de a vorbi cu un dezvoltator.

Discutați o aplicație web personalizată sau trimiteți descrierea proiectului.