Hur man kortar en anpassad ansökan utan att skriva en teknisk specifikation.

En utveckling kort behöver inte börja med ett databas diagram. Det måste förklara ett jobb som någon ska kunna slutföra och resultatet ditt företag behöver från det.

Syftet med första kortet är att göra projektet diskuteras. Du kan lämna tekniska val öppna samtidigt som du är exakt om det arbete programmet måste stödja.

Börja med en användare och en uppgift

"Bygg en portal" namn en typ av programvara. "Låt en godkänd kund skicka in en serviceförfrågan och se dess framsteg" beskriver ett användbart första arbetsflöde.

Namnge användaren, åtgärden och resultatet. Sedan identifiera vem som hanterar den andra sidan av processen. I det här exemplet måste en anställd granska begäran och uppdatera sin status. Det betyder att kortet redan innehåller två olika roller och en delad post.

Undvik att börja med "en app för alla". Olika användare kan behöva olika behörigheter, skärmar och information. Bestäm vilken roll som är viktigast i den första utgåvan.

Förklara vad som händer idag

Beskriv de aktuella stegen på vanligt språk. Kanske en kund e-post information, en anställd kopierar det till ett kalkylblad och en annan person skickar en framstegsuppdatering. State där förvirring eller upprepad ansträngning uppstår, utan att anta att programvaran kommer att lösa varje omgivande problem.

Ett redigerat exempel på den aktuella formen eller rekordet kan vara mer användbart än en polerad presentation. Ta bort personlig information och konfidentiella detaljer innan du delar den.

Beskriv en komplett resa

Följ ett representativt rekord från början till slut. Vad startar det? Vilken information krävs? Vem gör nästa beslut?

Inkludera ett eller två viktiga undantag. En begäran kan vara ofullständig, en granskare kan avvisa det eller en användare kan behöva korrigera ett misstag. Dessa fall hjälper till att skilja en fungerande ansökan från en demonstration av den ideala vägen.

Du behöver inte uppfinna varje sällsynt händelse i detta skede. Koncentrera dig på de undantag som skulle stoppa det huvudsakliga arbetsflödet från att vara användbar.

Namn på data och beroenden

Lista viktiga poster: användare, förfrågningar, produkter, bokningar, filer eller annan uppsättning information. Förklara var de kommer ifrån och vem som är ansvarig för att behålla dem.

För en integration, namnge den andra tjänsten och tillhandahålla dess dokumentation när den är tillgänglig. "Konnect to our CRM" lämnar stora frågor öppna. Den användbara detaljen är vilken rekord bör flytta, i vilken riktning och efter vilken händelse.

Identifiera om mönster, produktinnehåll, kontoåtkomst eller affärsregler redan finns tillgängliga. saknade material är inte automatiskt blockerare, men de behöver en ägare och en plats i planen.

Definiera den första användbara versionen

Separat kärnleveransen från senare idéer. En första portal kan stödja att skapa en förfrågan, granska den och visa status. Meddelanden, avancerad rapportering och en mobilapp kan vara senare diskussioner snarare än orörda krav i den första byggnaden.

Detta är inte en instruktion att bygga något ofullständigt. Det valda arbetsflödet bör fungera från början till slut. Gränsen är mellan kompletta arbetsflöden, inte mellan en attraktiv skärm och logiken som den fortfarande behöver.

Skriv ett godkännande exempel

Prova en mening som någon kan testa:

En godkänd kund kan lämna in en förfrågan, se sin status efter att ha undertecknat in och visa endast sina egna förfrågningar. En auktoriserad personal kan uppdatera statusen, och kunden ser den förändringen.

Detta är ett illustrativt krav, inte en beskrivning av ett befintligt kundprojekt. Det gör det förväntade beteendet mycket tydligare än "en modern, säker portal". Den eventuella omfattningen kan förfina behörigheter och kantfall.

Lägg till praktiska begränsningar

Ange din önskade tidpunkt, oavsett om det är en preferens eller ett fast externt datum, och budgetintervallet där det är känt. Namnge den person som kan godkänna beslut och förklara hur mönster eller återkoppling kommer att levereras.

Beskriv lanserings- och överlämningsförväntningar också. Vem kommer att äga hosting och konton? Behöver en annan utvecklare ta emot koden? Dessa frågor påverkar leveransen även när de inte visas på en skärm.

En kortare du kan använda

Vi vill bygga: ansökan eller arbetsflödet. Huvudanvändarna är: människor och roller. De måste: huvuduppgiften och slutfört resultat. Idag sker detta genom: den nuvarande processen. Den första versionen måste innehålla: Det väsentliga kompletta arbetsflödet. Det måste anslutas till: kända system och dokumentation. Vi har redan: design, innehåll, konton eller exempeldata. Fortfarande osäkra: Frågor att lösa. Timing, budget och beslutsfattare: de praktiska begränsningarna.

Använd några tydliga meningar för varje del. Kortet är en utgångspunkt för att definiera projektet, inte ett test du behöver för att passera innan du talar med en utvecklare.

Diskutera en anpassad webbapplikation eller Skicka ditt kort.