Kravställning i vardagen

Att kravställning är svårt vet nog alla vid det här laget. Fler och fler företag inser fördelarna med så kallade “one liners”; men dessa fungerar inte om inte teamet och beställaren är redo för det.

I helgen var jag på MAXI för att handla matvaror till en middag med vänner. Jag hade fått en inköpslista där det stod vad jag skulle köpa så detta skulle bli enkelt.

När jag står i mjölkkylen framför crème fraîchen poppar en fråga upp, light eller vanlig?
Det slog mig då att situationen hade paralleller till systemutveckling där den här sortens små frågor är precis vad systemutvecklare brottas med varje dag.

Jag fortsatte att leka med tanken. Jag hade ju en backlog (inköpslistan), en utvecklare (jag) och en produktägare (Amanda; som skulle laga maten). Min uppgift var att implementera (dvs hitta och köpa) det som fanns på listan och leverera till produktägaren.
Det låter ju som en ganska enkel uppgift eller hur?

Om vi går tillbaks till listan så har jag bl a smör och crème fraîche på den.
Skall jag köpa smör till smörgås eller smör att baka med? Skall jag köpa vanlig eller light crème fraîche? Det stod heller inget om mjöl eller mjölk på listan, behövs inte det?

Jag löste dessa frågor genom att använda tre olika tekniker.

Smör – Jag visste att vi skulle göra en paj samt baka lussekatter så med stor sannolikhet var det smör att baka med som hon var ute efter. Att jag kunde välja rätt här berodde på att jag hade domänkunskap och jag visste det bakomliggande behovet.

Crème fraîche – Här kunde jag direkt välja den vanliga. Detta eftersom jag mindes att Amanda en gång sagt ”Light är för tjockisar” och genom det så visste jag vad hon ville ha.
Här använde jag mig av det faktum att jag känner produktägaren och jag kunde därför applicera den kunskapen till att välja rätt.

Hur var det då med mjölet och mjölken? Här använde jag mig av simpel kommunikation. Jag skickade helt enkelt ett meddelande och frågade. Fick då svar att det fanns redan hemma.

Så när ni jobbar med systemutveckling och utvecklingsteam så tänk på detta. Det gäller att ha ett team med domänkunskap och de måste förstå vad det är dom utvecklar och varför.
Se också till att alla i teamet trivs så att de stannar och får den personliga kontakten med produktägaren som gör att de vågar ställa frågor och kan ta de små besluten som kanske inte verkar så betydelsefulla men som i längden leder till en nöjdare produktägare och en bättre slutprodukt.

Om författaren
Magnus Carlsson är konsult på Inceptive. Han har verkat i IT-branchen sedan 1998 och som konsult sedan 2006.
Hans huvudsakliga expertis är inom Agil systemutveckling/testledning.

Comments

[Torbjörn Andersson]

Exemplet och situationen som Magnus beskriver verkar ganska självklart, eller hur? Så då undrar man varför det ändå är problematiskt i de flesta projekt?

Som jag ser det så finns det flera stora skillnader mellan vardags exemplet och många IT projekt.

I exemplet så utspelar det hela sig i ett ganska kompakt område, att baka en paj. Alla inblandade har någon gång själva bakat en paj, ätit paj och är familjära med ingredienserna. Om man skulle jämföra med hur det ofta ser ut i ett IT projekt så skulle det vara ungefär så här:

Beställaren har hört talas om paj och vill ha en men är helt omedveten om hur en sådan blir till och har heller ingen som helst aning om vad den består av (saknar helt kännedom om ingredienser(design lösningar dvs light eller ej)). Bagaren(utvecklaren) vet hur man bakar en paj men har aldrig ätit en och vet inte vad köparen skall ha den till.

I detta läget så händer det att Bagaren blir så osäker på om det kommer att bli rätt eller ej pga valen mellan margaring, smör, bregott, light eller ej etc. Vilket egentligen kanske inte påverkar så mycket om det blir en bra paj eller ej. Det kan variera något i smak etc pga dessa val men resulterar förmodligen i en tillräckligt bra paj i vilket fall som helst.

Då ställer bagaren alla dessa frågor till beställaren som blir tvungen att sätta sig in i vad det betyder och förstår inte heller att dennas svar på dessa frågor nu har blivit krav på designen vilket bagaren naturligvis vet bäst själv egentligen.

Bagaren har lämnat över ansvaret för resultatet till beställaren!

Så jag håller med Magnus om att kravingenjörer och utvecklare mm bör anstränga sig att förstå kundens behov men de bör också ta ansvar för resultatet istället för att bolla design frågor(smör vs margarin etc) till beställaren/kunden.