Konsten att granska

Jag överdriver inte om jag säger att vi tillbringar minst en timme om dagen med att granska varandras arbeten. Varför så mycket? Svaret är tydligt. Genom kollegial granskning upprätthåller vi kvaliteten på våra produkter. Dessutom lär vi oss mycket av det som mottagare och granskare av feedback. Men att slutföra en granskning är ingen liten bedrift. Du måste på ett konstruktivt sätt kritisera dina kollegors arbete, som i vissa fall har krävt blod, svett och tårar. Hur gör du återkopplingen konstruktiv och tydlig? Vi diskuterar tre metoder för peer review, inklusive vår favorit. 

Lösningar, lösningar, lösningar 

För att optimera kvaliteten på ditt arbete behövs djupgående feedback. Ett sätt att göra peer review är vad jag kallar vet-allt-metoden. Du gör koden eller texten till din egen. Du har sett varje ord, varje mening, varje interpunktion eller varje sträng flera gånger och föreslår alternativ för delar som inte uppfyller kvalitetsstandarderna. Ibland åtföljs detta av en förklaring till varför du har ändrat det. 

Tidigare har jag använt den här metoden. Se hur jag ändrade inledningen som min kollega Jeroen skrev till sin artikel "Why we don't do overtime." 

Känner du igen det här: du är inne i ett projekt med en snäv deadline. Du jobbar extra för att hinna med. Efter några dagars övertid kommer du hem sent och trött, äter onyttigt och går direkt till sängs. Nästa morgon stiger du upp tidigt, fortfarande inte utvilad efter den korta natten. Ta dig samman.  Var stark och heroisk och klara den här deadlinen. Du lovar dig själv att nästa gång kommer att bli annorlunda. Att du ska planera bättre, göra de förbättringar du hoppade över den här gången. Du kommer att lämna kontoret i tid och äta med din familj eller ta en drink med dina vänner. Fast nästa gång är det ett annat viktigt projekt med en deadline. Och det upprepar sig.

_{Utkast till introduktion av artikeln "Why we don't do overtime", skriven av Jeroen.}

Jag föreslog att den skulle ändras till detta för att göra den mer tilltalande som inledning:

I de flesta jobb förväntas ofta övertid. Vi tror inte att övertid är lösningen för att få arbetet gjort och hålla deadlines. Om och om igen. Faktum är att vi tror att det är kontraproduktivt. Det är därför vi avslutar saker efter en åtta timmars dag, en vanlig arbetsdag i Nederländerna. 

_{Slutlig introduktion av artikeln "Why we don't do overtime", skriven av Jeroen.} 

Enligt min mening var Jeroens inledning för lång och bestod av information som upprepades i brödtexten. Jag ägnade en hel del tid åt att komma på en ny inledning, och Jeroen accepterade den. 

Om man ersätter sitt eget arbete med andras minskar känslan av att man äger det helt och hållet.

Vad var det som gick fel? Jag gav omedelbart lösningen. Den här metoden att granska är inte bättre än att bara be om godkännande. Som mottagare av feedback får du naturligtvis en glimt av orsaken till förändringen. Men genom att inte skriva om det själv missar du möjligheten att förbättra dina skrivfärdigheter. Dessutom minskar känslan av fullständigt ägande när man ersätter sitt eget arbete med andras. Det känns inte som ditt arbete längre. Dessutom kan osäkerheten öka, vilket kan leda till sämre kvalitet på det framtida arbetet. Kunna-allt-metoden kan också underlätta något helt annat: du tar feedbacken för given och är inte längre kritisk till den. Det är något vi inte heller vill, eftersom varje återkopplingspunkt också bör vara en möjlighet att lära sig något. Enligt vår mening är det viktigt att granska den feedback du får för att du ska kunna utvecklas som utvecklare eller skribent (front-end eller back-end). 

Snabbt och smutsigt 

I andra änden av spektrumet har du den snabba och smutsiga metoden. Den går ut på att du ber dina kollegor att godkänna det arbete du har gjort för att komma till nästa steg i processen. Egentligen vill du inte ha feedback. Du vill bara ha något online för att: 

1. Ni har utvecklat kodbiten tillsammans (pair programming). 

2. Det är en så liten förändring att inget kan gå fel. 

3. Du känner tidspress och kommentarer orsakar en försening.

4. Du har diskuterat lösningen med en kollega och implementerat den efteråt.

När det gäller skäl A och B är den snabba och smutsiga metoden tillåten. I vårt dagliga arbete gör vi det ganska ofta. Det är bara en del av vår process. Men detta gäller inte för skäl C, D och andra komplexa uppgifter. Här behövs faktiskt ett par extra ögon eftersom djävulen finns i detaljerna;

Möte i mitten 

De två nämnda peer review-metoderna är inte idealiska när det gäller lärande. Det är därför vår älskade metod hamnar någonstans mittemellan. Enligt vår mening är värdefull feedback från kollegor:  

• Är konstruktiv. Vi behandlar kollegor och deras arbete med respekt. 

• Får dig att tänka. Det hjälper dig att reflektera över ditt arbete och uppmuntrar dig att tänka på andra lösningar. 

• Består av frågor. Varför gjorde du på det här sättet? Vad är anledningen till den här inställningen? Tänkte du på alternativ X och Y istället för bara Z?

• Gör det möjligt för människor att bearbeta det själva. Det pekar dem i rätt riktning, utan att ge hela lösningen. Ibland är det dock mycket svårt att hålla tillbaka, särskilt när det gäller mindre misstag. Till exempel: obekvämt namngivna funktioner och variabler (kod) eller grammatiska misstag (innehåll). 

Vi ser feedback från kollegor som en konversationsstartare. Joan, en Back-End-utvecklare på Easy LMS, förklarar: "Jag avslöjar inte hela lösningen, ibland bara en del, men jag diskuterar främst hur ett alternativ kan uppnås genom refaktorisering. Och ibland innebär det att jag bokstavligen sitter bredvid någon för att gå igenom det, istället för att spela pingpong via GitHub eller BitBucket, de verktyg vi använder för kodgranskning."

"Det jag också gör ibland: Jag erbjuder flera alternativ och låter mottagaren av feedbacken avgöra vilket alternativ som passar dem bäst. Det är en hjärngympa eftersom flera alternativ måste övervägas noggrant."

_{Exempel på en konversation om kodgranskning i GitHub.}

Enligt Joan är det inte alltid nödvändigt med konversationsfeedback. Det beror på vilken typ av kod det handlar om. "Anta att någon av misstag har lagt in en (säkerhets)sårbarhet i koden, då är det uppenbart att den måste tas bort. Naturligtvis kommer jag att förklara varför den ska tas bort och hur du kan undvika den från och med nu, men det är inte ett idealiskt tillfälle för en stor konversation. Då passar vet-allt -metoden bättre."

Anna, vår Implementation Consultant, som har engelska som modersmål, kontrollerar alla engelska texter innan de läggs ut på nätet och tillämpar även konversationsmetoden . För bara några veckor sedan rättade hon själv till grammatiska fel. Nu hänvisar hon oftare till vår Style Guide, så att folk kan fixa det själva. "Och när någon byter tempus hela tiden frågar jag bara vilket tempus som ska användas."

Tar mer tid, men det lönar sig så småningom 

Ju mer du själv bearbetar feedback, desto bättre blir du, och desto mindre tid tar det att leverera rätt kvalitet nästa gång.

Den här sista metoden för peer review tar mycket tid, särskilt i början. Det är förmodligen ett av skälen till att vi ibland faller tillbaka i våra gamla, bekväma vanor. Men vi säger till oss själva om och om igen: ju mer feedbacken får dig att tänka till och ju mer du bearbetar den själv, desto bättre blir du på ditt jobb. Då kommer det att ta mindre tid att leverera rätt kvalitet nästa gång. Fördelarna är tvåfaldiga. I slutändan kommer det också att ta mindre tid för granskaren att granska. Även då är det viktigt att fortsätta vara kritisk och att ge värdefull feedback eftersom det hjälper till:

• Involvera dina kollegor i ditt dagliga arbete. Det finns inga isolerade öar av arbete. 

• Ökat förtroende för det arbete som du skapar eftersom någon annan tycker att det är värt att titta på.

• Förbättrad kvalitet på arbetet. Det är en långsiktig investering som förhindrar (kostsamma) misstag. 

Denna artikel granskades i konversationssättet?