Async werken: wat schrijf je op en wanneer bel je

Schrijf op wat een ander later moet kunnen terugvinden of zonder jou moet kunnen begrijpen: besluiten met de reden erbij, vragen met genoeg context en de stand van je werk. Pak een call als iets heen en weer gaat zonder op te schieten, of als je samen iets moet bedenken. Na die call schrijf je de uitkomst alsnog op.

Ik werk als developer vanuit Servië in teams van klanten. Servië zit in dezelfde tijdzone als Nederland, dus we overlappen de hele werkdag. Async werken is voor mij een manier om geconcentreerd te werken en kennis vast te leggen die anders in iemands hoofd blijft zitten.

Wat altijd op schrift moet

Een paar dingen schrijf ik altijd op, ook als ze in een call zijn besproken:

• Besluiten, met de reden erbij. Over een half jaar weet niemand meer waarom de keuze zo is gemaakt, maar het ticket of de commit weet het nog wel.
• Aannames. Als ik verder moet zonder antwoord, schrijf ik op wat ik aanneem, zodat iemand me kan corrigeren voordat het in productie staat.
• Hoe je iets draait of test. Dat hoort in de README of in de beschrijving van de pull request, niet in een chatbericht.
• Wat ik bewust niet heb gedaan. Dan denkt een reviewer niet dat ik het vergeten ben.

Een vraag die in één keer te beantwoorden is

Het bekende "heb je even?" kost twee keer tijd: de ander moet reageren, en daarna moet jij je vraag alsnog stellen. Schrijf de vraag dus meteen helemaal uit. Geef de context, zeg wat je al hebt geprobeerd, stel de concrete vraag en zeg wat je doet als er geen antwoord komt.

Bijvoorbeeld:

In het ticket voor de nieuwe kortingsregel staat dat de korting ook voor bestaande abonnementen geldt. Moet ik lopende abonnementen met terugwerkende kracht herberekenen, of alleen vanaf de volgende factuur? Ik ga nu uit van de volgende factuur en zet dat in de PR. Zeg het als het anders moet.

Daar kan iemand tussen twee meetings door met één woord op antwoorden, en als het antwoord even op zich laat wachten, ligt het werk niet stil.

Wanneer je beter belt

Schrijven werkt slecht als je samen iets moet bedenken. Bij een ontwerpkeuze met drie opties en vier meningen kom je in een thread niet verder. Ik bel ook als een discussie na drie berichten heen en weer nog steeds niet opschiet, want tien minuten bellen kost dan minder dan nog een uur typen.

Feedback die verkeerd kan vallen, bespreek ik ook liever in een call. Een kritische opmerking komt op schrift harder over dan bedoeld, zeker in een tweede taal. Onze werktaal is Engels, en dat is in een gemengd team vaak niet ieders moedertaal.

Na de call schrijf ik twee of drie regels in het ticket of de thread: wat we hebben besloten en wie wat doet. Anders weet de rest van het team niet wat er is afgesproken.

Pull requests zijn ook documentatie

Een goede PR-beschrijving bespaart een call met de reviewer. Ik zet erin wat de wijziging doet, waarom, hoe je hem test en wat ik bewust heb laten liggen. Bij een wijziging aan de interface komt er een schermafbeelding of korte opname bij, en de link naar het ticket staat bovenaan.

Dat lijkt veel voor een kleine PR, maar meestal zijn het een paar regels. De reviewer hoeft dan niet eerst het ticket, de chat en de code naast elkaar te leggen om te snappen wat er gebeurt. Over de review zelf gaat code review op afstand.

De stand van je werk zichtbaar maken

Op afstand ziet niemand dat je vastzit. Is het werk aan het eind van de dag niet af, zet dan een korte update in het ticket: waar het staat, wat de volgende stap is en of je ergens op wacht. Dat kost een minuut, en wie het ticket morgen overneemt of erop wacht, hoeft niet te vragen hoe het ervoor staat.

Het bord moet kloppen. Een ticket dat op "in progress" staat terwijl je aan iets anders werkt, geeft de rest van het team een verkeerd beeld. De stand-up wordt dan een rondje navragen in plaats van een kort overleg over wat vastzit.

Eén plek per soort informatie

Informatie die over allerlei tools verspreid staat, vindt niemand terug. Houd per soort informatie één plek aan:

• besluiten en context bij het ticket, of in een korte notitie in de repository als het de architectuur raakt
• uitleg over hoe iets werkt in de README of de docs in de repository
• discussies in een thread in het teamkanaal, niet in privéberichten

Privéberichten zijn handig, maar wat daarin wordt besproken, weten precies twee mensen. Vraag ik in een privébericht iets wat ook voor anderen nuttig is, dan zet ik het antwoord daarna in het kanaal of het ticket.

Wat de opdrachtgever kan doen

Async werkt alleen als vragen ook beantwoord worden. Spreek af hoe snel dat gebeurt, bijvoorbeeld binnen een halve werkdag. Zeg het als je een dag niet bereikbaar bent, en wie er dan antwoordt. Accepteer ook dat een developer met een opgeschreven aanname verder werkt in plaats van te wachten. Dat is sneller, en als de aanname niet klopt, zie je dat in de PR.

Hoe we de samenwerking verder inrichten, staat bij onze werkwijze.