Definitie: De discovery-fase is de voorbereidende fase van een softwareproject waarin je onderzoekt wat er gebouwd moet worden, voor wie, waarom en binnen welke grenzen, voordat de ontwikkeling begint. De uitkomst is een afgebakende opdracht met eisen, schetsen, risico’s en een onderbouwde planning en begroting.
In het kort
- In de discovery-fase breng je het probleem, de gebruikers, het proces, de technische randvoorwaarden en de risico’s in kaart.
- De fase levert meestal een programma van eisen, schermschetsen of een klikbaar prototype, een technisch voorstel en een raming op.
- Afhankelijk van de omvang duurt een discovery-fase volgens Innowise ongeveer 1 tot 2 weken voor een klein project en 4 tot 6 weken voor een groter project.
- Een goede discovery verkleint de kans dat je het verkeerde bouwt, en maakt een offerte voor de bouw vergelijkbaar en controleerbaar.
Wat is een discovery-fase?
De discovery-fase, in het Nederlands ook ontdekkingsfase of scopingfase genoemd, is de periode waarin opdrachtgever en ontwikkelaar samen uitzoeken wat een project precies moet opleveren. Het idee is eenvoudig: hoe later je een fout in de opzet ontdekt, hoe duurder het wordt om hem te herstellen. Een verkeerd begrepen werkproces is in een gesprek met een paar vragen recht te zetten. Hetzelfde misverstand in werkende software kost weken.
In de discovery-fase wordt nog niet gebouwd. Je onderzoekt, schetst, toetst en besluit. Aan het eind weet je wat de eerste versie moet kunnen, wat er bewust buiten blijft, welke systemen eraan gekoppeld worden en wat de grootste onzekerheden zijn.
Waarom een discovery-fase?
- Het juiste probleem oplossen. Een aanvraag begint vaak bij een oplossing (“we willen een app”). De discovery-fase gaat terug naar het probleem en de mensen die ermee werken.
- Een realistische begroting. Zonder afbakening is elke offerte een gok, met een flinke marge voor onzekerheid.
- Minder meerwerk. Uitzonderingen en afhankelijkheden komen vooraf op tafel, niet halverwege de bouw.
- Gedeeld beeld. Opdrachtgever, gebruikers en ontwikkelaar praten daarna over hetzelfde.
- Een beslismoment. Soms blijkt in de discovery dat een bestaand pakket of een eenvoudige koppeling volstaat. Dan bespaar je de bouw helemaal.
Wat gebeurt er in de discovery-fase?
- Doel en aanleiding. Wat moet er beter, sneller of anders, en hoe merk je dat?
- Gebruikers en rollen. Wie gaat de software gebruiken, en welke taak moet die persoon als eerste kunnen afronden?
- Huidig proces. Hoe gaat het nu, welke stappen, welke systemen, welke spreadsheets en welke uitzonderingen?
- Gewenst proces. Hoe ziet de nieuwe route eruit, en waar beslist een mens?
- Eisen en prioriteiten. Wat is noodzakelijk voor de eerste versie, wat is wenselijk en wat komt later?
- Techniek en koppelingen. Met welke systemen moet de software praten, welke gegevens zijn er en wat zijn de randvoorwaarden voor beveiliging en privacy?
- Schetsen of prototype. Schermschetsen of een klikbaar prototype om te toetsen of de opzet klopt.
- Risico’s. Wat is onzeker, en hoe maak je dat kleiner?
- Voorstel en raming. Een afgebakend voorstel voor de eerste versie met planning en begroting.
Vragen die na de discovery beantwoord moeten zijn
Een handige toets voor een geslaagde discovery is of je deze vragen helder kunt beantwoorden:
- Welk probleem lossen we op, en hoe merken we dat het opgelost is?
- Wie gebruikt de eerste versie, en welke taak moet die persoon kunnen afronden?
- Wat komt er binnen in het proces, wie moet ermee verder en welke informatie heeft die persoon nodig?
- Welke stappen gebeuren automatisch en waar beslist een mens?
- Welke systemen en gegevens zijn nodig, en wie is daar eigenaar van?
- Wat zit er bewust niet in de eerste versie?
- Wat zijn de grootste onzekerheden, en hoe toetsen we die vroeg?
- Wat kost de eerste versie, en wat kost het daarna om hem te beheren?
Kun je een van deze vragen niet beantwoorden, dan is dat precies het punt om nog even bij stil te staan voordat de bouw begint.
Hoe ziet een discovery-traject er in de praktijk uit?
Een discovery voor een middelgroot project kan er bijvoorbeeld zo uitzien:
| Stap | Wat er gebeurt |
|---|---|
| Kennismaking | Aanleiding, doel en betrokkenen in kaart |
| Werksessies | Proces doorlopen met opdrachtgever en gebruikers |
| Analyse | Eisen ordenen, bestaande systemen en gegevens bekijken |
| Schetsen | Belangrijkste schermen en route uitwerken |
| Toetsen | Schetsen of prototype voorleggen aan gebruikers |
| Voorstel | Afbakening eerste versie, planning, raming en risico’s |
Dit is een voorbeeldopbouw, geen vaste methode. Bij kleine projecten vallen stappen samen in één of twee sessies, bij grote projecten worden ze uitgebreider en herhaald.
Wanneer kun je de discovery kort houden?
Niet elk project heeft weken voorbereiding nodig. Een korte discovery volstaat als het proces overzichtelijk is, er weinig gebruikersgroepen zijn, er nauwelijks koppelingen nodig zijn en de opdrachtgever al een duidelijk beeld heeft van de eerste versie. Ook dan blijft het waardevol om het proces, de rollen en de grenzen van de eerste versie op papier te zetten. Het kost weinig tijd en voorkomt dat beide partijen iets anders voor ogen hebben.
Wat levert een discovery-fase op?
| Onderdeel | Wat erin staat |
|---|---|
| Probleem- en doelbeschrijving | Aanleiding, gewenste uitkomst en hoe je succes meet |
| Gebruikers en rollen | Wie werkt ermee, met welke rechten en welke taken |
| Procesbeschrijving | Huidige en gewenste route, inclusief uitzonderingen |
| Programma van eisen | Functionele en niet-functionele eisen, met prioriteit |
| Schetsen of prototype | Hoe de belangrijkste schermen eruitzien en werken |
| Technisch voorstel | Opbouw, techniek, koppelingen, datamodel en beveiliging |
| Risico’s en aannames | Wat onzeker is en hoe dat wordt aangepakt |
| Voorstel eerste versie | Afbakening, planning en raming |
Het artikel van Marka noemt als typische opbrengst onder meer een specificatie van eisen, persona’s en journey maps, een klikbaar prototype, een architectuurdocument, een risicoregister en een roadmap met kostenraming. Bij kleinere projecten is dat vaak compacter, maar de onderwerpen blijven dezelfde.
Hoe lang duurt een discovery-fase?
De duur hangt af van de omvang en complexiteit van het project. Innowise noemt ongeveer 1 tot 2 weken voor een klein project en 4 tot 6 weken voor een groter project. Wavect spreekt van weken, niet maanden. Voor een afgebakende interne tool of een eerste versie van een webapplicatie is een korte, gerichte discovery meestal genoeg. Bij een project met veel gebruikersgroepen, koppelingen of regelgeving is meer tijd nodig.
Wat kost een discovery-fase?
Openbare prijzen zijn schaars, omdat de omvang sterk verschilt. Wavect noemt een vanafprijs van € 3.500. Andere partijen rekenen de discovery op uurbasis of als vast bedrag op basis van het aantal sessies en documenten. Vergelijk daarom vooral wat er wordt opgeleverd: een discovery die eindigt met een helder voorstel dat je ook bij een andere partij kunt neerleggen, is meer waard dan een reeks gesprekken zonder vastgelegd resultaat.
Discovery-fase, programma van eisen of prototype?
| Discovery-fase | Programma van eisen | Klikbaar prototype | |
|---|---|---|---|
| Wat is het? | Een fase met onderzoek en besluiten | Een document met eisen | Een klikbare weergave van schermen |
| Doel | Bepalen wat er gebouwd wordt en waarom | Vastleggen wat de software moet kunnen | Toetsen of de opzet werkt voor gebruikers |
| Relatie | Bevat vaak een programma van eisen en een prototype | Is een opbrengst van de discovery | Is een hulpmiddel binnen de discovery |
Wat doe je met de uitkomst?
De opbrengst van een discovery is pas waardevol als je er iets mee doet. Er zijn grofweg drie vervolgstappen:
- Bouwen zoals voorgesteld. De afbakening is helder, de raming past in het budget en de eerste versie kan starten.
- Bijsturen. De raming is hoger dan verwacht, of een onderdeel blijkt onzeker. Je schuift functies naar later of toetst eerst een prototype.
- Niet bouwen. De analyse laat zien dat een bestaand pakket, een koppeling of een aangepaste werkwijze volstaat.
Alle drie zijn een goede uitkomst. Het doel van de discovery is niet om een bouwopdracht te rechtvaardigen, maar om een onderbouwd besluit te nemen. Zorg daarom dat de documenten zo zijn opgesteld dat ook een andere partij ermee verder kan. Dan blijf je vrij in je keuze, en kun je offertes eerlijk vergelijken op basis van dezelfde afbakening.
Wie is erbij betrokken?
- De opdrachtgever of eigenaar van het proces, die beslist over doel, budget en prioriteiten.
- Eindgebruikers, omdat zij weten hoe het werk echt verloopt en waar het vastloopt.
- De ontwikkelaar of het team, voor techniek, haalbaarheid en raming.
- Eventueel ontwerp, voor schermen, flows en gebruikerservaring.
- Eventueel IT of beheer, voor bestaande systemen, beveiliging en hosting.
Veelgemaakte fouten
- De discovery overslaan om tijd te winnen. De tijd komt later terug als meerwerk en herbouw.
- Alleen met de leiding praten. Zonder eindgebruikers mis je de uitzonderingen die het dagelijkse werk bepalen.
- Te veel in de eerste versie willen. Een discovery die alles prioriteert als noodzakelijk, heeft niet afgebakend.
- Geen tastbare opbrengst. Spreek vooraf af welke documenten en schetsen je krijgt.
- De uitkomst niet durven gebruiken. Als de discovery laat zien dat maatwerk niet nodig is, is dat ook een goede uitkomst.
- Aannames niet vastleggen. Wat je vooraf aanneemt over gegevens, volumes of koppelingen, moet zichtbaar in het voorstel staan, zodat iedereen weet waarop de raming rust.
Wat betekent dit voor jouw project?
Mijn werkwijze volgt dezelfde gedachte. Ik begin met een procesgesprek van ongeveer twintig minuten over het probleem, de gebruikers, de impact en de huidige werkwijze. Daarna volgt een betaalde blauwdruk: het afgebakende proces, schermschetsen, afhankelijkheden en een voorstel voor de eerste versie. Pas daarna wordt er gebouwd.
Ik wil vooraf duidelijk hebben wat we met een eerste versie bedoelen. Bij een nieuw idee vraag ik daarom altijd wie het gaat gebruiken en welke taak die persoon als eerste moet kunnen afronden. Ik onderzoek ook eerst of een bestaand pakket, een koppeling of maatwerk het beste past. Het feit dat een applicatie gebouwd kan worden, maakt de commerciële vraag nog niet beantwoord.
Heb je een idee, maar weet je nog niet precies wat de eerste versie moet doen? Stuur me voor wie het is, wat er nu gebeurt en wat de eerste versie moet oplossen. Dan bepalen we samen de logische eerste stap.
Veelgestelde vragen over de discovery-fase
Wat is een discovery-fase?
De discovery-fase is de voorbereidende fase van een softwareproject waarin je onderzoekt wat er gebouwd moet worden, voor wie en binnen welke grenzen. De uitkomst is een afgebakende opdracht met eisen, schetsen, risico’s en een raming.
Wat is een discovery sessie bij software?
Een discovery sessie is een werksessie binnen de discovery-fase waarin opdrachtgever, gebruikers en ontwikkelaar samen het probleem, het proces en de eisen bespreken. Een discovery-fase bestaat vaak uit meerdere van zulke sessies.
Hoe lang duurt een discovery-fase?
Dat hangt af van de omvang van het project. Voor een klein project is 1 tot 2 weken gebruikelijk, voor een groter project 4 tot 6 weken.
Verwante termen
Programma van eisen · Klikbaar prototype · Prototype · Fixed price vs nacalculatie · Build vs buy · Webapplicatie
← Terug naar de kennisbank