HomeBlog ❱ Waarom weinig ontwerpen heel slim is

Waarom weinig ontwerpen heel slim is

Software die je vooraf niet volledig uitdenkt, is uiteindelijk vaak succesvoller én goedkoper. Hoe komt dat, en hoe overwin je die -logische- drang om alles te willen denken?

Jorrit Venema door Jorrit - leestijd 2 minuten

software ontwerp

Al ontzettend veel software ontwikkeling projecten zijn mislukt doordat opdrachtgever en opdrachtnemer zich samen committeerden aan een vuistdik ontwerp - en aan de belofte dat het daarin beschreven systeem na een maandenlange bouwfase zou worden opgeleverd.

Deze werkwijze is beroemd geworden dankzij de grote ICT-bedrijven en overheidsprojecten. Maar ook op kleinere schaal is het verleidelijk je te laten meevoeren door je eigen enthousiasme en een leverancier die een vuistdik glimmend ontwerp schrijft.

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

Hoe omvangrijker je ontwerp is, des te langer het duurt totdat je gebruikers (of jij) iets in handen hebben.

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

Er zijn twee simpele regels voor het ontwerpen van software, die dit veroorzaken:

  • 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.

Is het ontwerp daardoor minder belangrijk? Zeker niet: een ontwerp is onmisbaar voor succes. De juiste vorm en doelstelling van het ontwerp, daar gaat het om.

Natuurlijk heb je een goede roadmap nodig van het totale systeem dat je voor ogen hebt; de "stip op de horizon". Maar alles vooraf uittekenen, dát is heel wat anders - en precies wat je moet voorkomen.

Je ontwerp moet spreken over doelstellingen, voor het bedrijf en de gebruikers. De details moeten voortschrijdend worden ingevuld.

Hoe dan wel?

Moeite om je ontwerp klein en 'voortschrijdend' te houden? De volgende praktische richtlijnen helpen daarbij:

  • Maak in het ontwerp gebruikersdoelstellingen leidend voor elke feature (gebruik de User Story vorm).
  • Neem voor elke versie/feature een korte bouwfase af (1-3 weken) en maak die heilig.
  • Ontwerp niets dat niet meteen gebouwd gaat worden.
  • Bouw niets dat niet meteen gereleased gaat worden.

De korte bouwperiode, van 1 tot 3 weken, geldt ook voor de éérste versie.

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 namelijk gedwongen om te bepalen wat de belangrijkste doelen van je software zijn. De eerste versie is functioneel genoeg om in je bedrijf te integreren en levert onmisbare feedback en kennis voor de volgende versies. Na elke release bepaal je wat de belangrijkste volgende verbetering moet zijn.

Gefeliciteerd: je hebt nu een software systeem in het leven geroepen dat flexibel kan meebewegen met de werkelijkheid van je business en feedback van je gebruikers. Bovendien heb je het risico om werk opnieuw te moeten doen of functies helemaal weg te gooien, enorm verkleind.

Maar opgelet...

Je volgt nu een wendbare ontwikkelmethode, maar je software komt het beste uit de verf als je ook zorgt voor een wendbare architectuur. En nee, deze twee zijn niet hetzelfde. Meer hierover lees je in De grootste valkuil van maatwerk software.

Ga jij aan de slag met een klein en voortschrijdend ontwerp? Deel je bevindingen of vragen in de reacties hieronder, ik reageer altijd.

Reacties