Hur vet du att AI faktiskt hjälper? Mät det.
Fråga vilket mjukvaruföretag som helst om AI har gjort deras utvecklare mer produktiva, så svarar de flesta ja. Men fråga hur de vet det, och svaret är ofta en känsla, inte något mätbart – oavsett vilken siffra de anger: trettio procent, femtio procent eller dubbelt så produktiva.
Ofta saknas både en utgångspunkt att jämföra med och en metod för att avgöra vad som faktiskt är en förbättring och vad som snarare är önsketänkande.
Vi har utvecklat mjukvara åt våra kunder i mer än tjugo år. När AI började förändra vårt sätt att arbeta bestämde vi oss tidigt för att vi ville kunna mäta effekten – inte bara utgå från våra egna intryck. Så här gör vi i praktiken.
“”AI är ett verktyg. Man skyller inte på hammaren. Det är som en avancerad maskin – först lär du dig att använda den, sedan gör den jobbet.””
En avancerad maskin som du lär dig att använda är också en maskin vars resultat går att mäta. Så här arbetar vi med mätning idag – och tar med oss det vi lärt oss på vägen.
Det här följer vi upp
Våra mätningar börjar som vanligt med estimat. Varje deluppgift estimeras innan arbetet påbörjas och per komponent, så att insatsen inom varje område kan följas separat.
Tiden följs upp för varje uppgift och avvikelser tas upp vid teamets uppföljning med en enkel fråga: Varför tog det här två dagar när vår uppskattning var en timme?
Utöver detta följer vi sådant som estimaten i sig inte kan fånga:
Antal buggar per version
Buggar som upptäcks vid acceptanstest jämfört med efter release
Hur många problem som upptäcks vid användaracceptanstest (UAT) innan en release godkänns
Testtäckning
Den totala tiden från uppstart till driftsättning
Inget av detta är några ovanliga mätetal – och det är själva poängen. Att mäta effekten av AI kräver inte att vi uppfinner nya sätt att mäta. Det handlar om att ta de mätetal vi redan har på allvar, eftersom AI förändrar både var tiden läggs och var felen uppstår.
AI-regler som hela teamet kan se
Ett nyare arbetssätt är att behandla själva AI-konfigurationen som kod. Varje team arbetar med ett AI-ramverk: instruktioner, agenter och kvalitetskontroller som styr hur AI används i projektet.
En kvalitetskontroll kan vara så enkel som att kontrollera antalet tecken i AI-genererad text, eller så viktig som att kräva att varje teknikval som AI föreslår genomgår en arkitekturgranskning innan det får bli en del av lösningen.
Den typen av regler är skillnaden mellan resultat du kan lita på och resultat som hela tiden måste kontrolleras.
Varje team sparar sitt AI-ramverk i Git, versionshanterat tillsammans med projektet. Där kan det granskas, jämföras och förbättras i stället för att bara finnas i någons huvud.
Versionshistoriken ger oss samtidigt en tydlig signal. Ett AI-ramverk som måste korrigeras varje dag fungerar ännu inte som det ska. När det har stabiliserats vet vi att det gör sitt jobb.
Vad vi lärde oss på vägen
Vi trodde att utmaningen skulle vara att ta fram själva metoden. Men det var det inte. Mätetalen var den enkla delen och vi behövde inte uppfinna något nytt.
Den verkliga utmaningen var att göra individuella arbetssätt synliga och dela dem med resten av teamet.
I ett projekt behövde AI-ramverket justeras nästan varje dag under de första veckorna. När vi följde upp teamet hittade vi orsaken: två utvecklare granskade AI-genererad kod på olika sätt, men inget av arbetssätten hade dokumenterats.
När teamet lade in båda arbetssätten som instruktioner i AI-ramverket upphörde de dagliga korrigeringarna inom två veckor. Utmaningen var inte att skriva instruktionerna, utan att göra ett individuellt arbetssätt synligt för resten av teamet.
Att mäta är det enda sättet att skilja mellan att faktiskt använda AI och att bara tro att det fungerar
Om ni inte mäter något idag är första steget inte att bygga en dashboard. Börja i stället med att dokumentera arbetet medan det pågår: estimatet innan uppgiften påbörjas och den faktiska tiden när den är klar.
Det går inte att i efterhand förstå vad som gick fel om ingenting dokumenterades medan arbetet pågick.
