Software die je vooraf niet volledig uitdenkt, is uiteindelijk vaak succesvoller én goedkoper. Hoe komt dit? En hoe overwin je de drang om alles te willen uitdenken?
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 maakt.
Maar wat blijkt: in de praktijk werkt het averechts om een systeem van tevoren helemaal uit te denken en op papier te zetten.
Hoe omvangrijker het ontwerp, des te langer het duurt totdat jij of jouw gebruikers iets in handen hebben.
En dat blijkt heel belangrijk voor de kwaliteit van je software en de te verwachten kosten.
Er gelden namelijk twee simpele regels bij het ontwerpen van software:
- 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 de uiteindelijke oplevering zal afwijken van de werkelijke wensen in de praktijk. 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 beoogde systeem; de “stip op de horizon”. Maar alles vooraf uittekenen, dát is heel wat anders – en precies wat je moet wil voorkomen.
Hoe dan wel?
Neem in ieder geval het volgende in acht:
- Het ontwerp beschrijft de doelstellingen voor bedrijf en gebruikers.
- De functionele details worden voortschrijdend door het team ingevuld.
Ondervind je toch nog moeite om het ontwerp klein en ‘voortschrijdend’ te houden?
De volgende praktische richtlijnen helpen je hiermee:
- Maak in het ontwerp gebruikersdoelstellingen leidend voor elke feature (gebruik de User Story vorm).
- Neem voor elke versie/feature een korte bouwfase (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 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 de software zijn.
De eerste versie is functioneel genoeg om in uw organisatie 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 bouwt nu aan een software systeem dat effectief meebeweegt met de werkelijke wensen vanuit de business en je gebruikers.
En je hebt het risico om werk opnieuw te moeten doen of functies helemaal weg te gooien, gigantisch verkleind.