Handen houden een tablet vast met stroomschema's en beslisbomen op het scherm, omringd door getekende vraagtekens

Deze vragen stel je voordat je software op maat laat ontwikkelen

De belangrijkste keuzes in een maatwerktraject vallen voordat er een regel code staat. Ze zitten in de vragen die vooraf wel of niet op tafel komen: wat moet dit opleveren, wie gaat ermee werken, wat gebeurt er na de oplevering. We voeren sinds 2001 intakegesprekken over software op maat, en de trajecten die goed aflopen hebben één ding gemeen: de lastige vragen kwamen aan het begin, niet halverwege.

Daarom hieronder geen algemeen projectmanagementadvies, maar de vragen zoals ze bij ons aan tafel klinken. Eerst de vragen die wij aan jou zouden stellen, daarna de vragen die jij aan elke ontwikkelpartner mag stellen.

Het doel gaat voor de functionaliteit

De meeste aanvragen die we krijgen zijn al een oplossing: een portaal met inlog, een koppeling tussen twee pakketten, een dashboard voor het management. Begrijpelijk, maar de eerste intakevraag negeert die lijst bewust. Wat moet er in je organisatie makkelijker worden? Welk werk blijft liggen, waar ontstaan fouten, welke beslissing duurt te lang omdat de informatie ontbreekt?

Het antwoord bepaalt wat er ontwikkeld moet worden, en soms is dat minder dan gevraagd. Een deel van de wensenlijst blijkt in bestaande software te passen, of vervalt zodra het onderliggende proces is versimpeld. Twijfel je of maatwerk voor je situatie de juiste route is, lees dan eerst hoe maatwerk zich verhoudt tot standaardsoftware.

De vragen die wij bij een intake stellen

Elke organisatie is anders, maar deze vragen komen in vrijwel elk eerste gesprek terug:

  • Welk proces kost je mensen nu de meeste tijd, en hoe verloopt het vandaag, stap voor stap?
  • Wie gaat er straks dagelijks mee werken, en wie bepaalt of het geslaagd is?
  • Met welke systemen moet de software gegevens uitwisselen, en wie beheert die systemen?
  • Wat gebeurt er als je een jaar lang niets verandert?
  • Wie onderhoudt de software na de oplevering: je eigen team of je ontwikkelpartner?

De antwoorden sturen keuzes die later moeilijk terug te draaien zijn. Het aantal koppelingen zegt meer over de complexiteit dan het aantal schermen. De minst technische gebruiker bepaalt hoe eenvoudig de interface moet zijn. En de vraag wat er gebeurt als je niets verandert, maakt zichtbaar wat het vraagstuk je nu al kost.

Wat je aan een ontwikkelpartner terugvraagt

Een goede intake werkt twee kanten op. Met een paar vragen ontdek je of je met een partner of met een leverancier aan tafel zit. Van wie is de broncode na oplevering? Wat kost onderhoud per jaar, en wat krijg je daarvoor? Hoe snel staat er een eerste werkende versie, en wat kun je daar al mee? Vooral die eerste vraag wordt te weinig gesteld; hoe je daarmee vendor lock-in voorkomt is een artikel op zich.

Let ook op wat er niet gevraagd wordt. Een partij die na het aanhoren van je wensenlijst meteen begint te rekenen, heeft de belangrijkste stap overgeslagen: begrijpen waarom je die wensen hebt.

Niet alles hoeft vooraf vast te staan

Een dichtgetimmerd bestek van veertig pagina’s is geen voorwaarde voor een goed traject. Het is eerder een risico, omdat het beslissingen vastlegt op het moment dat iedereen het minste weet. Wat wel scherp moet zijn voordat er iemand gaat programmeren: het doel, de gebruikers en de systemen eromheen. De rest krijgt vorm tijdens het traject, met een eerste werkende versie als toets in plaats van een document.

Wil je weten waar die eerste versie bij jou zou beginnen? Op onze pagina over maatwerkapplicaties lees je hoe we van vraagstuk naar werkende software komen. Neem je antwoorden op de vragen hierboven mee, dan begint het gesprek niet bij software, maar waar het hoort te beginnen: bij hoe je organisatie werkt.

Praat met ons

Elke goede oplossing begint met een gesprek.

Vraag over iets wat je hier las? Neem contact op - we denken graag met je mee.