De scope van maatwerksoftware bepalen: van wensen naar een eerste werkende versie

Kies een resultaat dat een gebruiker kan herkennen

Begin met een taak die iemand werkelijk moet afronden. Voor het onderhoudsbedrijf is dat niet “een dashboard hebben”, maar een complete aanvraag toewijzen aan een beschikbare medewerker en later terugvinden wat is afgesproken. Benoem welke informatie daarvoor nodig is en hoe de verantwoordelijke kan zien dat de toewijzing daadwerkelijk is opgeslagen.

Loop een huidig voorbeeld door zonder meteen oplossingen te tekenen. Vraag waar mensen wachten, informatie aanvullen of buiten het systeem verdergaan. Maak onderscheid tussen de gewenste uitkomst en bestaande gewoonten die misschien niet behouden hoeven te worden. Dit onderzoek kan opleveren dat de eerste versie smaller wordt dan aanvankelijk gedacht, maar een duidelijker probleem oplost.

GOV.UK Service Manual: How the discovery phase works ↗

Maak rollen en grenzen onderdeel van de opdracht

Noteer welke personen de taak starten, beoordelen en afronden. Een klant, planner en uitvoerder kunnen dezelfde aanvraag vanuit verschillende verantwoordelijkheden gebruiken. Beschrijf per rol de noodzakelijke gegevens en handelingen. “Iedereen kan inloggen” is geen uitgewerkte toegangseis; een planner mag mogelijk toewijzen terwijl een uitvoerder alleen eigen werkzaamheden bijwerkt.

Neem een uitgesloten situatie op. Een uitvoerder mag bijvoorbeeld niet via een aangepast adres een aanvraag van een andere vestiging openen. Je hoeft daarvoor in de eerste bespreking geen complete technische oplossing te kiezen. Wel moet duidelijk zijn dat de grens tot het gevraagde gedrag behoort en tijdens acceptatie wordt gecontroleerd, naast de succesvolle route voor een bevoegde medewerker.

Teken toestanden in plaats van alleen schermen

Een aanvraag kan ontvangen, onvolledig, beoordeeld, ingepland en afgerond zijn. Bespreek wat iedere toestand betekent en wie een overgang mag veroorzaken. Het verschil tussen “ingepland” en “bevestigd aan de klant” kan belangrijk zijn. Eén kleur op een overzicht mag niet stilzwijgend verschillende gebeurtenissen samenvoegen die medewerkers later apart moeten kunnen onderzoeken.

Werk een wijziging na planning uit. Blijft de oude afspraak zichtbaar, ontstaat een nieuw voorstel of wordt de eerdere planning direct aangepast? Beschrijf ook welke afgeleide informatie daardoor veroudert. Een klein toestandsmodel helpt voorkomen dat de interface eenvoudig oogt terwijl het team telkens opnieuw moet raden welke zakelijke betekenis bij een opgeslagen waarde hoort.

Een scope wordt toetsbaar wanneer duidelijk is welke situaties de eerste versie moet doorlopen: Maatwerksoftware accepteren: beoordeel complete taken en afgesproken grenzen.

Beperk gegevens tot wat de taak nodig heeft

Inventariseer de gegevens die de eerste werkstroom nodig heeft en wijs een bron aan. Een klantadres kan uit een bestaande administratie komen; een werkinstructie kan in de nieuwe applicatie ontstaan. Noteer welke gegevens alleen worden getoond, welke worden bewerkt en welke historisch moeten blijven bestaan. Zo wordt zichtbaar wanneer dezelfde term eigenlijk verschillende soorten informatie aanduidt.

Gebruik fictieve voorbeeldrecords om ontbrekende betekenis te vinden. Wat gebeurt er bij een onbekend klantnummer, een aangepast adres of twee locaties met dezelfde naam? Leg de beslissing vast voordat je een import als eenvoudige technische stap beschouwt. Het beperken van gegevens houdt de scope begrijpelijker, maar mag noodzakelijke referenties, herkomst en controle-informatie niet uit het ontwerp verwijderen.

Zet uitzonderingen naast de normale route

Kies enkele uitzonderingen die het ontwerp wezenlijk beïnvloeden: ontbrekende invoer, een ingetrokken aanvraag, een tijdelijk onbereikbaar systeem of gelijktijdige wijzigingen. Beschrijf het gewenste gedrag op hetzelfde niveau als de gewone taak. Moet het werk stoppen, wachten of door een medewerker worden beoordeeld? Wie krijgt daarover een begrijpelijk signaal en welke referentie is beschikbaar?

Niet elke denkbare uitzondering hoeft vooraf volledig te worden gebouwd. Maak onderscheid tussen gevallen die in de eerste versie worden ondersteund, situaties waarvoor een handmatige route wordt afgesproken en onzekerheden die nog onderzoek vragen. Een expliciete tijdelijke werkwijze is beter bespreekbaar dan een stilzwijgende aanname dat de gebruiker eventuele problemen later wel zelf kan oplossen.

Scheid onderzoek van uitvoerbare werkzaamheden

Sommige wensen hangen af van onbevestigde mogelijkheden. Een leverancier moet misschien API-toegang toestaan of de bestaande database blijkt onvoldoende gedocumenteerd. Formuleer daarvoor een kleine onderzoeksvraag met een concreet resultaat: een aangetoonde gegevensuitwisseling, een geschikte export of een lijst met blokkerende beperkingen. Spreek af wie informatie en toegang levert en wanneer een besluit volgt.

Plaats dergelijke onzekerheden niet ongemerkt onder een vaste belofte voor de volledige bouw. Een voorstel kan bevestigde uitvoering en een aparte onderzoeksstap bevatten. Beschrijf welke keuzes veranderen als de veronderstelling onjuist blijkt. Zo kan het onderhoudsbedrijf bijvoorbeeld besluiten eerst handmatig gegevens te exporteren in plaats van een onbewezen realtimekoppeling als voorwaarde voor de gehele eerste versie te gebruiken.

Maak oplevercriteria observeerbaar

Schrijf per belangrijke handeling op wat iemand moet kunnen vaststellen. Een aanvraag wordt onder een vaste referentie opgeslagen, een onbevoegde gebruiker krijgt geen toegang en een mislukte overdracht blijft herkenbaar openstaan. Voeg een normale invoer en een uitzonderingsgeval toe. Daarmee worden criteria sterker dan woorden als gebruiksvriendelijk, snel of volledig geïntegreerd zonder verdere uitleg.

Leg vast wie beoordeelt en waar het bewijs wordt bewaard. Een projectverantwoordelijke kan het zakelijke resultaat beoordelen terwijl een technisch beheerder de herstelhandeling controleert. Houd het onderscheid tussen een meetbare indicator en een gekozen doel helder; Google SRE beschrijft dat principe voor dienstverlening. De concrete grens moet uit jouw gebruik volgen en is geen universele technische norm.

Google SRE: Service Level Objectives ↗

Benoem wat bewust later komt

Schrijf uitsluitingen zo concreet als de inbegrepen onderdelen. In het fictieve project kan de eerste versie alleen binnenkomende onderhoudsaanvragen verwerken; automatische facturatie, voorraadbeheer en meerdere planningsregio’s komen later. Vermeld wat medewerkers in de tussentijd blijven doen. Anders kan een uitsluiting juridisch of technisch netjes lijken terwijl de dagelijkse werkwijze onbruikbaar wordt.

Controleer of een latere wens nu al een belangrijke ontwerpgrens raakt. Een tweede vestiging hoeft niet meteen te worden gebouwd, maar kan wel betekenen dat gegevens straks per organisatie gescheiden moeten blijven. Onderzoek zo’n grens gericht. Dit is geen reden om alle toekomstige functies alvast te ontwikkelen; het helpt voorkomen dat een kleine eerste stap een bekende noodzakelijke vervolgstap onnodig blokkeert.

Gebruik scope om wijzigingen te beoordelen

Een verandering wordt begrijpelijk wanneer je het oorspronkelijke en nieuwe gedrag naast elkaar legt. Welke gebruiker krijgt een extra handeling, welke gegevens ontstaan en welke bestaande regels wijzigen? Onderzoek ook welk testwerk en beheer daardoor veranderen. Een extra veld kan bijvoorbeeld invloed hebben op selectie, autorisatie, exports en documentatie, ook als het schermwerk beperkt is.

Bewaar de afgesproken eerste scope met beslissingen en proefgevallen bij een herkenbare versie. Geef nieuwe wensen een eigen besluit: nu uitvoeren, onderzoeken of parkeren. De omvang van een project blijft dan niet alleen een gesprek over uren. Je houdt zicht op het resultaat dat gekocht wordt, de aannames eronder en de dagelijkse verantwoordelijkheid nadat de eerste versie beschikbaar komt.

Van uitleg naar een concrete projectkeuze

Leg je aannames, open vragen en oplevercriteria vast in de bijbehorende tool. Gebruik de dienstengidsen om uitvoering en afbakening te bespreken.

• Maatwerksoftware ↗
• Klantportaal Laten Maken ↗

Vragen over dit onderwerp

Verder met een aansluitende vraag