Ett stort problem vid kravinsamling är att väldigt många intressenter gärna pratar lösningar istället för att definiera problemen de har.
Ber man en intressent att säga vad de skulle vilja ha får man oftast svar som ”samma fast lite snabbare/lättare/bättre”. De utgår från den produkt de har idag och lägger gärna till lite funktionalitet. Av någon anledning är det väldigt svårt att se vad som bör förbättras när man ställer en positivt formulerad fråga. ”Säg vad som går att göra så säger jag om det är bra” är ganska vanligt att höra, trots att man idag kan lösa i stort sett vilket problem som helst.
Däremot är folk väldigt bra på att prata problem, om man bara ställer frågan på rätt sätt. Jag brukar därför vända på det och fråga ”Om man skulle göra ett så dåligt <system> som möjligt, hur skulle det se ut då?”. Av någon anledning sätter tankeprocesserna nästan alltid igång på högvarv hos intressenterna.
”Man skulle få vänta tio minuter på <rapport x>”
”Det skulle inte gå att hitta <funktion x> i menyerna”
”Det skulle inte gå att spara <information x>”
”Det skulle bli fel när man gjorde <uppgift x>”
Förslagen är nu plötsligt hur många som helst. Det är inte särskilt svårt att utifrån dessa svar se var förbättringspotentialen finns. Vilka funktioner man anser vara viktigast (de som skulle vara jobbiga om de inte fungerade), vilka delar som behöver gå snabbare, vilken information som inte får bli fel osv.
Hans Eckman (SunTrust Bank) använder en liknande approach som han kallar The three pains, där han ställer frågor för att ta reda på ”de tre saker som orsakar mest irritation”. Det kan vara frågor som ”Vilka tre uppgifter i ditt dagliga arbete skulle du vilja ändra på?” eller ”Vilka tre steg i process x skapar flest problem?”. Även här handlar fokus om att berätta om de problem man har, för att på så sätt hitta förbättringspotential.
Den här ”negativa” approachen har visat sig vara väldigt effektiv. Prova gärna i ditt nästa projekt, eller redan nästa gång du behöver ta reda på det verkliga problemet, oavsett situation.
/Staffan Melin, Require AB