HomeKwaliteit in software ❱ Vijf sleutelfactoren voor succesvolle software ontwikkeling (deel 2): Ontwerp niet teveel

Vijf sleutelfactoren voor succesvolle software ontwikkeling (deel 2): Ontwerp niet teveel

Dit is deel 2 in de reeks Vijf sleutelfactoren voor succesvolle software ontwikkeling.

2: Ontwerp niet teveel

Er zijn al ontzettend veel software projecten mislukt doordat de opdrachtgever én de opdrachtnemer zich committeerden aan een vuistdik ontwerp.

En aan de belofte dat het daarin beschreven systeem na een maandenlange bouwfase (zonder of met sporadisch tussentijds contact) zou worden opgeleverd.

Deze werkwijze is beroemd gemaakt door grote ICT-bedrijven en overheidsprojecten.

Het is best verleidelijk om je te laten meevoeren door een leverancier die met zo'n vuistdik ontwerp op de proppen komt.

Of die voorstelt om eerst een paar weken goedbetaald te gaan ontwerpen.

Een veel te ingewikkeld software interface ontwerp

Maar wat blijkt: in de praktijk werkt het juist averechts om een systeem van tevoren helemaal uit te denken en op papier te zetten.

Hoe omvangrijker en completer het ontwerp namelijk is, des te langer het duurt totdat jouw gebruikers iets in handen hebben.

En dat blijkt heel belangrijk voor de kwaliteit van de software én de kosten die je gaat maken.

Er zijn namelijk twee simpele waarheden bij het ontwerpen van software, die hierop direct betrekking hebben:

  • Het is onmogelijk om een systeem perfect te ontwerpen. Bij elk systeem constateren de gebruikers functionele fouten, ontbrekende functies of een werkelijkheid die afwijkt van papier.
  • Hoe langer de bouwfase duurt, des te meer zal de opgeleverde software achterlopen op de werkelijkheid. Dit levert "re-work" dat voorkomen had kunnen worden.

Natuurlijk is een goede overview nodig van het beoogde systeem. En een technisch ontwerp, waarin de (verborgen) specificaties staan beschreven.

Maar het functionele ontwerp kan het beste worden opgedeeld in kleine featuresets, om daarna zo snel mogelijk de eerste featureset te bouwen en in gebruik te nemen.

Spreek met je leverancier een korte eerste bouwfase af en houd elkaar daaraan. Neem bijvoorbeeld 4 weken: na een maand bouwen neem je de eerste versie in gebruik.

Het ligt voor de hand dat je dan start met een applicatie met hoogstens basale, primaire functionaliteit.

Maar dat is prima, uitstekend zelfs! Je wordt nu namelijk gedwongen om vast te stellen wat écht de belangrijkste functies van het systeem zijn.

De eerste versie is functioneel genoeg om in jouw bedrijf te integreren, en inhoudelijk zodanig dat het input en/of output levert voor de volgende functies.

Na oplevering neem je deze applicatie meteen in gebruik en stel je met gebruikers vast wat de belangrijkste volgende verbetering moet zijn. 

Je spreekt een cyclus af waarin je nieuwe features in gebruik neemt, bijvoorbeeld elke week of twee weken.

Gefeliciteerd: nu beschik je over een software systeem dat flexibel meebeweegt met de veranderlijkheid van jouw bedrijf en feedback van gebruikers.

Bovendien heb je het risico om werk opnieuw te moeten doen of functies helemaal weg te gooien, enorm verkleind.

Maar één van de belangrijkste resultaten van deze aanpak zul je functioneel niet meteen merken. In het volgende artikel vertellen we wat dat is.

Over deze reeks

We beschrijven de vijf sleutelfactoren voor succesvolle software ontwikkeling in een reeks artikelen, één sleutelfactor per artikel.

Je kunt ook onze gratis whitepaper downloaden waarin alle 5 de sleutelfactoren behandeld worden.


Gerelateerde berichten

Bezoekadres: Kanaalweg 18-G 3526KL Utrecht (Smart Business Park)

Wat kost maatwerk software?

Kwaliteit in software

Met ons werken?

Algemene Voorwaarden

Onze klanten geven VAART software een 4.5/5 (4 beoordelingen)