Een webapp laten bouwen is voor de meeste organisaties geen dagelijks werk. Je beslist over software die je zelf niet maakt, voor collega’s die er straks wel elke dag mee werken. De projecten die misgaan, stranden zelden op techniek. Ze stranden op keuzes die te laat of helemaal niet gemaakt zijn.
We ontwikkelen webapplicaties vanuit Amsterdam. Uit die trajecten komt een vast rijtje aandachtspunten. Geen geheimen, wel zaken die in de drukte van een project makkelijk ondersneeuwen.
Begin bij het vraagstuk, niet bij het wensenlijstje
“We willen een webapp” is een wens, geen briefing. De bruikbare vraag is welk vraagstuk de applicatie moet oplossen: welk proces loopt vast, waar verliezen mensen tijd, welke informatie is nooit op orde. Zet dat op papier en breng er volgorde in. Functionaliteiten die geen van die kernpunten raken, kunnen naar de reservebank.
Betrek de mensen die er straks mee werken er vroeg bij. Een uur meekijken met een planner of een binnendienstmedewerker levert meer op dan een vergaderuur over functionaliteiten: je ziet waar het werk wringt en welke stappen een applicatie kan overnemen.
Houd je begroting eerlijk
Wat een webapp kost, hangt af van de omvang, de koppelingen met andere systemen en de eisen aan beveiliging en gebruikersaantallen. Wat vrijwel elk traject gemeen heeft: er komt iets tussendoor dat niemand had voorzien. Reserveer daar vooraf ruimte voor, in budget en in planning. En tel je eigen uren mee, want feedback geven, testen en collega’s meenemen kost tijd van mensen die het al druk hebben.
Kies een partner die doorvraagt
Eerder werk zegt iets: bekijk cases en let op projecten die op jouw situatie lijken. Het eerste gesprek zegt meer. Een goede partner begint over je proces en je doelen, niet over zijn eigen technologie, en vertaalt elke technische keuze naar wat die jou oplevert.
Vraag in dat gesprek in elk geval:
- hoe je tussentijds ziet wat af is en wat nog niet;
- hoe wijzigingen tijdens het traject worden besproken en geprijsd;
- van wie de broncode is en wie de applicatie later kan onderhouden.
In de kennisbank werkten we eerder uit welke vragen je stelt voordat je software op maat laat ontwikkelen.
Gebruiksgemak verslaat de langste functielijst
Een applicatie die snel reageert en logisch in elkaar zit, wordt gebruikt. Een applicatie vol mogelijkheden die traag of onoverzichtelijk is, wordt omzeild, en levert dus niets op. Begin met de taken die dagelijks terugkomen en maak die vlekkeloos. De rest kan in een volgende ronde, gestuurd door wat gebruikers na de livegang nodig blijken te hebben.
Test vóór die livegang met echte gebruikers in realistische scenario’s, niet alleen met het projectteam. Wie het systeem heeft helpen bedenken, kijkt er te vertrouwd naar om de struikelblokken nog te zien.
Na de livegang begint het pas
Een webapp is nooit af. Browsers veranderen, beveiligingseisen schuiven op en je organisatie staat zelf ook niet stil. Maak daarom vooraf afspraken over onderhoud en doorontwikkeling: wie monitort, wie lost verstoringen op, hoe worden nieuwe wensen opgepakt en wat kost dat per jaar. Structureel klein onderhoud is vrijwel altijd goedkoper dan een grote reparatie achteraf.
Leg deze punten naast je eigen plan voordat je met bureaus om tafel gaat; dat gesprek wordt er meteen scherper van. Wil je zien hoe zo’n traject er bij ons uitziet, van eerste schets tot beheer, kijk dan bij webapplicaties en portalen.