Kennis
Behoeftes & Functionaliteit
Een wensenlijst is geen requirement. Wij schrijven op wat er écht speelt.
De meeste specificaties beschrijven een oplossing die iemand al in zijn hoofd had. Wij beginnen een stap eerder: welk probleem speelt er en wat kost het je nu? Pas daarna gaat het over functionaliteit.
De vraag achter de vraag
Klanten vragen zelden om wat ze nodig hebben.
Ze vragen om een knop, een rapport of een koppeling. Dat is de oplossing die ze zelf al bedacht hebben. Wij vragen door tot het probleem eronder zichtbaar wordt. Een raadsel heeft één antwoord. Een mysterie vraagt om onderzoek en zo behandelen we jouw vraag.
Zo schrijven wij een behoefte uit
Vijf vragen per behoefte, altijd dezelfde.
Welk probleem speelt er? Waardoor ontstaat het? Wat is de impact, welke workaround houdt het nu overeind en waar ontbreekt de regie? Beantwoord je die vijf, dan heb je geen wens meer maar een requirement dat je kunt bouwen en testen.
Ze vroegen door tot ik zelf
het echte probleem zag.
Waarom een wensenlijst geen requirements is
Vijftig wensen in een spreadsheet zeggen niets over wat je bedrijf nodig heeft.
Een wensenlijst beschrijft oplossingen die mensen al bedacht hebben. Prioriteren lukt niet want elke regel klinkt even belangrijk. Testen lukt ook niet want nergens staat wanneer het probleem opgelost is. En de tegenstrijdigheden tussen afdelingen blijven onzichtbaar tot de bouwers erop stuiten.
Wat levert het op?
- ›Bouwers weten precies wat ze moeten maken
- ›Testen kan, want elke behoefte heeft een norm
- ›Prioriteren op effect in plaats van op wie het hardst roept
- ›Minder meerwerk achteraf en minder verrassingen bij de livegang
Behoefte, functionaliteit, prioriteit
Drie lagen die in de praktijk door elkaar lopen. Uit elkaar getrokken worden ze werkbaar.
Behoefte
Wat je organisatie nodig heeft om haar werk te doen. Geschreven als probleem met oorzaak en impact, in de taal van de mensen die er dagelijks last van hebben. Nog zonder oplossing erin.
Functionaliteit
Wat het systeem moet kunnen om die behoefte te dekken. Toetsbaar opgeschreven volgens de IREB-principes: eenduidig, testbaar en zonder verborgen aannames. Een SIPOC laat zien waar de functie in de keten landt en wie er iets van merkt.
Prioriteit
Niet alles tegelijk. Theory of Constraints wijst het knelpunt aan dat de doorstroom bepaalt. Dat detailproces werken we als eerste uit. De rest wacht op zijn beurt en dat scheelt maanden aan werk dat niemand mist.
