Kunsten at anmelde

Jeg overdriver ikke, hvis jeg siger, at vi bruger mindst en time om dagen på at gennemgå hinandens arbejde. Hvorfor så meget? Svaret er klart. Gennem peer review opretholder vi kvaliteten af vores produkter. Derudover lærer vi meget af det som feedbackmodtagere og -anmeldere. Men at gennemføre en anmeldelse er ikke nogen lille bedrift. Du skal konstruktivt kritisere dine kollegers arbejde, som i nogle tilfælde har krævet blod, sved og tårer. Hvordan gør man feedback konstruktiv og klar? Vi diskuterer tre metoder til peer review, herunder vores favorit.

Løsninger, løsninger, løsninger 

For at optimere kvaliteten af dit arbejde er der brug for dybtgående feedback. En måde at lave peer review på er det, jeg kalder vide-det-hele-metoden. Du gør koden eller teksten til din egen. Du har set hvert ord, hver sætning, hvert mellemled eller hver streng flere gange og foreslår alternativer til dele, der ikke lever op til kvalitetsstandarderne. Nogle gange ledsages dette af en forklaring på, hvorfor du har ændret det;

Jeg har tidligere brugt denne metode. Se, hvordan jeg ændrede indledningen, som min kollega Jeroen skrev til sin artikel "Why we don't do overtime."  

Kender du det: Du er i gang med et projekt med en stram deadline. Du arbejder ekstra for at nå deadline. Efter nogle dages overarbejde kommer du sent og træt hjem, spiser usundt og går direkte i seng. Næste morgen står du tidligt op og er stadig ikke udhvilet efter den korte nat. Tag dig sammen, vær stærk og heroisk og få denne deadline i hus. Du lover dig selv, at næste gang bliver anderledes. At du vil planlægge bedre, lave de forbedringer, du sprang over denne gang. Du vil forlade kontoret til tiden og spise med din familie eller tage en drink med dine venner. Men næste gang er der et andet vigtigt projekt med en deadline. Og det gentager sig.

_{Udkast til introduktion af artiklen "Why we don't do overtime", skrevet af Jeroen.}

Jeg foreslog at ændre det til dette for at gøre det mere tiltalende som introduktion:

I de fleste jobs forventes der ofte overarbejde. Vi tror ikke på, at overarbejde er løsningen på at få arbejdet gjort og overholde deadlines. Igen og igen. Faktisk mener vi, at det er kontraproduktivt. Derfor afslutter vi tingene efter en otte timers dag, en almindelig arbejdsdag i Holland. 

_{Endelig introduktion til artiklen "Why we don't do overtime", skrevet af Jeroen.} .

Efter min mening var Jeroens indledning for lang og bestod af oplysninger, der blev gentaget i brødteksten. Jeg brugte en del tid på at finde på en ny indledning, og Jeroen accepterede den;

Når man erstatter sit eget arbejde med andres, mindskes følelsen af fuldt ejerskab.

Hvad gik der galt? Jeg gav straks løsningen. Denne metode til gennemgang er ikke bedre end bare at bede om godkendelse. Som modtager af feedback får du selvfølgelig et glimt af årsagen til ændringen. Men ved ikke selv at skrive det om, går du glip af muligheden for at forbedre dine skrivefærdigheder. Desuden reducerer det følelsen af fuldt ejerskab, når man erstatter sit eget arbejde med andres. Det føles ikke længere som dit arbejde. Desuden kan usikkerheden øges, hvilket kan føre til dårligere kvalitet i det fremtidige arbejde. Know-it-all-metoden kan også fremme noget helt andet: Du tager feedbacken for givet og er ikke længere kritisk over for den. Det er heller ikke noget, vi ønsker, for enhver form for feedback bør også være en mulighed for at lære. Efter vores mening er det at gennemgå den feedback, du modtager, nøglen til din egen udvikling som (front-end eller back-end) udvikler eller skribent;

Hurtig og beskidt 

I den anden ende af spektret har du den hurtige og beskidte metode. Den består i at bede dine kolleger om at godkende det arbejde, du har udført for at komme videre til næste trin i processen. Egentlig vil du ikke have feedback. Du vil bare have noget online, fordi: 

1. I har udviklet kodestykket sammen (pair programming). 

2. Det er så lille en ændring, at der ikke kan gå noget galt. 

3. Du føler tidspres, og kommentarer skaber forsinkelse.

4. Du har diskuteret løsningen med en kollega og implementeret den bagefter.

I tilfælde af grund A og B er den hurtige og beskidte måde tilladt. I vores daglige arbejde gør vi det ret ofte. Det er bare en del af vores proces. Men det gælder ikke for grund C, D og andre komplekse opgaver. Her er det faktisk nødvendigt med et ekstra par øjne, for djævlen ligger i detaljen;

Mødes i midten 

De to nævnte peer review-metoder er ikke ideelle med hensyn til læring. Derfor mødes vores elskede metode et sted i midten. Efter vores mening er værdifuld peer-feedback:  

• Er konstruktiv. Vi behandler kolleger og deres arbejde med respekt. 

• Får dig til at tænke. Det hjælper dig med at reflektere over dit arbejde og opfordrer dig til at tænke på andre løsninger. 

• Består af spørgsmål. Hvorfor gjorde du det på denne måde? Hvad er grunden til denne opsætning? Tænkte du på mulighed X og Y i stedet for kun Z?

• Gør det muligt for folk at bearbejde det selv. Det peger dem i den rigtige retning uden at give hele løsningen. Men nogle gange er det meget svært at holde sig tilbage, især når det drejer sig om mindre fejl. For eksempel: uhensigtsmæssigt navngivne funktioner og variabler (kode) eller grammatiske fejl (indhold). 

Vi ser peer-feedback som en samtalestarter. Joan, der er Back-End Developer hos Easy LMS, forklarer: "Jeg afslører ikke hele løsningen, nogle gange kun en del, men jeg diskuterer primært, hvordan et alternativ kan opnås ved refaktorering. Og det betyder nogle gange, at jeg bogstaveligt talt sætter mig ved siden af nogen for at guide dem igennem i stedet for at spille pingpong via GitHub eller BitBucket, som er de værktøjer, vi bruger til kodegennemgang."

"Det gør jeg også nogle gange: Jeg tilbyder flere alternativer og lader det være op til feedbackmodtageren at beslutte, hvilket alternativ der passer dem bedst. Det er en hjernevrider, fordi flere muligheder skal overvejes nøje."

_{Eksempler på en kodegennemgangssamtale i GitHub.}

Ifølge Joan er der ikke altid brug for dialogisk feedback. Det afhænger af typen af kode. "Hvis nogen ved et uheld har lagt en (sikkerheds)sårbarhed ind i koden, så er det klart, at den skal fjernes. Jeg vil selvfølgelig forklare, hvorfor den skal fjernes, og hvordan du kan undgå den fra nu af, men det er ikke et ideelt tidspunkt for en stor samtale. Så passer ved-det-alle -metoden bedre."

Anna, vores implementeringskonsulent, som har engelsk som modersmål, tjekker alle engelske tekster, før de går online, og anvender også konversationsmetoden . For bare et par uger siden rettede hun selv grammatiske fejl. Nu henviser hun oftere til vores Style Guide, så folk selv kan rette det. "Og når nogen skifter tid hele tiden, spørger jeg dem bare, hvilken tid der skal bruges."

Det tager længere tid, men det betaler sig i sidste ende .

Jo mere du selv behandler feedback, jo bedre bliver du, og jo mindre tid tager det at levere den rigtige kvalitet næste gang.

Denne sidste metode til peer review tager meget tid, især i begyndelsen. Det er nok en af grundene til, at vi nogle gange falder tilbage i vores gamle, komfortable vaner. Men vi siger til os selv igen og igen: Jo mere feedbacken får dig til at tænke, og jo mere du selv bearbejder den, jo bedre bliver du til dit job. Så vil det tage mindre tid at levere den rigtige kvalitet næste gang. Fordelene er dobbelte. I sidste ende vil det også tage anmelderen mindre tid at anmelde. Selv da er det vigtigt at fortsætte med at være kritisk og give værdifuld feedback, fordi det hjælper:

• Involver dine kolleger i dit daglige arbejde. Der er ingen isolerede arbejdsøer. 

• Øget tillid til det arbejde, du skaber, fordi en anden synes, det er værd at se på.

• Forbedring af arbejdets kvalitet. Det er en langsigtet investering, der forhindrer (dyre) fejltagelser. 

Denne artikel blev gennemgået på den dialogiske måde?