Berichten

Website optimalisatie

Wat kost een website?

Opnieuw gepubliceerd

Dit artikel is eerder gepubliceerd in maart 2011

De prijs van een website

Laatst, natuurlijk vlak voordat ik op vakantie zou gaan, las ik op een forum van de Kamer van Koophandel een discussie over de prijs die iemand vraagt voor het maken van een website. De discussie die daar gevoerd werd gaf mij een ongemakkelijk gevoel. Want wat was het geval?

De prijzen die genoemd werden waren in mijn ogen vaak geheel onrealistisch en slecht doordacht. Ik maak me zorgen dat we onze eigen markt voor webontwerp en -ontwikkeling kapot maken en dat wij, als professionals,  ook niet helemaal serieus genomen worden als we onze werkzaamheden tegen dumpprijzen aan bieden.

Wat kost dat?

“Wat kost dat?” is waarschijnlijk de meest gehoorde vraag aan ons, webontwikkelaars. Logisch natuurlijk, dat vraag ik ook als ik iets ga kopen. Dan wil ik ook graag vantevoren weten wat iets kost. Echter, het verschil tussen een product en het ontwikkelen van een website is  dat het bouwen van een website veel meer lijkt op het kopen van verschillende onderdelen (die door samen te werken een werkende website opleveren) dan op het kopen van één product. Toch gaan onze potentiële klanten er vaak van uit dat een website een simpel product is, in plaats van een complex, samengesteld geheel (product). Een website bestaat uit verschillende onderdelen die tezamen zorgen dat de website het doet en werkt. Dit maakt het lastig om vantevoren een vaste prijs te geven, als je niet eens weet waaruit de website moet bestaan  en waar deze aan moet voldoen (welke techniek, welk framework, capaciteit,  (bezoekersaantallen), veiligheid, functionaliteiten, etc.).

Metafoor: een huis bouwen

Als eenvoudige metafoor gebruik ik vaak het bouwen van een huis. Als je aan iemand vraagt: “Wat kost een huis?” zal deze persoon je waarschijnlijk vreemd aankijken en zeggen “Wat voor huis zoek je?”. Als je dan een groot huis wenst, heb je nog steeds geen flauw idee wat dat zou moeten kosten. Dit moet gespecificeerd worden: hoeveel deuren, hoeveel vierkante meters, hoeveel tuin, wat voor materiaal, welke milieuaspecten / duurzaamheidsaspecten, waar moet het komen te staan, etc. etc.

Zo is het eigenlijk ook bij de bouw van een website. Wat voor site wil je, welke functionaliteit wil je, wie wil je bereiken, op welke plek wil je gevonden worden, standaardontwerp of maatwerk, etc. etc… Er gaat werk in zitten om dit te specificeren. Toch wordt er niet zo naar websites gekeken, terwijl dat wel zou moeten voor het slagen van de site.

Afstemmen verwachtingen: doelstellingen en ontwerp

Zo vanzelfsprekend het ontwerp van een huis of een tuin is, voordat überhaupt begonnen wordt met de uitwerking, zo vreemd wordt er vaak aangekeken als je als webdesigner of -ontwikkelaar zegt dat je eerst een tijdje nodig hebt om een ontwerp te maken. Hierbij gaat het zowel om een grafisch ontwerp als een functioneel ontwerp (en wellicht ook een technisch ontwerp) en prototypes (al dan niet op papier).

Het nadenken en ontwerpen van de website zijn de belangrijkste succesfactoren voor een website omdat je dan zowel als opdrachtgever als opdrachtnemer weet waar je aan toe bent en later op terug kunt vallen. Het opstellen van de specificaties kost (veel) tijd, maar is de moeite waard. Het is echter vaak zo dat deze ‘kostenpost’ niet wordt meegenomen in de offerte, terwijl het een belangrijk onderdeel is van het hele proces.

Dat kijn mijn buurjongen / neefje / vriend van een vriend ook wel / beter

Als webdesigner heb je waarschijnlijk vaak genoeg gehoord dat iemand wel iemand kent die heel goed is met computers en ook wel een website kan maken of aan webdesign doet. Maar het ontwikkelen van websites is, zeker in een vakgebied waarbij de kennis van vandaag morgen alweer achterhaald kan zijn, een vak waarin enorm veel tijd gaat zitten. Het is zelfs voor ‘web professionals’ onmogelijk om op alle terreinen bij te blijven, daarvoor zijn de werkzaamheden te divers.

Je kunt natuurlijk ook je tuin zelf ontwerpen, of door een hobbytuinier laten doen, maar als je zeker wilt weten dat het goed komt huur je een tuinarchitect in. Deze kent de valkuilen en kan het groter geheel overzien (waterhuishouding, stand van de zon, etc.). Dit heeft zijn prijs, maar je hebt ook zekerheid. Zo is het ook met webontwikkeling. Je kunt het voor een zacht prijsje (of zelfs gratis) laten doen door iemand die het als een hobby ernaast doet, maar vaak vallen de resultaten tegen en wordt niet alles meegenomen in het traject. Denk hierbij aan gebruikte techniek, veiligheid, zoekmachineoptimalisatie, flexibiliteit, onderhoudbaarheid, etc. (een enorme lijst, hier kom ik in een later blogitem terug).

Het ontwikkelen van websites is een vak, wij zijn professionals die hier met volle overgave dagelijks met bezig zijn.

Web professionals: wees trots en vraag de beloning die je verdient

Ik ken eigenlijk geen vakgebied waarbij je zoveel diverse kennis moet hebben om tot een succesvol eindproduct te komen. Natuurlijk kun je deze kennis ook verdelen (als je gebruik maakt van specialisten) maar het is bij webontwikkelaars in mijn ogen nog steeds zo dat enorm veel kennis bij één persoon zit. Je moet iets weten van:

  • webdesign
  • techniek
  • functioneel ontwerp
  • zoekmachineoptimalisatie
  • gebruiksvriendelijkheid
  • (online) marketing
  • projectmanagement
  • psychologie

Ik heb bewust een … neergezet, omdat deze lijst nog veel langer kan zijn. Buiten de vakgebied specifieke kennis moet je ook wel een paar kwaliteiten beschikken om succesvol te zijn. Zo zijn bijvoorbeeld communicatieve vaardigheden ook wel handig als je met een opdrachtgever in overleg gaat of aan acquisitie moet doen, mensenkennis is daarnaast welkom (hoe ga je met verschillende opdrachtgevers om). Een beetje kennis van financiën is ook onontbeerlijk.

Het is niet vreemd om geld te vragen voor kennis die je in de loop der jaren hebt vergaard. Vaak worden bij andere beroepen trainingen gedaan die verdisconteerd zijn in de tarieven en worden mensen bijgeschoold indien nodig (denk aan advocaten, bankiers, notarissen). Wij als webprofessionals doen hier niet aan mee, terwijl voor ons het juist ontzettend belangrijk is om bij te blijven en (dagelijks) nieuwe dingen te leren. Waarom laten we ons niet voor onze kennis belonen? Het is inderdaad dat het soms slechts een halfuurtje kost om iets te bouwen, maar vaak is het zo dat het uren, dagen of zelfs weken heeft gekost om achter de juiste implementatie te komen (zelf had ik laatst iets met de uitwerking van een menu. Nu ik weet hoet ik dat moet doen kost het me inderdaad nog geen kwartiertje, maar het traject naar de oplossing heeft me denk ik wel vier dagen gekost).

Onderzoek kost ook tijd (en geld)

Vreemd is ook dat het bij ons not-done is om te zeggen dat je iets niet weet en dat je dit nog uit moet zoeken (laat staan dat je je hiervoor laat betalen). Hoe vaak is de bouw van een website nu écht helemaal standaardwerk? Ik ben het nog niet tegengekomen. Altijd moet er wel iets uitgezocht worden en uitgetest worden of het wel werkt in een specifieke situatie. Dat is geen enkel probleem en houdt het werk als webontwikkelaar ook leuk, maar het is wel iets waar je rekening mee zou moeten houden bij het opstellen van je prijs.

Wat nu?

Ik pleit ervoor dat we als webdesigners / webontwikkelaars en online marketeers eens kritisch naar onze werkzaamheden kijken en eerlijke prijzen vragen voor wat uiteindelijk doen. Ik denk dat een deel van ons zal schrikken van de tijd die we echt kwijt zijn (en van bijkomende kosten, als software, hardware, huur kantoorruimte, etc. maar ook pensioenen en verzekeringen) en dat het nodig is om deze toch mee te nemen in de tarieven. Alleen op deze manier kunnen we onze markt professionaliseren en ook de waardering krijgen die we verdienen. Ik zeg niet dat de tarieven meteen hard omhoog moeten, maar het aanbieden van een website voor € 250,- is in mijn ogen niet realistisch (hiervoor kun je niet een uniek ontworpen, geteste en geïnstalleerde website leveren). Houd rekening met alle werkzaamheden die je moet uitvoeren om een werkende website op te leveren en breng deze ook netjes in kaart. Je opdrachtgever zal eerder bereid zijn mee te gaan in jouw voorstel als je de kosten inzichtelijk maakt en eerlijk bent over de complexiteit van je werk.

Checklist

Neem sowieso de volgende aspecten mee in de berekening van je tarief of prijs voor een project

  • overlegmomenten
  • reiskosten
  • grafisch ontwerp van de website (inclusief eventueel vervaardigen aanvullend beeldmateriaal)
  • functioneel ontwerp
  • kosten aanvullende functionaliteit (breng in rekening wat achteraf nog door de opdrachtgever wordt toegevoegd)
  • installatie op productieomgeving
  • inrichten en installatie van een testomgeving
  • projectmanagement

Ik ben benieuwd naar jullie mening, graag hoor ik jullie ervaringen en aanvullingen op mijn blogitem…

Website met CMS is niet altijd zaligmakend

Veel websites zijn tegenwoordig gemaakt met een Content Management Systeem. Een website zonder CMS is eigenlijk niet meer van deze tijd, tenminste dat wordt veel gezegd. Maar is dit wel zo?

Veelal ingegeven door de wens van de opdrachtgever om ‘zelf plaatjes en tekst’ te kunnen toevoegen wordt gebruik van een website met CMS. Dit is echter vaak slechts een deel van de onderliggende wens: “Ik wil mijn website zelf kunnen bouwen”. Hiermee ontstaat wel eens de illusie dat een website met een CMS op elk moment helemaal te wijzigen is en elementen naar hartelust zijn toe te voegen. Dat is echter een groot en wijdverspreid misverstand. Ook bij het bouwen van een website met een CMS staat op een bepaald moment het raamwerk vast. Daarom is de eerste fase van (functioneel) ontwerp en het opzetten van een structuur van groot belang (zo niet het grootste belang), om het raamwerk te definiëren en vast te stellen wat een opdrachtgever met zijn CMS wil én kan. Communicatie is hierbij het sleutelwoord.

CONTENT Mangement Systeem

Wanneer gesproken wordt over een CMS is vaak de definitie niet duidelijk of hetzelfde bij alle partijen. Mijn mening is dat een Content Management Systeem bedoeld is voor het onderhouden (toevoegen, verwijderen, bewerken) van inhoud door de gebruiker, oftewel content van een website en niet om de structuur of layout steeds te kunnen wijzigen. Dit blijft mensenwerk.

Het heet niet voor niets een “Content Management Systeem”, en niet “Website Structuur Management Systeem”. Het zou erg fijn zijn als dat bestaat, maar dat is niet (nog) zo. Een computer is per definitie dom, wij als webontwikkelaars moeten hem (ik spreek in de hij-vorm, overigens zegt dit niks over mijn beeld van man/vrouw) vertellen hoe de structuur van de data is, wat de relaties zijn en hoe de hierarchie is en hoe dit allemaal getoond moet worden. Als je dus ergens in de hierarchie iets wijzigt, zul je de computer ook moeten vertellen dat hij er anders mee om moet gaan. Alles moet dus geprogrammeerd worden. En dat kan best grote gevolgen hebben….

Valkuilen

Tijdens mijn werk als webdesigner heb ik verschillende CMS oplossingen geïmplementeerd, waaronder de open-source frameworks WordPress en Drupal. Daarnaast heb ik ook ervaring met MODx. Alle drie hebben voor- en nadelen, maar dat behandel ik graag in ander blogitem. Ik wil me nu beperken tot de valkuilen die ik steeds weer tegenkom en waarbij vaak de verwachtingen niet helemaal kloppen met de mogelijkheden die een website met CMS kan bieden.

Op basis van mijn ervaringen met het opzetten en communiceren over een CMS onderscheid ik de volgende valkuilen:

  • onrealistische verwachtingen omtrent mogelijkheden van de website met CMS
  • omdat het een CMS is wordt er gedacht: ach, dat kan later ook nog wel, voegen we nog wel toe (dat blijkt in de praktijk soms lastig realiseerbaar of schopt de hele architectuur onderuit)
  • technische onwetenheid van de eindgebruiker zorgt voor discussies
  • niet denken in structuur en functionaliteit, zodat gevolgen voor wijzigingen niet duidelijk zijn
  • relatie van data onderling niet duidelijk voor gebruiker
  • denken in categorisering en hierarchie is niet voor iedereen makkelijk op te pikken
  • een computer is per definitie dom (nog wel) dus alle wijzigingen in functionaliteit moeten aan de computer ‘verteld’ worden (geprogrammeerd)

Hiervoor zijn uiteraard verschillende oplossingen te bedenken, ik ben van mening dat alles begint met COMMUNICATIE. Vertel in eerlijke bewoordingen de mogelijkheden én onmogelijkheden, leg duidelijk uit wat vaststaat en wat de gebruiker later nog kan wijzigen. Gebruik hiervoor concrete voorbeelden.

Uiteraard heeft een CMS veel voordelen ten opzichte een traditionele website, waarbij de pagina’s nog stuk voor stuk werden aangemaakt door de webdeveloper (of iemand met ‘verstand van websites’).

Voordelen van een CMS

Zoals gezegd kent een CMS, mits goed gecommuniceerd en gebouwd, vele voordelen:

  • Eindgebruiker heeft in veel gevallen de webontwikkelaar niet meer nodig
  • Bij gebruik van open source systemen zit de opdrachtgever niet vast aan één leverancier
  • Het onderhoud van de website is vele malen sneller en eenvoudiger dan op de oude manier
  • Het systeem is flexibeler
  • Het bespaart tijd voor de gebruiker (deze hoeft niet meer te bellen, te vragen, etc, maar kan het zelf doen)
  • Het bijhouden van de website is leuk! Elke wijziging is voor de gebruiker direct te zien op het scherm
  • Lagere kosten / geen maandelijkse kosten

Hoe nu verder?

Ik zeg bewust dat een CMS ontzettend belangrijk en handig kan zijn. Met name voor grote websites is het eigenlijk niet mogelijk om alles bij te houden zonder een goed systeem voor de inhoud. Maar hou bij het opzetten van een CMS altijd rekening met de volgende punten:

  • Leg duidelijk de eisen en wensen vast
  • Maak altijd de mogelijkheden en onmogelijkheden duidelijk
  • Er is soms ook onderhoud achteraf nodig (updates, veiligheid, nieuwe ontwikkelingen)
  • Hoe dan is er ook een leercurve voor gebruiker (ook met Outlook of Word heeft men moeten leren omgaan)
  • Vraag altijd door; wat wil een klant nu echt, wat heeft hij echt nodig, wat is het achterliggende probleem, etc…. is dit werkelijk een CMS?

Ik vind een CMS een prachtig stuk gereedschap, maar ben van mening dat soms een stapje terug ook geen kwaad kan. Waarom zou je een website met CMS optuigen als de klant eigenlijk maar 5 pagina’s statische content nodig heeft?