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.