Een briefing voor een applicatie op maat opstellen zonder een technische specificatie te schrijven.

Een ontwikkelingsopdracht hoeft niet te beginnen met een database diagram. Het moet een baan uitleggen die iemand moet kunnen voltooien en het resultaat dat uw bedrijf nodig heeft.

Het doel van de eerste opdracht is om het project bespreekbaar te maken. U kunt technische keuzes open laten terwijl u precies bent over het werk dat de applicatie moet ondersteunen.

Beginnen met een gebruiker en een taak

Bouw een portal met namen van een type software. Laat een goedgekeurde klant een serviceverzoek indienen en zie de voortgang ervan beschrijft een handige eerste workflow.

Noem de gebruiker, de actie en het resultaat. Geef vervolgens aan wie de andere kant van het proces behandelt. In dit voorbeeld moet een medewerker het verzoek herzien en zijn status bijwerken. Dat betekent dat de opdracht al twee verschillende rollen en een gedeelde record bevat.

Vermijd het starten met

Leg uit wat er vandaag gebeurt.

Beschrijf de huidige stappen in de gewone taal. Misschien e-mailt een klant informatie, een medewerker kopieert het in een spreadsheet en een andere persoon stuurt een voortgangsupdate. Staat waar verwarring of herhaalde inspanning plaatsvindt, zonder aan te nemen dat de software elk omliggende probleem zal oplossen.

Een geredigeerd voorbeeld van de huidige vorm of record kan nuttiger zijn dan een gepolijste presentatie. Verwijder persoonlijke informatie en vertrouwelijke gegevens voordat u deze deelt.

Beschrijf één volledige reis

Volg een representatieve record van begin tot eind. Wat begint het? Welke informatie is nodig? Wie maakt de volgende beslissing? Wat markeert het als compleet?

Voeg een of twee belangrijke uitzonderingen toe. Een verzoek kan onvolledig zijn, een recensent kan het afwijzen of een gebruiker moet mogelijk een fout corrigeren. Deze gevallen helpen een werkende toepassing te onderscheiden van een demonstratie van het ideale pad.

U hoeft niet elke zeldzame gebeurtenis in dit stadium uit te vinden. Concentreer u op de uitzonderingen die de belangrijkste workflow zou stoppen nuttig te zijn.

Noem de gegevens en afhankelijkheden

Vermeld de belangrijke records: gebruikers, verzoeken, producten, boekingen, bestanden of een andere set van informatie. Leg uit waar ze vandaan komen en wie verantwoordelijk is voor het onderhouden ervan.

Noem bij een integratie de andere dienst en verstrek de documentatie als die beschikbaar is. “Koppel ons CRM” laat belangrijke vragen open. De nuttige informatie is welk record moet worden verplaatst, in welke richting en na welke gebeurtenis.

Identificeer of ontwerpen, productinhoud, account toegang of zakelijke regels al beschikbaar zijn. Ontbrekende materialen zijn niet automatisch blokkers, maar ze hebben een eigenaar en een plaats in het plan nodig.

Definieer de eerste handige versie

Een eerste portal kan het maken van een verzoek ondersteunen, het herzien en de status tonen. Berichten, geavanceerde rapportage en een mobiele app kunnen later worden besproken in plaats van onuitgesproken eisen van de eerste build.

Dit is geen instructie om iets onvolledigs op te bouwen. De gekozen workflow moet werken van begin tot eind. De grens ligt tussen volledige workflows, niet tussen een aantrekkelijk scherm en de logica die het nog nodig heeft.

Een acceptatievoorbeeld schrijven

Probeer een zin die iemand kan testen:

Een erkende klant kan een verzoek indienen, de status ervan zien na het aanmelden en alleen hun eigen verzoeken bekijken. Een bevoegd personeelslid kan de status bijwerken en de klant ziet die verandering.

Dit is een illustratieve vereiste, niet een beschrijving van een bestaand client project. Het maakt het verwachte gedrag veel duidelijker dan een moderne, veilige portal. De uiteindelijke scope kan verfijnen de machtigingen en rand gevallen.

Praktische beperkingen toevoegen

Vermeld uw gewenste timing, of het nu een voorkeur of een vaste externe datum, en het budget bereik waar bekend. Noem de persoon die besluiten kan goedkeuren en uitleggen hoe ontwerpen of feedback zal worden geleverd.

Beschrijf ook release- en overdrachtsverwachtingen. Wie bezit de hosting en accounts? Moet een andere ontwikkelaar de code ontvangen? Deze vragen hebben invloed op de levering, zelfs als ze niet op een scherm verschijnen.

Een brief die u kunt gebruiken

We willen bouwen: de toepassing of workflow. De belangrijkste gebruikers zijn: de mensen en rollen. Zij moeten: de belangrijkste taak en voltooid resultaat. Vandaag gebeurt dit door: het huidige proces. De eerste versie moet het volgende bevatten: de essentiële volledige workflow. Het moet verbinding maken met: de bekende systemen en documentatie. We hebben al: ontwerpen, inhoud, accounts of voorbeeldgegevens. Nog niet beslist: vragen op te lossen. Tijdschema, begroting en besluitvormer: de praktische beperkingen.

Gebruik een paar duidelijke zinnen voor elk onderdeel. De opdracht is een startpunt voor het definiëren van het project, niet een test die je moet passeren voordat je met een ontwikkelaar spreekt.

Bespreek een aangepaste webtoepassing of stuur uw brief.