Hoe werkt webontwikkeling? Het volledige proces
Van buitenaf kan webontwikkeling ogen als een lange stilte gevolgd door een afgeronde site. In de praktijk is het een reeks omgevingen, controlemomenten en beslissingen, en de klantzijde heeft bij vrijwel elk daarvan verplichtingen.
Deze gids behandelt hoe een project werkelijk verloopt, wat er wanneer van je gevraagd wordt, en de controlemomenten waarop een probleem nog goedkoop te herstellen is.
Omgevingen: waar de site woont voordat hij live is#
Vrijwel elk professioneel project draait drie kopieën van de site. Weten naar welke je kijkt voorkomt veel verwarring tijdens beoordelingen.
| Omgeving | Wie gebruikt hem | Waarvoor |
|---|---|---|
| Lokaal | De ontwikkelaar | Dagelijks werk; jij ziet dit nooit |
| Testomgeving | Jij en de ontwikkelaar | Beoordelen, testen en goedkeuren — afgeschermd voor zoekmachines |
| Productie | Bezoekers | De live site |
Content die op de testomgeving is ingevoerd verschijnt niet automatisch op productie, tenzij het project daarop is ingericht. Vraag dat vroeg, want 200 producten twee keer intypen is een reëel risico.
De volgorde van een typische bouw#
Namen verschillen per team, maar de volgorde ligt redelijk vast omdat elke stap op de vorige steunt.
- Aftrap. Eisen bevestigd, toegangen verleend, contactpersonen benoemd, data afgesproken.
- Inrichting. Repository, omgevingen, CMS of framework geïnstalleerd, uitrolstraat.
- Sjablonen. Het ontwerp wordt werkende sjablonen, meestal het complexste eerst.
- Contentmodellering. Velden en contenttypes zodat je team kan bewerken zonder opmaak te breken.
- Koppelingen. Betaling, CRM, e-mail, statistieken — elk vraagt inloggegevens van jou.
- Content invoeren. Van jou of van hen, afhankelijk van wat de offerte zei.
- Testen. Functioneel, over browsers, snelheid, toegankelijkheid.
- Controles vóór lancering. Omleidingen, robots, sitemap, statistieken, back-ups.
- Lancering. DNS-wijziging, verificatie, monitoring.
- Na de lancering. Correcties, overdracht, training, daarna onderhoud.
Wat jouw kant moet leveren, en wanneer#
De meeste vertragingen die op ontwikkelaarsvertraging lijken zijn wachten-op-de-klant. Dit zijn de zaken die klaar horen te liggen voordat erom gevraagd wordt, want elk blokkeert werk als het te laat komt.
| Jij levert | Nodig bij | Als het te laat komt |
|---|---|---|
| Toegang tot domein en DNS | Inrichting | De lancering is niet in te plannen |
| Merkmateriaal en logobestanden | Sjablonen | Voorlopige merkuitstraling gedurende de hele beoordeling |
| Paginacontent en afbeeldingen | Content invoeren | De meest voorkomende oorzaak van een gemiste lanceerdatum |
| Productgegevens | Content invoeren | De bouw van de webshop staat volledig stil |
| Inloggegevens van derden | Koppelingen | Koppelwerk blokkeert midden in een sprint |
| Feedback bij elke beoordeling | Elk controlemoment | Overwerk, omdat de bouw verder is gegaan |
| Juridische pagina's | Vóór lancering | Lancering uitgesteld voor een privacyverklaring |
Controlemomenten waarop een probleem nog goedkoop is#
De kosten van wijzigen stijgen sterk gedurende een project. Dit zijn de momenten om echt te kijken in plaats van te scannen, want na elk kost dezelfde wijziging een veelvoud.
- Na de wireframes: structuur en prioriteit zijn nog gratis te wijzigen.
- Na het eerste gebouwde sjabloon: hier merk je of het ontwerp echte content overleeft.
- Na de contentmodellering: probeer zelf een pagina te bewerken. Is het nu onhandig, dan blijft het jaren onhandig.
- Na de eerste koppeling: controleer of de gegevens terechtkomen waar je team werkelijk werkt.
- Op de testomgeving met echte content: het laatste punt waarop opmaakproblemen goedkoop zijn.
- Vóór de DNS-wijziging: omleidingen, statistieken en formulieren gecontroleerd.
Beoordelen op een telefoon is niet optioneel. De meeste sites krijgen het merendeel van hun verkeer van telefoons, en alleen op een bureaublad beoordelen is hoe mobiele problemen productie bereiken.
Veelgestelde vragen
Hoeveel van mijn tijd kost het project?
Meer dan de meesten begroten. Reken op een wekelijks controlemoment van dertig tot zestig minuten, plus contentwerk dat in dagen wordt gemeten en niet in uren. De sterkste voorspeller van een project dat op tijd afkomt is of de klantzijde één persoon heeft met de bevoegdheid om te beslissen en de tijd om te beoordelen.
Wat is een sprint en moet dat mij iets zeggen?
Een sprint is een vaste periode — meestal één of twee weken — waarin een afgesproken hoeveelheid werk wordt afgerond en aan jou getoond. Het raakt jou omdat het het ritme van beslissingen bepaalt: feedback tijdens een sprint is goedkoop, feedback drie sprints later is overwerk. Werkt je ontwikkelaar niet in sprints, dan wil je om dezelfde reden toch een vast controlemoment.
Kan ik voortgang zien voordat de site af is?
Ja, en dat zou je moeten. Vraag vanaf het eerste sjabloon toegang tot de testomgeving. Half werk zien is ongemakkelijk maar veel beter dan een onthulling aan het eind, wanneer structurele feedback duur is. Verwacht dat het onaf oogt — dat is precies de bedoeling van vroeg kijken.
Wat gebeurt er direct na de lancering?
Een korte periode — gebruikelijk twee tot vier weken — waarin kleine correcties gedekt zijn, en daarna een overgang naar een onderhoudsafspraak of naar niets. Spreek vooraf af welke van de twee het is, wat als correctie geldt tegenover een nieuwe wens, en wie je buiten kantooruren belt als de site eruit ligt. «Dat regelen we later» is hoe sites zonder onderhoud eindigen.
hoe werkt webontwikkelingwebontwikkelprocesfasen webontwikkelingtestomgevingwebprojectmanagementdoorlooptijd website
