Het webontwikkelproces uitgelegd
Elke webontwikkelmethodiek ordent dezelfde fasen anders. De fasen zelf begrijpen — wat elk oplevert en wat ze sluit — is nuttiger dan de naam van de methodiek, want het vertelt je of het project staat waar het zou moeten staan.
Deze gids behandelt de zeven fasen, gebruikelijke doorlooptijden voor een middelgrote site, en hoe een echte goedkeuring er per fase uitziet.
De zeven fasen#
De doorlooptijden gaan uit van een middelgrote maatwerksite met een klein team. Ze rekken veel meer op met contentvolume en koppelingen dan met het aantal pagina's.
| Fase | Levert op | Typische duur |
|---|---|---|
| 1. Verkenning | Doelen, publiek, scope, randvoorwaarden | 1–2 weken |
| 2. Structuur | Paginastructuur, contentmodel, wireframes | 1–2 weken |
| 3. Ontwerp | Sjablonen, componentsysteem, responsieve regels | 2–4 weken |
| 4. Bouw | Werkende sjablonen, CMS, koppelingen | 4–10 weken |
| 5. Content | Echte teksten, beelden en gegevens in het systeem | Loopt parallel — vaak de langste |
| 6. Testen | Functioneel, over browsers, snelheid, toegankelijkheid | 1–2 weken |
| 7. Lancering | Live site, omleidingen, monitoring, overdracht | 2–5 dagen |
Fase 5 is degene die uitloopt. Ze is parallel getekend omdat ze in fase 2 zou moeten beginnen, niet omdat ze klein is.
Wat elke fase sluit#
Een fase is niet af omdat er tijd is verstreken. Ze is af wanneer iets specifieks schriftelijk is afgesproken door iemand met bevoegdheid. Zonder dat gaat het werk door op een fundament dat nog kan schuiven.
- Verkenning: een ondertekende scope met een expliciete lijst buiten scope.
- Structuur: een goedgekeurde paginastructuur en contentmodel, met veldnamen die je team begrijpt.
- Ontwerp: goedgekeurde sjablonen voor elke afzonderlijke opmaak, inclusief mobiel en lege toestanden.
- Bouw: elk sjabloon getoond op de testomgeving met realistische content.
- Content: elke lanceringkritieke pagina gevuld en nagelezen door een bij naam genoemde persoon.
- Testen: een afgesproken lijst met issues, gesplitst in lanceringblokkers en correcties na lancering.
- Lancering: een afgeronde checklist vóór lancering en een bevestigde overdracht van toegangen.
Waterval, agile, of iets ertussenin#
Het werkelijke verschil is wanneer de scope wordt vastgezet. Projecten met vaste scope laten zich nauwkeurig beprijzen en gaan slecht om met verandering; iteratieve projecten gaan goed om met verandering en kunnen geen vast totaalbedrag beloven. Het meeste webwerk zit ertussenin: vaste scope tot de lancering, iteratief daarna.
| Vaste scope | Iteratief | |
|---|---|---|
| Prijs | Vooraf bekend | Tarief per sprint of per maand |
| Wijziging | Formeel wijzigingsverzoek, opnieuw beprijsd | Opgevangen door de backlog te herprioriteren |
| Past bij | Heldere, stabiele eisen | Producten in ontwikkeling en onduidelijke eisen |
| Jouw risico | Betalen voor iets dat niet meer past | Kosten die zonder harde stop oplopen |
| Vraagt van jou | Beslissingen vooraf | Doorlopende beschikbaarheid om te prioriteren |
Pas op voor een vaste prijs bij een vage scope. Dat is de slechtste combinatie: de ontwikkelaar beschermt de marge door dubbelzinnigheid eng uit te leggen, en elke verduidelijking wordt een onderhandeling.
Waar het proces meestal misgaat#
Dezelfde vier fouten verklaren de meeste uitloop, en geen ervan is technisch.
- Ontwerp goedgekeurd op opvulcontent. De echte tekst komt twee keer zo lang en de opmaak wordt herbouwd.
- Koppelingen laat ontdekt. «Het moet ook met ons voorraadsysteem praten» in week acht is een nieuw project, geen wijziging.
- Geen enkele beslisser. Feedback komt van vijf mensen, twee spreken elkaar tegen, en niemand heeft de bevoegdheid het te beslechten.
- Testen als fase behandeld in plaats van als gewoonte. Fouten die in week tien worden gevonden maar in week drie zijn ontstaan kosten een veelvoud om te herstellen.
Veelgestelde vragen
Hoelang duurt een typische website?
Een kleine sjabloonsite is twee tot vier weken. Een middelgrote maatwerksite duurt doorgaans drie tot vijf maanden van begin tot eind. Webshops en applicaties duren langer. De variabele die dit het sterkst beweegt is niet de complexiteit van de code maar de beschikbaarheid van content en de beslissnelheid aan de klantzijde.
Mogen fasen overlappen?
Sommige zouden dat moeten. Content hoort tijdens de structuurfase te beginnen, en testen hoort de hele bouw te begeleiden in plaats van alleen aan het eind te staan. Wat niet mag overlappen is ontwerp en bouw van hetzelfde sjabloon: bouwen tegen een ontwerp dat nog beweegt garandeert overwerk, en het is de meest voorkomende bron van «dat hadden we al gebouwd»-discussies.
En als we halverwege iets moeten wijzigen?
Reken erop, en spreek het mechanisme vooraf af: wie een wijziging mag aanvragen, wie hem beprijst, en of hij de lanceerdatum verschuift. Kleine wijzigingen die stilzwijgend worden opgevangen zijn hoe een project een maand verschuift zonder dat iemand kan zeggen wanneer. Een schriftelijk wijzigingslogboek lost het meeste hiervan op.
Moet ik per fase betalen?
Mijlpaalbetalingen gekoppeld aan opleveringen die je kunt inspecteren zijn voor beide partijen de eerlijkste opzet — doorgaans een aanbetaling, daarna betalingen bij ontwerpgoedkeuring, afronding van de bouw en lancering. Vermijd alles vooraf betalen, en vermijd alles bij oplevering betalen, wat het hele liquiditeitsrisico bij de ontwikkelaar legt en jou meestal duurder uitkomt.
webontwikkelprocesfasen webontwikkelingstappen webprojectagile webontwikkelingplanning websitemethodiek webontwikkeling
