Een webapplicatie die mislukt, gaat zelden onderuit op de code. Wanneer we gevraagd worden een vastgelopen project vlot te trekken, zien we steeds dezelfde oorzaken terug. Ze ontstaan in de gesprekken vóór de bouw en in de stilte na de livegang, en juist daarom zijn ze te voorkomen.
Deze vijf komen we sinds 2001 in wisselende gedaanten tegen. Herken je er een in je eigen project, dan is dat geen reden voor paniek, wel voor een gesprek deze week in plaats van volgend kwartaal.
Niemand heeft het vraagstuk scherp gemaakt
“We hebben een portaal nodig” is geen vraagstuk maar een conclusie. Wat moet er beter, voor wie, en waaraan zie je dat het gelukt is? Blijven die vragen onbeantwoord, dan bouwt elke betrokkene in gedachten een andere applicatie. Dat merk je pas bij de oplevering, wanneer iedereen iets anders verwachtte en de scope ondertussen drie keer is opgerekt.
De remedie kost geen regel code: leg vóór de bouw vast welk werkproces de applicatie verandert en welke functies daarvoor onmisbaar zijn. Al het andere is versie twee.
De techniek is gekozen op indruk, niet op het werk
Het nieuwste framework voelt als een veilige keuze, want modern. Maar technologie die je team niet beheerst, is een risico dat je elke week opnieuw betaalt. De juiste vraag is niet wat er trending is, maar wat het werk vraagt: hoeveel gebruikers, welke koppelingen met bestaande systemen, wie dit over vijf jaar onderhoudt. Bewezen technologie die bij het vraagstuk past, wint het vrijwel altijd van de nieuwste tool met kinderziektes.
Gebruikers zien de applicatie pas bij de livegang
Dit is het patroon dat het meeste geld kost. De demo voor het management verloopt vlekkeloos, de stuurgroep is tevreden, en de mensen die er dagelijks mee moeten werken openen de applicatie voor het eerst op de dag van de livegang. Binnen een maand staan de oude Excel-lijsten weer open.
Betrek eindgebruikers daarom vanaf het eerste ontwerp. Laat ze klikken door een prototype voordat er code staat en kijk mee over hun schouder terwijl ze hun dagelijkse werk doen. Elke aanname die je zo onderschept, is een herbouwronde die je niet hoeft te betalen.
De planning rekent op de beste dag
Onrealistische deadlines leiden tot gehaast werk, gehaast werk tot fouten, en fouten tot een team dat achter de feiten aan repareert terwijl het vertrouwen wegsijpelt. Complexiteit onderschatten is menselijk; er geen ruimte voor inbouwen is een keuze.
Deel het werk daarom op in kleine stappen die elk iets werkends opleveren, zodat je bijstuurt op wat er staat in plaats van op een voortgangsrapportage. En wees vooraf eerlijk over hoe lang het duurt om een webapplicatie te laten ontwikkelen: dat hangt sterk af van hoe snel beslissingen genomen worden, niet alleen van de bouw.
Na de livegang valt de aandacht stil
Een livegang voelt als een finish, maar voor de applicatie begint het werk dan pas. Browsers veranderen, beveiligingslekken worden ontdekt, gekoppelde systemen krijgen nieuwe versies en gebruikers krijgen nieuwe wensen. Een applicatie waar niemand meer naar omkijkt, wordt eerst traag, dan kwetsbaar, en uiteindelijk het systeem waar iedereen omheen werkt.
Regel daarom bij de start het eigenaarschap voor daarna: wie monitort, wie voert beveiligingsupdates uit en uit welk budget wordt dat betaald. Onderhoud is geen kostenpost die je zo lang mogelijk uitstelt, maar de reden dat de investering blijft renderen.
Staat er bij jou zo’n applicatie stil, of wil je voorkomen dat je nieuwe project in dit rijtje belandt? Bij doorontwikkeling en beheer nemen we ook applicaties onder onze hoede die anderen ontwikkelden. Het eerste gesprek gaat dan niet over techniek, maar over waar het knelt.