Als je overweegt om een softwareoplossing te laten ontwikkelen, heb je misschien al een concreet beeld van hoe die oplossing eruit moet zien. Toch nemen we graag eerst de tijd om samen met jou dieper op je vraag in te gaan. Om goede software te bouwen, moeten we goed begrijpen hoe jouw processen werken, wie met de oplossing zal werken en met welke uitzonderingen we rekening moeten houden. Als we dat niet doen, bestaat de kans dat we een oplossing bouwen die in de praktijk toch niet helemaal blijkt te zijn wat jouw organisatie nodig heeft.
Daarom brengen product owners en analisten eerst je behoeften helder in kaart. Daarna vertalen ze die naar concrete functionaliteiten voor het developmentteam. Onze collega’s Mathias Broothaerts (project lead en product owner) en Brent Schillemans (product owner en developer) leggen uit hoe wij die vertaalslag van businessbehoefte naar IT-oplossing maken en wat dat jou als klant oplevert.
De vraag achter de vraag begrijpen
Elke organisatie heeft een andere mate van maturiteit op het gebied van digitalisering. Sommige klanten hebben hun processen al uitgebreid beschreven en weten precies welke richting ze op willen. Andere organisaties ervaren vooral de beperkingen van een handmatige werkwijze, een verouderde applicatie of een versnipperd proces, maar zien niet hoe ze die grenzen kunnen oplossen.
Toch blijft de eerste stap in een succesvolle vertaalslag voor ons het begrijpen van de vraag achter de vraag, zelfs als de klant al weet wat hij wil. Mathias geeft een voorbeeld: “Een van onze klanten vroeg om een uitbreiding op een applicatie die we voor hen ontwikkeld hadden. Zij hadden zelf een heel uitgebreide analyse gedaan en een heel concreet beeld in hun hoofd van hoe die uitbreiding eruit moest zien. Op papier leek alles duidelijk. Maar toen het team de analyse begon uit te tekenen in concrete mock-ups en scenario’s, doken er stelselmatig ontbrekende uitzonderingen en businessregels op. Wat op het eerste gezicht een technisch correcte oplossing leek, zou in de praktijk niet hebben gewerkt.”
Voor de klant zelf voelen de eigen processen vaak vanzelfsprekend. Daardoor blijven net de belangrijke details onuitgesproken. “Daarom starten we ieder softwaretraject graag met een analyse,” zegt Mathias. “Hoe ver die analyse gaat, passen we aan de situatie van de klant aan. Maar bij een nieuwe klant of een nieuwe richting brengen we de betrokken businessprocessen eerst in kaart met technieken zoals event storming.
Tijdens de analyse brengen we alle betrokken stakeholders aan tafel: managers, IT-profielen en medewerkers die later dagelijks met de oplossing werken. “Aan de hand van event storming brengen we uitgebreid in kaart wie welke stap in het proces uitvoert,” vertelt Mathias. “Zo krijgen we inzicht in de volledige keten. Ook voor de organisatie zelf levert dit vaak nieuwe inzichten op. Het gebeurt dat teams afhankelijkheden en knelpunten ontdekken die voordien onder de radar bleven.”
In diezelfde analyse is het belangrijk om door te vragen. Gelukkig zijn onze collega’s niet bang om dat te doen. “Elke vraag kan weer leiden tot andere vragen, en dat is soms lastig,” vult Brent aan. “Maar we blijven doorvragen totdat we alles in kaart hebben gebracht. Soms komen klanten daardoor zelf tot nieuwe inzichten: dan merk je dat ze zeggen: wacht, dat is een piste waar ik zelf nog niet aan had gedacht. Zo kom je tot een vertrekpunt dat steunt op de realiteit over afdelingen heen, in plaats van op aannames.”
Van inzichten naar prototype
Zodra we jouw behoeften met de analyse in kaart hebben gebracht, vertalen we die naar functionele blokken en concrete features. Hierbij proberen we de oplossing al snel zoveel mogelijk visueel te maken. “Als je iets alleen mondeling uitlegt, heeft iedereen een ander beeld in zijn hoofd,” zegt Mathias. “Het is dan moeilijk om feedback te krijgen. Met een mock-up zorg je ervoor dat de klant en het developmentteam naar hetzelfde doel kijken. Zo kunnen ze het meteen challengen en bijsturen.” Brent vult aan: “Ik ben zelf heel visueel ingesteld. Een mock-up meteen kunnen zien, in plaats van er alleen over te horen, maakt het voor mij veel duidelijker wat er precies gebouwd moet worden.”
AI versnelt dat proces vandaag aanzienlijk. “Vroeger kostte een klikbaar prototype soms dagen werk,” vertelt Mathias. “Met AI kunnen we veel sneller iets tastbaars tonen en samen met de klant valideren. De kwaliteit van de input blijft daarbij wel bepalend.” Ook Brent herkent die meerwaarde. “Bij een van mijn projecten heb ik een screenshot genomen van een scherm dat herwerkt moest worden. Dankzij AI kon ik dat snel herwerken naar een mock-up met de gevraagde aanpassingen. Dat bleek al voldoende om snel met de klant af te stemmen of ik in de juiste richting zat. Zo kunnen we snel schakelen.”
Bij grotere projecten met veel verschillende onderdelen gebruiken we story mapping: we zetten de stappen die een gebruiker doorloopt naast elkaar en plaatsen daaronder, per stap, de functies van meest naar minst essentieel. “We bepalen samen met de klant wat er over de hele reis heen minimaal nodig is om de software te laten werken,” legt Mathias uit. “Dat pasten we onlangs nog toe voor een klant met meer dan 180 eindgebruikers, voor een applicatie met verschillende onderdelen. Wij kozen uit elk onderdeel de belangrijkste functies, zodat de MVP al de hele keten kon ondersteunen. Dat geeft ons bovendien de kans om een eerste versie te testen bij eindgebruikers en hun feedback te verwerken. Pas als die basis goed zit, kunnen we daarna gericht verder uitbreiden.
Snel bijsturen tijdens de ontwikkeling
De vertaalslag stopt niet zodra de ontwerpfase is afgerond. Ook tijdens de ontwikkeling blijven we continu afstemmen via vaste overlegmomenten. “Een vraag vooraf valideren kost meestal maar vijf minuten,” zegt Mathias. “Als iets al gebouwd is en het moet herwerkt worden, dan spreek je al snel over meerdere dagen werk. Hoe sneller we iets kunnen afstemmen, hoe beter dus.” Brent benadrukt daarom het belang van een open contactlijn naast de vaste overlegmomenten. “Snel een bericht kunnen sturen of even bellen om een korte vraag meteen af te toetsen, voorkomt verwarring en zorgt ervoor dat we sneller tot een goed resultaat komen.”
Voordat onze developers starten met ontwikkelen, krijgen zij ook de businesscontext mee. Het is belangrijk dat ze weten welk probleem een bepaalde feature moet oplossen. “Bij een nieuw project of een nieuwe klant starten we het liefst samen met het hele team aan tafel”, vertelt Brent. “Zo trap je het project gezamenlijk af, in plaats van het gewoon aan development te ‘geven’. Het is heel belangrijk dat onze developers het ‘waarom’ achter een feature begrijpen. Als ze weten welk probleem ze oplossen, kunnen ze keuzes maken die beter aansluiten bij de behoeften van de eindgebruiker.”
Die eindgebruikers worden trouwens vroeg betrokken. Zij mogen onder andere prototypes beoordelen en demo’s bekijken. “Als je gebruikers vanaf het begin betrekt en laat zien wat er met hun feedback gebeurt, creëer je buy-in,” vult Mathias aan. “Ze krijgen dan de kans om de oplossing actief mee vorm te geven. De kwaliteit van de oplossing wordt daardoor beter en je creëert tegelijk meer draagvlak voor het effectief gebruiken van de oplossing.”
Wat is een correcte vertaalslag van businessbehoefte naar IT-oplossing?
Een goede analyse en een vlotte samenwerking zijn één ding, maar het resultaat is natuurlijk het belangrijkste. Hoe weten we dan of het resultaat is wat er nodig was om het probleem op te lossen? “Als je ziet dat de oplossing effectief wordt gebruikt, weet je dat je goed zit,” zegt Mathias. “Een nog sterker signaal is wanneer klanten zelf beginnen na te denken over uitbreidingen. Dan heeft de software voor hen duidelijke waarde.”
Brent herkent dat signaal ook: “Het duidelijkste teken is wanneer de oplossing gewoon deel wordt van hun dagelijkse workflow,” zegt hij. “Dat vertellen klanten niet altijd expliciet, maar je merkt het aan hoe vanzelfsprekend ze de oplossing zijn gaan gebruiken.” Hij merkt het ook aan de impact op het dagelijkse werk van medewerkers: “Als mensen van een berg manueel werk naar een proces gaan waarin ze met een paar klikken klaar zijn, dan weet je dat de software het verschil heeft gemaakt. Daar haal ik veel voldoening uit.”
Luisteren, processen begrijpen, kritisch doorvragen en ideeën valideren: dat vormt de basis voor een correcte vertaalslag van businessbehoefte naar IT-oplossing. Door business en technologie gedurende het hele traject met elkaar te verbinden, bouwen we oplossingen die bij jouw organisatie passen en mee kunnen groeien in de toekomst.
