Vijf veelgemaakte fouten in low-code ontwikkeling

Een applicatie op maat van een behoefte die alleen jouw organisatie heeft? Daar durfden bedrijven vroeger niet eens aan te denken. Maatwerk nam een eeuwigheid in beslag en kostte een fortuin. Met de komst van low-code platforms staan de zaken er intussen weer helemaal anders voor. Low-code en no-code maken maatwerk snel en betaalbaar. Maar het betekent allerminst dat je zomaar blindelings een project in mag duiken. We staan stil bij vijf veelgemaakte fouten in low-code development.

Snelheid en flexibiliteit zijn voor low-code en no-code platforms de kernwoorden. Low-code en no-code laten toe om met applicaties snel in te spelen op de veranderende behoeften van je klant. Tegelijkertijd maken low-code en no-code het mogelijk om voluit voor maatwerk te kiezen. Een oplossing op maat biedt een oplossing voor een specifiek probleem of een concreet proces.

Low-code en no-code platforms

Het is mooi om te zien hoe low-code en no-code platforms de ontwikkeling van maatwerk haalbaar en betaalbaar maken. Maar betekent het dat jouw bedrijf vanaf nu alles op maat laat ontwikkelen? Natuurlijk niet. Een eenvoudig voorbeeld maakt duidelijk waarom. Klanten vragen ons wel eens of EsperantoXL voor hen via low-code of no-code een webshop kan bouwen. Natuurlijk kunnen we dat. Alleen is de vraag: waarom zou je dat als bedrijf willen? Er bestaan in de markt heel wat uitstekende pakketoplossingen voor een webshop. Die pakketten zijn bovendien ontwikkeld door vakspecialisten die in hun domein een ongeëvenaarde expertise hebben opgebouwd.

Zonder grondige analyse van het vraagstuk, kun je daarom niet de juiste keuze maken. Stel nu dat het bedrijf van daarnet bij nader inzien niet een complete webshop nodig heeft, maar een online bestelpagina waar zijn klanten op een eenvoudige manier verbruiksproducten of reserve-onderdelen kunnen bijbestellen. Nu bellen klanten met die vraag naar de servicedesk, waar ze de wachtrij langer maken voor klanten die een dringende interventie nodig hebben. Moet het bedrijf om die behoefte in te vullen een compleet webshoppakket implementeren? Natuurlijk niet. Dat zou een zwaar geval van overshooting zijn. Maar hier kan een low-code of no-code applicatie juist wél het verschil maken: een gericht antwoord op een specifieke vraag, niets meer, niets minder.

Vijf valkuilen

Heb je als bedrijf de juiste afweging gemaakt? Dan nog bestaat het risico dat je project niet helemaal volgens de verwachtingen verloopt. Juist hierin schuilt de toegevoegde waarde van een neutrale, leveranciers-onafhankelijke partner als EsperantoXL. Dit zijn vijf veel gemaakte fouten bij low-code development:

1. Onvoldoende voorbereiding

Software-ontwikkeling met een low-code of no-code platform verloopt snel, heel snel. Bij veel van onze klanten vraagt dat een aanpassing. Dat de zaken zo snel vooruitgaan, zijn ze niet gewend– of hadden ze niet verwacht.

Belangrijk is dat iedere medewerker van de onderneming aan boord is. Omdat de ontwikkeling zo snel verloopt, hebben wij – als ontwikkelaar – veel sneller informatie nodig dan de onderneming gewend is. Anticipeer daarop door goed in kaart te brengen welke informatie wanneer beschikbaar moet zijn. Lukt dat niet, dan valt de ontwikkeling stil, omdat ze moet wachten op een beslissing die nog niet is genomen.

2: De verkeerde keuze

Bedrijven laten zich nog te vaak verleiden door de vele voordelen van een low-code of no-code platform. Het is echter belangrijk om te begrijpen dat geen enkel low-code of no-code platform perfect is. De keuze voor een platform is altijd een afweging van voor- en nadelen. Praat daarom niet alleen met de leveranciers zelf, maar laat je begeleiden door een ervaren, maar onafhankelijke specialist. Die plaatst de voors en tegens van de diverse platformen in perspectief.

Eenvoudig gesteld kun je de keuze tussen low-code en no-code als de afweging tussen performance en gebruiksgemak beschouwen. Bij een no-code platform gebeurt alles in de cloud. Dat zorgt voor een hoog niveau van gebruiksgemak, maar beperkt vroeg of laat de performance. Gaat het om een applicatie die het bij uitstek van haar performance moet hebben, dan gaat de voorkeur naar low-code.

3: Iedereen is citizen developer

Geloof ons: niet iedere medewerker is zomaar geschikt als citizen developer. In de eerste plaats heb je een medewerker nodig die de business perfect begrijpt – en die dus ook weet wat de uitdaging is en op welke manier de applicatie er een oplossing voor zal vormen. Onderschatting is in deze context de belangrijkste fout. De rol van citizen developer is niet iets dat je er zomaar, on the side, even bijneemt. De rol van citizen developer vraagt een fulltime focus, aangezien je in die rol de strategische keuzes van de onderneming maakt.

Dat is uiteraard een andere rol dan die van het operationele beheer van een low-code of no-code applicatie. Dat is een takenpakket dat makkelijker een plaats krijgt binnen de bestaande job van een medewerker.

4: Te weinig aandacht voor de adoptie van de app

Stel: de applicatie is klaar, maar uiteindelijk blijken de medewerkers haar niet of nauwelijks te gebruiken. Dat is zonde, want op dat moment slaag je er als bedrijf niet in om het potentieel van de applicatie optimaal te benutten. Hierop kan je anticiperen door alle medewerkers zo vroeg mogelijk bij de ontwikkeling te betrekken.

Bij EsperantoXL lossen we dat op door na iedere sprint – dus telkens na één of twee weken – een demo in te plannen. Zo laten we regelmatig zien hoe ver we zijn en de vorderingen gaan. Dat laat toe om heel vroeg in het traject feedback mee te nemen. Zo blijft de hele organisatie betrokken bij het proces en ziet ze direct hoe we de gegeven feedback in het project verwerken.

5: Het duurt nog altijd te lang

Low-code en no-code zijn met hun agile aanpak dan wel op snelheid gericht, stiekem houdt de IT-afdeling van een onderneming nog te vaak vast aan de principes van de watervalmethode. Zo haalt ze de snelheid van een traject onnodig omlaag. Vanuit EsperantoXL helpen we de product owner op dat moment om snel veel, kleine incrementele stappen te zetten en zo zijn low-code development toch van de nodige drive te voorzien.