Bij Elephant werken we al ruim 9 jaar aan verschillende typen webprojecten. In het begin ging het voornamelijk om WordPress websites, maar tegenwoordig zijn de projecten enorm uiteenlopend. Van webshops, intranet oplossingen, webapps en websites op maat. Met de toename aan verschillende typen projecten, komt één onderwerp bij ons ook steeds vaker naar voren: Goede documentatie.
Wat verstaan we onder ‘goede documentatie’? Wanneer is het noodzakelijk en wanneer is het ‘overkill’ binnen je project? En wat moet je dan precies documenteren en voor wie? In dit artikel geef ik je antwoord op deze vragen.
Wat verstaan we onder documentatie?
Voordat we verder gaan, is het belangrijk een toelichting te geven over wat documentatie precies inhoudt. Dit zijn alle documenten die worden gemaakt ter ondersteuning van een project. Denk hierbij aan een project briefing en planning, schetsen of wireframes, user stories, persona’s, customer journeys, interactieontwerpen, etc. Ieder document heeft een specifiek doel en draagt bij aan het zo succesvol afronden of voortzetten van een project. Je kunt dus stellen dat ieder project een vorm van documentatie nodig heeft.
Belangrijk om bij stil te staan is dat documentatie geen enorm boekwerk is. Het doel van een document is niet dat het uitlegt hoe een website werkt. Het biedt ondersteuning tijdens het uitleggen. Het is niet mogelijk uit te leggen hoe een website werkt zonder ‘menselijk contact’. Documentatie maak je dus als ondersteuning bij je uitleg aan iemand.
Technische documentatie. Wel of niet nodig?
De belangrijkste redenen om niet te documenteren zijn tijd en geld. Het kost nou eenmaal tijd om op te zetten en in die tijd kun je natuurlijk ook werken aan het daadwerkelijke product. Je product wordt toch niet beter van een goed document? Nou, in sommige gevallen kun je wel voorkomen dat het product er minder goed door wordt. Dit zie je vooral terug in twee punten:
1. Overdragen van projecten aan nieuwe developers
Regelmatig komt het voor dat er nieuwe developers aan een project worden toegevoegd, of dat er een implementatiepartij aanschuift voor een bepaald onderdeel binnen het project. Documentatie is enorm waardevol wanneer je een project (of een deel van het project) over wilt dragen. Het is iets waar de nieuwe developer of een dergelijke externe partij op terug kan vallen bij onduidelijkheden. Wederom; het doel van documentatie is niet om alle uitleg te bieden, maar om ondersteuning te bieden bij de uitleg.
2. Hervatten van projecten
Het komt bij ons vaak voor dat een project na een jaar weer opgepakt wordt om verder uit te breiden. Maar hoe zat het ook alweer met hetgeen wat we het jaar ervoor hebben opgeleverd? In zulke situaties biedt documentatie net dat beetje steun om het project beter op pakken.
In veel webprojecten werken we met het scrum projectmethodiek. Dat betekent dat vraagstukken pas in een sprint zelf worden aangepakt. Van te voren documenteren is dan vrij zinloos en zonde van de tijd.
Echter is het wel waardevol ruimte in sprints te bewaren om de gemaakte oplossingen beknopt te documenteren voor latere sprints. Zeker wanneer het team kan gaan wisselen of wanneer het vrij complexe functionaliteiten zijn waaraan gewerkt wordt.
Online strategie als onderdeel van documentatie
Documentatie hoeft dus niet altijd technisch van aard te zijn. Bij Elephant ontwikkelen we bij ieder project een online strategie, waarin we de doelen, doelgroepen en structuur van de website/shop/app in grote lijnen noteren. Dit beschouwen we als ondersteuning voor onze interne briefing en tegelijkertijd toetsen we of we op één lijn zitten met de opdrachtgever. Een dergelijk strategisch document werkt dus heel goed en hoeft niet veel tijd in beslag te nemen. Ook dit is een vorm van documentatie en kan voor ieder project worden toegepast.
Belangrijke factoren bij het opstellen van documentatie
Je wilt graag aan de slag met documentatie binnen je project. Maar wat is nu het juiste format voor jouw document? Een presentatie, excel sheet, een apart trello board of een eenvoudige Word document? Het is handig met een aantal factoren rekening te houden, zodat je jouw documentatie daadwerkelijk ook bruikbaar maakt.
1. Voor wie is het document?
Het document moet worden aangepast aan je lezer. Zijn het developers, marketeers, verkopers? Hebben ze een technische achtergrond? Hebben ze affiniteit met het web? Dit heeft enorme impact hoe je de documentatie op gaat zetten (middels een Word document, een Powerpoint sheet, Evernote of iets anders?).
2. Hoe gaat het document gebruikt worden?
Denk goed na over het gebruik van je document. Moeten developers het als naslag kunnen gebruiken om een bepaalde feature te implementeren? Of moeten stakeholders begrijpen wat de waarde van een feature zal zijn? Dient het document tijdens het project verder aangepast of uitgebreid te kunnen worden? Afhankelijk van wanneer en waarvoor het document gebruikt dient te worden, kies je dus het juiste format en de juiste inhoud voor jouw document.
3. Wat voor doel heeft het document?
Een document moet een doel hebben. Je kunt het gebruiken om een groep ergens van te overtuigen of om bijvoorbeeld eindgebruikers te helpen in het beheer van een app. Afhankelijk van hetgeen dat je wilt bereiken, kies je een geschikte format en ontwikkel je een structuur. Een voorbeeld hiervan is: Aangeven op welke manier de formulieren in WordPress gekoppeld worden aan de CRM software van de klant.
Eindconclusie
Documentatie in webprojecten heeft dus wel degelijk zin en kan veel waarde aan een project toevoegen. Nee, het eindproduct wordt er niet direct beter van, maar goede documentatie biedt het projectteam ondersteuning effectief te kunnen werken op langer termijn. Ook hoeft documentatie niet erg veel tijd te kosten als je het op een pragmatische manier blijft toepassen.