Systemeffekter och krav – Varför fanns det ingen mjölk?

Häromdagen var jag inne i en mindre livsmedelsbutik för att handla lite. Det var en måndag runt lunchtid och mjölkdisken var helt ren sånär som på några få paket. Nåja jag fick i alla fall lite mjölk och nämnde det för kassörskan. Hon kunde inte dölja sin frustration över att mejeriet trots påtalande och försök att öka på beställningarna inte levererade tillräckligt mycket.

Det hela verkade bottna i ett smart beställningssystem som varje dag vid en viss tidpunkt stämde av saldot och därefter drog slutsatser kring hur butikens omsättning resten av helgen skulle se ut. Problemet är bara sa kassörskan att det är senare framåt fredag eftermiddag den riktiga veckoruschen kommer till den här butiken, dvs. man har en i allmänhet oproportionerligt stor omsättning under helgen vilket lösningen verkar ha svårt att kompensera för.

Det måste vara besvärligt för de enskilda affärerna att känna till behov men ha ett system som kör över intuition och kunskap kring de specifika förutsättningarna. I grund och botten handlar detta om ett intressentperspektiv där leverantören drar fördelarna på en mer övergripande nivå men där enskilda butiker kommer i kläm. Det vill säga för leverantören kan det här angreppssättet räknas hem men vissa av mejeriets kunder blir lidande och i slutändan påverkas jag som slutkund.

Så effekten blev att jag fick inte kunde köpa den mjölk jag ville ha samt att butiken och leverantören förlorade intäkten. Vem fick dessutom kommentarerna från kunderna, de som orsakade problematiken eller butiken?

Att förstå, identifiera och ta tillvara relevanta intressenters behov och lösningens konsekvenser i drift är ett mycket viktigt område där man i  många fall inte lägger nog med tid resurser. Med rätt perspektiv såsom det vi erbjuder inom UX-området kan risken för liknande systemeffekter minimeras.

Kravhantering – kontraproduktivt?

Kravhantering, så som den bedrivs i IT-projekt idag, är slöseri med tid och resurser. Med tanke på hur många, särskilt inom användbarhetsområdet, som arbetar med kravhantering är det förstås en provokativ tanke.

Kraven finns där för att det är en stor lucka mellan affärs- och verksamhetskonsulternas abstrakta rapporter och den faktiska systemimplementationen de ibland förordar. Så långt allt väl. Men vad är kraven egentligen bra för? Vad försöker de beskriva?

Jag hävdar bestämt att krav är en artefakt av ett alltför ingenjörsorienterat arbetssätt. Ett arbetssätt där man trots allt uppmärksammat att man på något sätt måste definiera och specificera vad det är som ska göras, visst. Problemet är att så fort kraven är formulerade glömmer man varenda ord om vad, varför och för vem. Du kan ha kartlagt och skrivit personas, definierat scenarios, vad som helst, men när kraven finns där är det dom som styr. Obevekligt. Och i 9 fall av 10 levereras ett system som uppfyller tillräckligt många av kraven för att leveransen ska vara godkänd men som inte går att använda och som inte fyller nån affärsnytta.

Pengar i sjön.

Och det värsta är inte att jag säger dethär utan att det faktiskt händer. Igen och igen och igen. Och beställarna svarar med att försöka bli bättre och bättre på att skriva krav. Blir det det?

Inte så vitt jag vet.

Snarare har kraven förvandlats från generella ”bilen ska vara bränslesnål” till specifika ”bränsleinsprutningen måste vara kalibrerad till 0,00001% marginal”. Kontraproduktivt.

Därför har jag börjat prata om att krav är föråldrat. Vill man verkligen uppnå affärsnytta kartlägger man behov och förväntningar och matchar dem mot verksamhetens strategier och visioner.

Detdär är ju inget nytt för de flesta av oss. Men nästan alla arbetar fortfarande med krav och kravhantering – det är till och med en särskild yrkesroll och i linjeverksamhet har man ofta kravhanterare anställda; först tar man fram behoven, målen och konceptet. Sen simsalabim gör man krav.

Och där någonstans tappar man bort hela nyttan med investeringen.

Som en konsekvens av detta provar jag just nu med att strunta i krav. Det enda (sic!) som behövs är ju egentligen att kartlägga, prioritera och balansera alla intressenters behov och förväntningar, inklusive affärsstrategierna och målen. Sen dokumenterar man det i koncept, design rationale, lösningsarkitektur och interaktionsdesign. Hur exakt man går till väga beror ju på om man implementerar standardsystem, om man gör en app till en padda, eller vad det nu är, men i grunden är det ju inga konstigheter.

Självklart måste man ha koll på informationsarkitektur och verksamhetsregler och en massa andra saker. Men så fort man gör krav av dem blir det de som styr, inte nyttan eller meningen med hela investeringen.

Och hela meningen med det vi gör är ju att det ska bli nytta, nytta och ändamålsenligt!

Krav – funktionella, ickefunktionella, och helt fel?

Jag kanske är helt korkad i huvudet, men trots att jag i över tio års tid plöjt systemspecifikationer fattar jag faktiskt inte vad det är för skillnad på funktionella och ickefunktionella krav.

Typexempel på funtionellt krav: ”Sökfunktionen ska klara av trunkerade sökningar”

Typexempel på ickefunktionellt krav: ”Det ska vara möjligt att nå sökfunktionen från alla delar av systemet”

Att sökfunktionen ska vara nåbar överallt är ett funktionellt krav, som jag ser det – det har att göra med hur funktionen ska ”funka’.
Trots det skulle ovanstående exempel kunna vara taget från i princip vilken kravspec som helst.

Inte konstigt att IT-bolag levererar kajko lösningar när det blir viktigare att tillgängliggöra en sökfunktion än att leverera nån typ av nytta.

Ett typiskt ickefunktionellt krav borde, enligt mitt sätt att se det, vara ett överordnat krav som säkerställer nyttan i systemet. Ett ickefunktionelt krav är ”användarna ska kunna hitta relevant material oavsett var de befinner sig på webbplatsen”. Eller ”webbplatsen ska minska behovet av telefonsupport med 1500 samtal om dygnet”.
Sedan drar man streck från dessa övergripande och målstyrande krav och till allt detdär som belamrar en normal kravspec men som borde vara en del av systemspecifikationen – beskrivning av hur man ska möta kraven.

*skakar på huvudet*

Men vad vet jag.

Det finns säkert nån bra anledning till att man gör sådär.

Fast andelen lyckade IT-projekt totalt sett får mej att tvivla…