Hvordan man kortlægger et brugerdefineret program uden at skrive en teknisk specifikation.

En udvikling kort behøver ikke at begynde med en database diagram. Det skal forklare et job, som nogen bør være i stand til at fuldføre og resultatet din virksomhed har brug for fra det.

Formålet med den første briefing er at gøre projektet diskuteret. Du kan lade tekniske valg åbne, mens du er præcis om det arbejde, ansøgningen skal støtte.

Begynd med en bruger og en opgave

"Byg en portal" navngiver en type software. "Lad en godkendt kunde indsende en service anmodning og se dens fremskridt" beskriver en nyttig første workflow.

Nævn brugeren, handlingen og resultatet. Identificer derefter, hvem der håndterer den anden side af processen. I dette eksempel skal en medarbejder gennemgå anmodningen og opdatere sin status. Det betyder, at briefingen allerede indeholder to forskellige roller og en delt rekord.

Undgå at starte med "en app for alle". Forskellige brugere kan have brug for forskellige tilladelser, skærme og oplysninger. Beslut hvilken rolle der betyder mest i den første udgivelse.

Forklar hvad der sker i dag

Beskriv de nuværende trin i almindeligt sprog. Måske en kunde e-mails oplysninger, en medarbejder kopierer det i et regneark, og en anden person sender en statusopdatering. State, hvor forvirring eller gentagne indsats opstår, uden at antage, at softwaren vil løse alle omkringliggende problemer.

Et redigeret eksempel på den nuværende form eller rekord kan være mere nyttigt end en poleret præsentation. Fjern personlige oplysninger og fortrolige oplysninger, før du deler det.

Beskriv en komplet rejse

Følg en repræsentativ rekord fra start til slut. Hvad starter det? Hvilke oplysninger kræves? Hvem træffer den næste beslutning? Hvad markerer det som komplet?

Inkludér en eller to vigtige undtagelser. En anmodning kan være ufuldstændig, en anmelder kan afvise den, eller en bruger kan være nødt til at rette en fejl. Disse tilfælde hjælper med at skelne et fungerende program fra en demonstration af den ideelle sti.

Du behøver ikke at opfinde hver sjælden begivenhed på dette stadium. Koncentrer dig om de undtagelser, der ville stoppe den vigtigste arbejdsgang fra at være nyttig.

Navn på data og afhængigheder

List de vigtige optegnelser: brugere, anmodninger, produkter, bookinger, filer eller et andet sæt af oplysninger. Forklar, hvor de kommer fra, og hvem der er ansvarlig for at vedligeholde dem.

For en integration, navngiv den anden tjeneste og give sin dokumentation, når tilgængelig. "Tilslut til vores CRM" efterlader store spørgsmål åbne. Den nyttige detalje er, hvilken post skal flytte, i hvilken retning og efter hvilken begivenhed.

Identificer om design, produktindhold, kontoadgang eller forretningsregler allerede er tilgængelige. Manglende materialer er ikke automatisk blokkere, men de har brug for en ejer og en plads i planen.

Definér den første nyttige version

Separat den centrale levering fra senere ideer. En første portal kan understøtte oprettelse af en anmodning, gennemgå det og vise status. Beskeder, avanceret rapportering og en mobil app kunne være senere diskussioner snarere end uudtalte krav til den første bygning.

Dette er ikke en instruktion til at bygge noget ufuldstændigt. Den valgte arbejdsgang skal fungere fra start til slut. Grænsen er mellem komplette arbejdsgange, ikke mellem en attraktiv skærm og den logik, den stadig har brug for.

Skriv et accepteksempel

Prøv en sætning nogen kunne teste:

En godkendt kunde kan indsende en anmodning, se sin status efter signing i og se kun deres egne anmodninger. En autoriseret medarbejder kan opdatere status, og kunden ser denne ændring.

Dette er et illustrativt krav, ikke en beskrivelse af et eksisterende kundeprojekt. Det gør den forventede adfærd meget klarere end "en moderne, sikker portal". Det endelige anvendelsesområde kan forfine tilladelser og kanttilfælde.

Tilføj praktiske begrænsninger

Angiv din ønskede timing, uanset om det er en præference eller en fast ekstern dato, og budget rækkevidde, hvor kendt. Navn den person, der kan godkende beslutninger og forklare, hvordan design eller feedback vil blive leveret.

Beskriv frigivelse og overdragelse forventninger også. Hvem vil eje hosting og konti? Er en anden udvikler nødt til at modtage koden? Disse spørgsmål påvirker leveringen, selv når de ikke vises på en skærm.

Et kort du kan bruge

Vi ønsker at bygge: ansøgningen eller arbejdsgangen. De vigtigste brugere er: folk og roller. De skal: hovedopgaven og det afsluttede resultat. I dag sker dette gennem: den nuværende proces. Den første udgave skal indeholde: den nødvendige fuldstændige arbejdsgang. Det skal forbinde til: de kendte systemer og dokumentation. Vi har allerede: design, indhold, konti eller eksempeldata. Stadig uafgjort: Spørgsmål, der skal løses. Tidsplan, budget og beslutningstager: de praktiske begrænsninger.

Brug et par klare sætninger for hver del. Kortet er et udgangspunkt for at definere projektet, ikke en test du skal bestå, før du taler med en udvikler.

Diskuterer en brugerdefineret webapplikation eller send din briefing.