In mijn vorige blog vertelde ik over het mislukken van softwareprojecten. Gemiddeld worden slecht 16,2% van de softwareprojecten op tijd en binnen budget voltooid. Ook kwam er naar voren wat de redenen zijn van het mislukken van ICT-projecten:
- Gebrek aan gebruikersinput;
- Onvolledige vereisten en specificaties;
- Wijzigende vereisten en specificaties;
- Onbekwaamheid in technologie.
In deze blog zal ik toelichten hoe Appstorming zich verhoudt tot deze knelpunten.
Gebrek aan gebruikersinput – Bij Appstorming is er sprake van een hoge gebruikersinput. Tijdens het in kaart brengen van het proces tijdens de Exploratory Appstorm is het belangrijk dat alle stakeholders aanwezig zijn. Door het betrekken van alle stakeholders tijdens het beschrijven van het proces worden alle wensen en eisen meegenomen. Daarnaast is de Exploratory Appstorm een laagdrempelige methode om het proces in kaart te brengen. Er is voorafgaand geen cursus nodig en IT-jargon wordt vermeden. Dit zorgt ervoor dat de klant begrijpt wat er gebeurt. Ook krijgt de klant meer grip op zijn eigen proces. Door dit begrip kan de klant ook meer input geven over het proces, de wensen en de eisen.
Onvolledige vereisten en specificaties – Zoals eerder genoemd, is het belangrijk dat er zo veel mogelijk stakeholders aanwezig zijn tijdens het in kaart brengen van de requirements. Dit is belangrijk omdat dit ervoor zorgt dat het hele proces, met alle processtappen, aan bod komen. Door het bespreken van het hele proces komen er ook knelpunten aan de orde. Daardoor is er ook oog voor procesoptimalisatie. Door te werken met verschillende kleuren Post-its wordt inzicht verkregen in wat er allemaal nodig is bij het uitvoeren van een processtap. Zo kan er met de verschillende kleuren aangegeven worden of er gebruikt gemaakt wordt van het versturen van een e-mail en welke documenten er nodig zijn bij het uitvoeren van het proces en wie de stap uitvoert. Dit geeft een volledig beeld.
Wijzigende vereisten en specificaties – Door het bijeenbrengen van alle stakeholders kan er een volledig beeld geschetst worden van het gewenste proces. Door het proces meteen volledig in kaart te brengen wordt ervoor gezorgd dat er later in het proces weinig tot geen wijzigingen doorgevoerd hoeven te worden. Appergine voert de Appstorm direct uit in haar low-code tool. Een groot voordeel van low-code ontwikkeling is de mogelijkheid van snelle oplevering van nieuwe applicaties. Een low-code tool biedt de mogelijkheid om software tien keer sneller te ontwikkelen dan originele ontwikkelmethoden. Omdat de ontwikkeling van de applicatie zo snel gaat, is de kans kleiner dat de vereisten veranderen gedurende het project.
Onbekwaamheid in technologie – Appergine maakt gebruik van haar eigen low-code tool, Appergine Studio. Er zijn al meerdere low-code tools op de markt. Toch heeft Appergine ervoor gekozen om de tool zelf te gaan ontwikkelen. Appergine is ervan overtuigd dat dit sneller is en heeft hierdoor zelf alles onder controle. Zo kan er snel geschakeld worden wanneer een bug zich voordoet. Echter is de tool nog steeds in ontwikkeling. Er worden regelmatig verbeteringen en nieuwe features toegevoegd. Hierdoor ontstaan er soms bugs, waardoor het ontwikkelproces tijdelijk stil komt te liggen. Daarnaast zijn de user interfaces in Appergine Studio nog beperkter dan bij andere low-code tools. Dit beperkt de applicatie.
Hieruit kan opgemaakt worden dat Appstorming de knelpunten op het gebied van gebrek aan gebruikersinput, onvolledige vereisten en specificaties en wijzigende vereisten en specificaties verbeterd. Op het gebied van onbekwaamheid in technologie is er nog ruimte voor verbetering. In mijn volgende blog zal ik toelichten hoe de Scrum- en watervalmethode zich verhouden tot deze knelpunten.