Inre och yttre kvalitet

Alla älskar kvalitet, särskilt “rätt kvalitet”, så att vi inte går till överdrift. Eller när det är riktigt illa åtminstone “känd kvalitet”. Perfektion är oändligt dyrt och kvalitet är gratis. Det är lätt att gå vilse bland klyschor och halvsanningar i kvalitetsvärlden.

Kvalitet är något subjektivt upplevt som ibland kan kvantifieras mer exakt och ibland inte. Eftersom vi alla har olika behov sätter vi olika värde på olika egenskaper hos de produkter och tjänster vi skapar, köper och använder.

En liten men viktig distinktion som är extremt värdefull när vi jobbar med mjukvara är den mellan inre och yttre kvalitet. Den distinktionen hjälper oss kommunicera bättre kring kvalitet.

Yttre kvalitet är sådant som har göra med sådant som är direkt synligt för den som använder sig av produkten eller tjänsten. Har den de funktioner som jag behöver? Är den tillräckligt snabb och säker?

Inre kvalitet handlar om hur det ser ut på insidan. Är lösningens komplexitet väl hanterad? Går det att förstå hur saker och ting sitter ihop och går det att jobba vidare med systemet, eller har vi designat in oss i ett hörn?

En isbergsmetafor passar bra här: den externa kvaliteten är ofta en liten topp som syns ovanför ytan. Under ytan finns inte sällan en oerhörd systemkomplexitet som inte med lätthet går att se för någon som inte arbetar med systemets insida.

Agila team behöver investera inte bara i sin lösnings yttre kvalitet, utan även i den inre. Självklart finns ett samband mellan dessa två typer av kvalitet: när den inre kvaliteten blir för låg blir även den yttre lidande. Enkla saker börjar ta lång att göra, eftersom komplexiteten på insidan är så hög. När det är riktigt illa blir vi till och med tvungna att konstatera att vissa saker helt enkelt inte går att göra med mindre än att vi gör en kostsam omskrivning av större eller mindre delar av lösningen.

Ett sätt att få bättre koll på styrningen av den inre kvaliteten är att skapa en explicit “klar-definition”: en beskrivning av vad vi anser ska gälla för att något vi gjort ska anses klart. En sådan klardefinition kommer självklart påminna oss om att testa att vi verkligen byggt rätt saker ur mottagarens perspektiv, men också påminna om allt det som behöver göras under ytan för att den inre kvaliteten ska vara på rätt nivå.

Ett annat sätt att få upp diskussionen om den inre kvaliteten på dagordningen är att inkludera de egna utvecklingsteamen som en nyckelintressent i de analyser vi gör, och helt enkelt fråga oss: vilka kvalitetsbehov har vi på kort och lång sikt?