Iedereen heeft softwarewensen. Welke aanpassing komt eerst?

“We hebben een dashboard nodig” is al een voorstel voor een oplossing. Vraag eerst welke beslissing iemand nu niet goed kan nemen. Moet verkoop zien welke klanten aandacht nodig hebben? Wil de planning weten welke opdrachten nog niet uitvoerbaar zijn? Hetzelfde woord kan verschillende vragen verbergen.

Laat de aanvrager een recente situatie laten zien. Wat wilde die doen, welke informatie ontbrak en wat was het gevolg? Betrek de collega die daarna met het resultaat verder moet. Een export die één afdeling helpt, kan elders nieuw controlewerk veroorzaken. Een kort gesprek over de hele handeling geeft meer richting dan alleen extra velden verzamelen.

De Britse Government Digital Service adviseert bij prioriteiten bepalen om gebruiksonderzoek, prestatiegegevens en betrokkenen samen te brengen. Die handleiding is geschreven voor publieke dienstverlening. Hieronder passen we het principe toe op doorontwikkeling binnen een onderneming, zonder één vaste scoremethode voor ieder bedrijf voor te schrijven.

Een lijst wensen zegt weinig als de beschikbare aandacht ontbreekt. Maak zichtbaar wat al is toegezegd, welk noodzakelijk beheer doorgaat en hoeveel tijd medewerkers hebben om mee te ontwerpen en te testen. De capaciteit van de ontwikkelaar is maar één deel van de uitvoering.

Behandel een ernstig incident of een aantoonbaar urgent beveiligingsprobleem via de afgesproken verantwoordelijke en herstelroute. Laat dat niet stilzwijgend concurreren met een handig nieuw scherm. Andersom verdient niet ieder technisch verbeterpunt automatisch voorrang: vraag welk probleem het voorkomt, welke termijn ertoe doet en wat uitstel betekent.

Spreek af wie over de volgorde beslist en wie de benodigde kennis levert. De ondernemer kan richting en budget bepalen, terwijl een productverantwoordelijke binnen die grenzen keuzes maakt. Medewerkers moeten kunnen toelichten wat zij nodig hebben en een onjuiste aanname kunnen corrigeren. Meepraten hoeft niet te betekenen dat iedereen iedere beslissing moet goedkeuren.

Neem een beperkt aantal concrete kandidaten. Gebruik per optie dezelfde vragen, zodat een aantrekkelijke presentatie niet meer gewicht krijgt dan een lastig zichtbaar probleem.

Vraag	Wat je voor de keuze wilt weten
Welk werk wordt beter?	Wie kan welke verantwoordelijkheid beter dragen?
Wat weten we al?	Welke voorbeelden of waarnemingen ondersteunen het verzoek?
Wat gebeurt er bij uitstel?	Welke hinder, afspraak of mogelijkheid blijft liggen?
Wat vraagt de verandering?	Welke bouw, voorbereiding, invoering en ondersteuning zijn nodig?
Waar zit onzekerheid?	Welke aanname kan de keuze nog veranderen?

Een fictief voorbeeld: een groothandel vergelijkt een nieuw verkoopdashboard met een verbetering in het afhandelen van onvolledige orders. Verkoop verwacht dat het dashboard helpt bij klantgesprekken. Medewerkers kunnen bij de tweede optie laten zien dat zij steeds dezelfde ontbrekende gegevens moeten opvragen. Dat maakt de tweede optie beter onderbouwd, maar nog niet automatisch belangrijker.

Misschien is juist een specifieke commerciële beslissing dringend. Laat verkoop dan uitleggen welk gesprek vastloopt en wat het nieuwe inzicht mogelijk maakt. Vergelijk die concrete uitkomst met de orderproblemen. Maak geen ranglijst waarin een onbewezen omzetverwachting ongemerkt als vaststaand voordeel wordt opgeteld.

Niet ieder verzoek is klaar om te bouwen. Soms is de verstandigste volgende stap een korte observatie, een proef met bestaande gegevens of een eenvoudig ontwerp dat medewerkers kunnen beoordelen. Kies die stap omdat zij een beslissende onzekerheid wegneemt, niet omdat onderzoek een standaardvoorfase moet zijn.

Bij de groothandel kun je bijvoorbeeld eerst nagaan waarom orders onvolledig binnenkomen. Ontbreekt een duidelijke klantvraag, is een afspraak onbekend of kan het huidige systeem de informatie niet goed vastleggen? Die oorzaken vragen andere ingrepen. Een verplicht veld kan de registratie vollediger laten lijken terwijl medewerkers er een willekeurige waarde invullen om verder te kunnen.

Leg vooraf vast wat je na het onderzoek wilt besluiten: bouwen, anders oplossen of voorlopig niet doen. Geef ook het onderzoek een grens in tijd en inzet. Een klein prototype hoeft geen belofte te worden dat de volledige functie er komt. Vertel dat aan deelnemers, zodat hun feedback over de bruikbaarheid gaat en niet over een vermeende opleverdatum.

Maak de gekozen aanpassing klein genoeg om te kunnen beoordelen, maar volledig genoeg om iemand werkelijk verder te helpen. Alleen een scherm toevoegen terwijl de benodigde bevoegdheid of opvolging ontbreekt, levert nog geen bruikbare werkwijze op. Neem het werk van de ontvangende collega mee in de afbakening.

Schrijf de beslissing kort op: dit probleem pakken we nu aan, dit resultaat willen we zien en deze alternatieven wachten. Benoem welke nieuwe informatie aanleiding kan zijn om opnieuw te kiezen. Een verzoek dat voorlopig niet doorgaat, heeft daarmee een begrijpelijke status in plaats van een onzichtbare plek onderaan een lijst.

Bespreek ook de gevolgen van een nieuw spoedverzoek. Welk lopend werk wordt daardoor later afgerond? Wie moet dat weten? Voorkom dat dezelfde capaciteit meerdere keren wordt toegezegd. Bij softwarestrategie verbinden we zulke keuzes aan de richting van de onderneming en aan wat bestaande toepassingen al kunnen ondersteunen.

Spreek vóór het bouwen af hoe je het resultaat beoordeelt. De GDS-richtlijn over succes bepalen combineert passende meetgegevens met gebruiksonderzoek. Voor jullie verbetering kan dat betekenen: bekijken of medewerkers een order zonder opnieuw navragen kunnen voorbereiden, én bespreken welke uitzonderingen nog extra hulp vragen.

Leg vooraf enkele herkenbare situaties vast om later mee te vergelijken. Kijk niet alleen naar snelheid, maar ook naar juistheid, extra werk elders en de ruimte om een klant goed te helpen. Gebruik de beoordeling om de toepassing en werkwijze te verbeteren, niet als ranglijst van individuele medewerkers.

Blijkt het resultaat tegen te vallen, onderzoek dan waarom voordat je de volgende functie toevoegt. Was het probleem verkeerd begrepen, ontbreekt ondersteuning of is de oplossing onhandig? Het artikel over software invoeren met medewerkers werkt die praktische invoering verder uit.

Een goede eerste stap is een keuzegesprek met enkele echte verzoeken, de betrokken medewerkers en je technische partner. Je hoeft nog geen complete ontwikkelplanning te hebben. Wel een uitlegbare keuze, een eigenaar en een moment waarop je samen beoordeelt of het werk werkelijk beter is geworden.