Wat gebeurt er als Tom op vakantie gaat?

Documentatie mislukt niet omdat mensen lui zijn. Ze mislukt omdat dat altijd bovenop het eigenlijke werk komt.

De eerste keer dat ik zelf ineens begreep wat de kostprijs is van kennis niet deftig vast te leggen, kwam ik zelf uit vakantie. In dat bedrijf was ik normaal degene die de release notes schreef. Tijdens mijn afwezigheid was er gewoon doorgelereased: bugfixes, nieuwe features, ... Maar niemand had echter de release notes deftig opgepakt. Niet uit slechte wil, het was er simpelweg gewoon niet van gekomen. Ik kon dus op de eerste dag terug archeoloog spelen: uitzoeken wat er veranderd was, zelf de nodige kennis opvragen bij de ontwikkelaars, en vooral er terug invliegen met een overvolle supportinbox terwijl ik zelf al achterliep.

Wat mij toen overkwam gebeurt in bijna elke groeiende organisatie, alleen gebeurt dat meestal andersom. Ergens zit er wel een "Tom" of een "Jan": die ene collega die het antwoord op de meeste vragen wel weet. Zolang die persoon er is, draait alles. Zodra hij twee weken weg is valt plots op dat er zaken blijven liggen. Een offerte kan niet uitgestuurd worden, een klant kan geen sluitend antwoord op zijn vragen krijgen. Een junior maakt iets dat technisch wel klopt, maar eigenlijk niet juist is en moet dat een week later opnieuw ongedaan maken.

Zo was er ook ooit een bedrijf waar de lead developer zichzelf (zonder daar echt ooit bewust over te beslissen) had ingebouwd als laatste check vóór een release. Niets ging online zonder zijn akkoord. Toen hij twee weken de Ardennen in trok, lagen niet alleen de nieuwe features stil, maar ook de bug fixes voor klanten die al klaagden. Niemand had dat zo bedoeld, maar het was gewoon zo gegroeid.

De klassieke reflex op dat moment is steeds hetzelfde. "We moeten dat eens documenteren". We vragen die ene collega dan bij zijn terugkomst om eens uit te schrijven hoe hij dat doet, of waar zijn team de antwoorden had kunnen vinden. Iemand zet een Notion op, of gaat Confluence gebruiken, of misschien wordt er een gedeelde map aangemaakt waar we afspreken om vanaf nu de kennis te verzamelen. De eerste week werkt het. De vierde week ook nog, half. Tegen de zesde week ligt dat weer stil. Dat is niet omdat het team lui is, maar omdat documenteren altijd bovenop de echte werklast komt. Je moet daar maar tijd voor vinden in je overvolle schema. Er is altijd een release die de deur uitmoet, een klant die belt, een bug die niet kan wachten. Documenteren is niet alleen een kwestie van discipline, maar ook van prioriteiten.

Tijd voor verandering

De manier waarop je dit echt kan veranderen is door het uitgangspunt om te draaien. De beste momenten om kennis te gaan vastleggen zijn niet die waarop iemand zich apart neerzet om te gaan documenteren. Meestal heb je daar toch geen tijd voor. De beste momenten zijn de gewone werkmomenten zelf. De kennis is er al, die moet alleen opgevangen worden op het juiste moment.

Dat was het uitgangspunt bij Sarrai. Want ik heb in het verleden al heel vaak gemerkt dat je je engineers niet kan vragen om even twee alinea's te schrijven over een nieuwe feature. Het lukte zelden, of ik dat nu via mail of via Teams vroeg. Maar als ik gewoon naast iemand ging staan en zei "vertel even hoe dat precies werkt", dan kreeg ik vijf minuten heldere uitleg. Niet omdat hij het plots minder druk had, maar omdat de drempel om aan iets te beginnen schrijven veel hoger ligt dan we willen toegeven.

Bij Sarrai proberen we dat probleem op te lossen. Het systeem geeft je niet gewoon een blanco blad en een knipperende cursor, maar een vraag om op te antwoorden. Het schrijven zelf, dat doet de AI voor jou. Jij kan nog de eindredactie doen en jij beslist wat er live gaat.

Zo kan Tom op vakantie blijven gaan, en blijft zijn kennis toch mooi bij ons.