Achter de vraag hoe lang het ontwikkelen van een webapplicatie duurt, zit vrijwel altijd een datum. Een licentie die afloopt, een seizoenspiek die het huidige systeem niet meer aankan, budget dat dit jaar nog besteed moet worden. Het korte antwoord: een afgebakend portaal staat doorgaans binnen enkele maanden in productie, een platform met meerdere gebruikersrollen en koppelingen vraagt eerder een half jaar of meer.
Alleen kun je met zo’n bandbreedte niet plannen. Daarvoor moet je weten hoe het traject is opgebouwd. Daarom hieronder de fases zoals wij ze bij onze eigen projecten doorlopen: wat er in elke stap gebeurt, waar de tijd in gaat zitten en welk moment voor je planning telt.
Scherpstellen voordat er iets gebouwd wordt
De eerste fase is een verkenning van vier weken. Die begint niet met code, maar met de vragen die de rest van het traject bepalen:
- welk proces de applicatie gaat dragen, inclusief de uitzonderingen daarin
- wie ermee werken en welke rechten elke groep gebruikers nodig heeft
- met welke systemen de applicatie gegevens moet uitwisselen
- wat nadrukkelijk buiten de eerste versie blijft
Die laatste vraag weegt voor je doorlooptijd het zwaarst. Elke functie die naar een latere versie kan, verkort de weg naar de livegang. Hoe je die grens verstandig trekt, lees je in ons artikel over het verschil tussen een MVP, een bewust beperkte eerste versie, en volledig uitgewerkte software.
Een klikbaar prototype voordat de bouw begint
De verkenning eindigt niet met een rapport, maar met een klikbaar prototype: nog voordat de bouw begint, klik je door de belangrijkste schermen en herken je je eigen werkwijze erin.
Dat vroege moment is geen formaliteit. Pas wanneer mensen door zo’n prototype klikken, blijkt wat er in de gesprekken ongezegd bleef: de uitzondering die niemand noemde, de stap die in de praktijk anders loopt dan op papier. Hoe eerder dat boven tafel komt, hoe kleiner de correctie.
Bouwrondes waarin je kunt bijsturen
Daarna groeit de applicatie in rondes van vier weken, elk met een werkende versie. Je kijkt tussentijds mee, geeft feedback en bepaalt mee wat de volgende ronde oplevert. Testen gebeurt binnen elke ronde, niet als sluitstuk vlak voor de livegang.
In deze fase ontstaan de meeste vertragingen, en zelden door het programmeerwerk zelf. Koppelingen met externe systemen brengen wachttijd mee: documentatie opvragen, toegang geregeld krijgen, reacties afwachten. En zodra de eerste versie draait, dienen nieuwe ideeën zich aan. Die zijn welkom, maar horen op de lijst voor een volgende versie. Een project dat tijdens de bouw blijft groeien, komt zelden op tijd aan.
Rond de livegang zit meer tijd dan je verwacht
De livegang zelf is bij een goed voorbereid traject een kwestie van uren. De weken eromheen zijn dat niet. Bestaande gegevens moeten worden overgezet en gecontroleerd, collega’s moeten met de nieuwe applicatie leren werken en vaak draait het oude systeem nog een periode mee als vangnet. Reken voor dit geheel op enkele weken, en plan de overstap niet in je drukste maand.
Daarna staat de teller overigens niet stil. De eerste weken in productie leren je meer over je applicatie dan welke testronde daarvoor ook. Reserveer dus ruimte voor aanscherpingen kort na de start, in plaats van het budget tot de laatste dag aan de bouw te besteden.
Wil je weten of jouw datum haalbaar is? Reken terug: enkele weken voor invoering en livegang, daarvoor bouwrondes waarvan het aantal afhangt van je wensenlijst, en aan het begin een verkenning van vier weken. Of leg je vraagstuk aan ons voor; op basis van je proces en je systemen krijg je een planning die je aan deze fases kunt toetsen. Bekijk hoe we webapplicaties en portalen ontwikkelen.