Det är viktigare att göra rätt än att vara fri från fel

Användarna av våra program och webbplatser hatar dem ofta djupt och innerligt. Är inte det rätt tragiskt?

Kvalitet inom mjukvara framstår för mig som för snävt definierat. När man vanligtvis talar om mjukvarukvalitet menar man oftast “frihet från fel”. Sålunda går alla kvalitetsinsatser ut på att försöka få bort felen. Nå! Det är naturligtvis inget större fel med att försöka vara felfri, men tänk om det sker på bekostnad av något viktigare?

Låt oss utgå ifrån ett vardagligt exempel: Antag att din tvättmaskin går sönder och att du beställer hem en ny. Vad är viktigast för dig när du får hem den till dina smutsiga klädhögar? Är det att det inte finns ett fel i timerfunktionen eller att den tvättar, tumlar och sköljer kläder? Visst vore det irriterande om timern visade fel antal minuter kvar, men viktigast är ändå att vi med hjälp av tvättmaskinen kan uppnå det som vi förväntar oss: rena kläder på ett bekvämt och energisnålt sätt. Tvättmaskinen är bara ett redskap för oss att uppnå våra mål med användningen.

Det här känns säkert självklart, men när det handlar om skräddarsydd mjukvara blir det allt annat än självklart. Skillnaden ligger i den fullständiga friheten i utformningen av produktens egenskaper som finns inom mjukvara. När vi själva kan bestämma exakt vad en produkt ska klara av måste varenda funktion, varenda svarstid, varenda pixel hos produkten vägas på guldvåg. Med friheten att segla båten vartåt vi önskar följer komplexiteten att välja rätt kurs ur ett oändligt hav av möjligheter. Då blir det här med att kunna nå sina mål med användningen plötsligt ett verkligt problem. Vad vill vi egentligen? Och hur kommer vi dit?

Det är här som den traditionella definitionen av mjukvarukvalitet bryter samman. Vad spelar det för roll att vi inte har så många kritiska fel om vi inte löser rätt problem? Inte ett smack! Dagens definition av kvalitet leder oss till att fokusera helt på att utveckla med minimalt antal fel i stället för att utveckla rätt saker. Jag menar alltså att den viktigaste formen av kvalitet inte är frihet från fel utan närvaron av rätt.

Ett grundläggande mått på kvalitet borde vara i vilken mån produkten kan användas för att klara av de uppgifter som användaren ställs inför, det som ibland brukar benämnas användningskvalitet. Notera att detta är ett vidare begrepp än det mer vanliga “användbarhet”. En produkt kan vara hur användbar som helst, men om den inte gör det som jag vill är den inte nyttig och har låg användningskvalitet för mig.

Det är till och med viktigare att en produkt innehåller rätt funktion på ett inte helt perfekt sätt än att en felaktig funktion är helt perfekt. Låt oss analysera detta påstående lite grann. I första fallet kan vi åtminstone få ut någon nytta, även om den ännu inte är maximal; i andra fallet är nyttan noll, produkten är oanvändbar för att lösa vårt problem. En kanske viktigare fördel är att vi, i det första fallet, har chansen att förbättra och rätta funktionen så att den även utförs korrekt. Med iterativa förbättringar kan vi, givet tid och kraft, uppnå både rätt funktion och funktionen rätt. I andra fallet har vi slängt pengar i sjön på att utveckla en felfri funktion som få eller ingen kan använda till något värdefullt.

En tanke som kommer som ett brev på posten är att personer som främst definierar sin roll som kvalitetens förkämpar, till exempel testare av mjukvara, borde byta fokus. I stället för att satsa all sin tid på att “säkra kvaliteten” (= påtala fel), borde de lägga merparten av sin tid på att se till att vi utvecklar rätt saker. Därefter borde merparten av den återstående tiden läggas på att stötta utvecklarna att inte göra fel från första början. Det som är kvar efter detta kan ägnas åt efterverifierande aktiviteter, alltså det som idag benämns “testning”.

Den här trenden har också redan inletts. Allt mer ser vi automatisering av exempel på rätt funktioner innan de utvecklas som i ett senare skede används för regressionstestning, det vill säga en sammansmältning av det som traditionellt kallas “krav” och det som kallas “test”. Jag tror att den här trenden kommer att fortsätta och jag skulle vilja att den gick ännu längre: Att alla som arbetar inom mjukvaruutveckling ständigt hade fokus på användarna och vad de försöker uppnå. Utan att förstå våra kunder (dvs användarna, oavsett vem som betalar) kan vi aldrig systematiskt få till rätt lösningar och därmed inte heller en hög användningskvalitet. Och de kommer att fortsätta att hata våra alster.

5 thoughts on “Det är viktigare att göra rätt än att vara fri från fel

  1. Bra poänger men det alla inblandade i mjukvaruprojekt måste tänka på är att man kanske inte ska göra de där features som man inte sedan har/kan/vill kvalitetssäkra. Tja, en timer som funkar dåligt kanske inte gör att tvättmaskinen inte kan räknas som funktionell men då den finns där räknar man med att den fungerar. Ta exemplet att man ska iväg på en semester och vill tvätta innan man åker. Timern anger att man har tid att slutföra tvätten innan man behöver ge sig av. Men timern visar fel och man får välja mellan att hänga blöt, osköljd tvätt som kanske förstörs av detta eller låta tvätten gå klart och missa flyget. Eller låta tvätten tvättas klart och ligga och ruttna i maskinen som då även står på under resan.

    Jag irriterar mig väldigt mycket på Lotus Notes för alla dessa halvtrasiga funktioner som finns. Jag skulle hellre ha ett system med en tiondel av funktionerna men om dessa funkade.

    Ett annat problem med dessa små brister är givetvis att man förlorar förtroendet för dem. Hur ska jag kunna lita på en mjukvara där man inte ens klarar av dessa småfunktioner?

    Ergo: när en ny brilliant idé kommer till verkstan, glöm inte att få accept på att det ska sedan kunna testas, underhållas och fungera.

    • Hej Anna! Tack för din reflektion! Jag håller helt med om att “featuritis” är en vanlig och farlig åkomma. Det jag menar är att vågen som vi väger funktionerna på bör byggas utav affärsnytta genom användning, vilket bör reducera denna sjukdom till ett minimum.

  2. TJena Jocke! Tack för artikeln. Russell Ackoff brukade säga: “the righter you do the wrong thing, the wronger you become”. Om jag skulle parafrasera skulle jag säga: ju snabbare du springer åt fel håll, desto snabbare blir du mer vilse.

    • Tack Tobias! Och Russell hade helt rätt i det. 🙂

      Jag tror inte problemet är att folk inte inser detta. Jag tror att de flesta håller med om det om man säger det till dem. Men vi måste fortsätta att säga det för det glöms ständigt bort.

  3. Du har helt rätt Jocke! Det är viktigare att lösa rätt problem. Min teori om varför kvalitetsarbetet så ofta fokuserar på att eliminera fel är att detta är mycket enklare. Det är ibland lite svårt att testa om en given funktion leverar rätt resultat, särkskilt om det finns många olika testfall. Men att ta reda på vad ett företag egentligen behöver för stöd är ofta mycket svårt. Resultatet blir att vi gör som vanligt: Vi letar efter nycklarna under lyktstoplen – för där ser vi bättre!

Comments are closed.