10 valkuilen bij de bouw van een website

Onderschatting van de tijd die het kost inhoud te migreren
Bedrijven zien nogal eens over het hoofd dat bij vernieuwing van de website niet alleen de inhoud, maar ook templates, JavaScripts, beelden en mediabestanden van de oude site gemigreerd moeten worden. Aanpassing aan de vereisten van de nieuwe site is in de regel geen sinecure.

Misrekening bij de vaststelling van bandbreedte- en netwerkeisen
Data-uitwisseling in de achtergrond kan bezoekers van de website lelijk in de weg zitten, maar daar wordt bij de dimensionering van het netwerk vaak geen rekening mee gehouden.

Beveiliging pas achteraf regelen
Het is een misvatting te denken dat je ontwikkelteam beveiliging wel regelt; beveiligingsmaatregelen moeten vanaf het allereerste ontwerp meegenomen worden.

Schaalbaarheid uitbesteden aan de cloud
Webapplicaties moeten speciaal ontworpen zijn om gebruik te kunnen maken van meer processorkernen of verwerkingseenheden. Anders helpt het bijschakelen van hardware niet om meer webverkeer te kunnen afhandelen.

Na de lancering Gods water over Gods akker laten lopen
Bij een nieuwe website hoort een planmatige aanpak voor het uitvoeren van back-ups, eventuele hersteloperaties en het uitvoeren van upgrades – inclusief testen of alles werkt zoals het bedoeld is.

Beknibbelen op het opleidingsbudget
Het kiezen van geschikte technologie is niet voldoende. Men moet er ook voor zorgen dat het ontwikkelteam over de kennis beschikt en blijft beschikken om die technologie ten volle te benutten. Wie beknibbelt op opleidingen, betaalt daarvoor in de vorm van suboptimale oplossingen en op termijn hogere onderhoudskosten.

Te veel tegelijk doen
Veel bedrijven willen in één keer een brede site neerzetten. Dat vergroot de kans op mislukken en zorgt voor veel stress. Stap voor stap uitrollen van kleinere deelprojecten werkt veel beter en leidt ook meestal tot een beter eindresultaat omdat nog ingespeeld kan worden op reacties van gebruikers/bezoekers.

Bang zijn voor verandering
Angst voor aanpassingen tijdens het traject leidt meestal tot een slechter resultaat dan een open beleid waarin reacties juist aangemoedigd en omarmd worden. Het is daarbij wel zaak om het proces van inwachten van reacties goed te managen, steeds goed te wegen wat de voors en tegens van een eventuele aanpassing zijn, en open met alle betrokkenen te communiceren over de beslissing die uit die afweging rolt.

Iets meer prekend voor eigen parochie, maar daarmee nog niet zonder waarde, zijn de volgende 2 valkuilen die Beardslee signaleert:

Negeren van de expertise van de leverancier
Wie alleen zaken doet met zijn implementatiepartner, loopt een verhoogd risico dat hij door de gemaakte keuzes afhankelijk wordt van die partner. De softwareleverancier als derde partij aan tafel brengen, verhoogt bovendien de kans dat een passende architectuur wordt gekozen, helpt onnodige risico’s te vermijden en zorgt dat eventuele problemen die tijdens het project ontstaan, sneller opgelost worden.

Kiezen voor een inflexibel data-opslagsysteem
Contentmanagementtools die je dwingen vooraf alle potentiële datatypes te definiëren kunnen behoorlijk in de weg zitten als er nieuwe toepassingen worden ontwikkeld, laat staan wanneer die tools programmeerwerk vereisen voor het verwerken van bepaalde datatypes.

Een website is voor veel organisaties het meest zichtbare punt naar de markt. Mislukking van een webproject kan daardoor een sterk negatief effect hebben op de reputatie van de organisatie. Maar wie zich goed voorbereidt en bovenstaande valkuilen weet te vermijden, kan van zo’n project een doorslaand succes maken, stelt Beardslee.

Zijn volledige betoog is te vinden op de website van SD Times.