Gör rätt med kravhantering från början - Vem gör Vad och Varför?

2011-05-13 Artikelbanken Kravhantering Läst 16159 gånger

Som utbildare och konsult kommer jag varje år i kontakt med 100-tals organisationer som strävar efter förbättrad kravhantering. Bland alla varianter av utmaningar ser jag en återkommande röd tråd gällande de huvudproblem som finns i Sverige idag. Det handlar ofta om lösningsfokus för tidigt i projektet. Det handlar om att hitta rätt nivå för kravställning och dokumentation. Det handlar om svårighet med roller och ansvar (vem som ska göra vad och när?). Jag vet att många av er känner igen er i den här problematiken. Därför har jag skrivit denna artikel för att dela med mig av lite tips för att hjälpa er på traven att lösa era problem. För att illustrera mina tankar utgår jag från ett tänkt scenario som utspelar sig på en ganska vanlig arbetsplats någonstans i Sverige.

”Ett mellanstort svensk företag har beslutat att bygga ett digitalt arkiveringssystem för att lagra avslutade projekt. Beställaren av projektet heter Margareta Eriksson och är en medelålders kvinna som började sin karriär som systemutvecklare men numer har hon ett mer övergripande verksamhetsansvar där hon även agerar produktägare för vissa av företagets produkter.

Företagets nuvarande arkivering är helt manuell och består av utskrifter av alla projektdokument som sätts i pärmar och radas upp i arkivrummet hos respektive lokala kontor. Processen är mycket tidskrävande, mycket papper går åt och personalen klagar ofta på att deras kompetens inte kommer till användning på grund av allt administrativt arbete. Dessutom innebär pappersarkivet att informationen är låst till respektive kontor vilket gör att man antingen själv måste ta sig till staden där arkivet finns eller be någon medarbetare på plats att scanna och mejla informationen.

Det nya arkiveringssystemet skulle bidra till att lagringshantering skulle gå snabbare, det vill säga ta mindre tid i anspråk av medarbetarna och skulle definitivt vara en god gärning ur miljösynpunkt i och med att utskrifterna försvann från rutinen. Vid övergången till ett digitalt arkiv skulle även projektinformationen bli sökbar och tillgänglig för fler människor på ett helt annat sätt än tidigare.

Margareta bestämmer sig för att beställa systemet och går därför till företagets interna krav- och projektledare Carina Karlsson för att framföra sitt ärende: Vi behöver ett system för att lagra projekt på två servrar, en server för lagring i 3 år och en för lagring i 10 år. Jag vill att du startar upp detta projekt snarast möjligt.

- Absolut, svarar Carina. Som första steg skulle jag vilja prata med alla intressenter till projektet för att få tillräckligt med information för att kunna bilda mig en bättre uppfattning vilka behov som finns. Allt för många gånger har grundläggande behov och krav tillkommit från olika intressenter under projektets gång som i slutänden lett till förseningar.

- Men jag berättade ju mina behov, kontrar beställaren. Om du absolut behöver mer information kan jag tillägga att jag vill att systemet ska bestå av en webbapplikation som är byggd på .NET 4.0, flyttning av filer görs av en tjänsteapplikation och lagring av data sker till en SQL-databas.

- Jag förstår, svarar Carina. Jag ser till att vi arbetar fram ett förslag som du sedan får godkänna.

- Jag litar på dig Carina, du brukar göra ett bra jobb. Jag vill att du koncentrerar dig på att leverera systemet inom en snar framtid så att det kan tas i bruk till hösten. Under arbetets gång kan jag själv höra mig för kring projektets status när behovet uppstår.”

Om vi nu backar tillbaka och tittar på scenariot ur ett kravhanteringsperspektiv så finns några punkter som både Margareta och Carina kan tänka på för att förbättra kravarbetet:

1. Tänk behov istället för lösning i början av kravarbetet

Vi börjar med att titta på händelsen ur Margaretas perspektiv. Med sin bakgrund som utvecklare har hon kunskap om hur en eventuell lösning skulle kunna se ut så behovet blir aldrig formellt uttalat utan hon kommer istället direkt fram till lösningen för att snabba upp kravarbetet: ”En applikation ska byggas som lagrar projekt på två olika servrar i 3 respektive 10 år ”.

De är inte bara de med utvecklarbakgrund som kan vara lösningsfokuserade, utan de flesta människor är det rent generellt. Ställs vi inför ett problem är vi ofta snabba på att hitta en lösning. I vissa fall kan det vara en bra egenskap men just ur ett kravperspektiv kan ett lösningsförslag som tagits fram för tidigt i processen göra mer skada än nytta. Faran med tidiga lösningsförslag är att det egentliga behovet riskerar att glömmas bort. Visserligen kanske lösningen som byggs motsvarar det framtagna förslaget men den kanske inte löser det ursprungliga behovet.

För att på ett enkelt sätt formulera de övergripande verksamhetskraven kan man använda sig av VVV-metoden (eller ”VVV-mallen” som vi på Konsultbolag1 också kallar den):

Vem?

Vad?

Varför?

VVV-metoden berättar vem intressenten är, vad intressenten vill (målet) och varför intressenten vill det (motivet bakom kravet). Om vi tillämpar VVV-metoden på kravet ovan kan det se ut på följande sätt:

Om vi ser situationen ur Carinas perspektiv så är hon helt införstådd med att behovet är viktigt. Hon känner sig inte riktigt nöjd med kravet som Margareta uttrycker det utan hon vill framför allt att behovet ska vara tydligare. Kravet som det ser ut just nu är för lösningsorienterat. Det ligger i hennes ansvar i rollen som kravledare att ifrågasätta om inte det bakomliggande behovet är tydligt. Hon föreslår att de ska gå ut på bred front och fånga in behoven från alla intressenter för att inte missa något.

När Carina tar upp behovsaspekten vill Margareta än en gång effektivisera processen genom att, istället för att svara på frågan, förtydliga genom att komma med fler detaljer. Kravet blir nu än mer fyllt av detaljer och restriktioner: ”Det ska vara en webbapplikation med .NET 4.0, en tjänst ska flytta filerna och data ska lagras i en SQL-databas”.

Att bli mer detaljerad i förhoppning om att kraven ska bli tydligare är oerhört vanligt och är något som kommer upp varje gång på mina kurser.

Vi använder detaljerna för att se vad som händer med kravet:

Tycker ni det blev tydligare? Vad som har hänt är att vi med mer detaljer har utökat Vad-kolumnen, dvs målet men behovet eller motivet bakom kravet har vi fortfarande inte fått fram. ”För att lagra projektdata ” är ett svar på varför vi vill bygga applikationen men inte ett svar till det bakomliggande behovet. Om man som leverantör skulle ha fått denna information skulle man naturligtvis använda den lösning och den teknik som står specificerad. Hur relevanta kraven och restriktionerna som beställaren kommer med här har vi ingen aning om. Det kan vara välgrundat eller bara första bästa lösning som Margareta kom på. Specialisterna på lösningen, dvs leverantörerna, får här inte komma till tals utan lösningen blir precis så bra, eller så dålig, som beställaren har förmåga att tänka ut. Självklart ska man så småningom detaljera sina krav och också komma med lösningsförslag men det kommer senare.

Den information som vi egentligen är ute efter hittar vi i inledningen. Behovet bestod egentligen av en ökning av personalens kompetensanvändande, effektivitet och informationsutbyte.

Det vi har gjort med VVV-metoden är att vi har använt ett kravdesignmönster som liknar en användarberättelse. Användarberättelser används ofta inom agila projekt och uttrycks då på följande sätt:

Som en [intressent] vill jag [mål] så att [motiv].


Som en beställare vill jag digitalisera arkiveringsprocessen för att öka personalens kompetensanvändande, effektivitet och informationsutbyte.


2. Beställaren ansvarar för behovet och leverantören för lösningen

I slutet av dialogen signalerar Carina att hon vill ta fram kravspecifikationen och lösningsförslaget med beställarens godkännande. Egentligen är det beställarens ansvar att ta fram behoven/verksamhetskraven och leverantörens ansvar att komma med ett förslag till lösning. Men många gånger klarar inte beställaren av att formalisera dess behov till krav utan lägger över det på leverantören. Detta är helt i sin ordning, men det är fortfarande beställaren som har ansvaret att det blir gjort och att se till att behoven har formaliserats på rätt sätt. Det betyder alltså i förlängningen att beställaren alltså måste ha en aktiv roll i kravhanteringen för att resultatet ska bli lyckat. Det räcker inte att, som Margareta föreslår, ”själv höra sig för kring projektets status när behovet uppstår”.


3. Bekräfta tolkningar av krav och lösningsförslag

När vi nu har fått fram behoven, formaliserat verksamhetskraven och kommit fram till ett lösningsförslag behöver beställaren bekräfta att våra tolkningar av kraven och lösningsförslag tillgodoser behoven. I detta exempel skulle det mycket väl ha kunnat gå flera månader mellan avstämningarna beroende på hur aktiv beställaren varit. I värsta fall kan vi råka ut för att vare sig kravspecifikation eller lösningsförslag är i linje med vad beställaren tänkt sig och många timmar kan ha lagts ned på utveckling som sedan får göras om. Att påminna om kvitteringens betydelse verkar inte kunna göras för ofta.

Sammanfattning

Det finns mycket att tänka på när det gäller kravhantering men några av de viktigaste aspekterna att ta med sig är:

Tänk behov istället för lösning tidigt i projektet
Beställaren ansvarar för behovet och leverantören för lösningen
Bekräfta tolkningar av krav och lösningsförslag

Nästa steg

Konsultbolag1 erbjuder kursen Effektiv kravhantering där vi bland annat går igenom hela kravhanteringsprocessen från insamling till förvaltning. Vill du istället lära dig hur du praktiskt utvecklar och skriver krav för olika kravnivåer så erbjuder vi kursen Kravdesign – att utveckla och skriva bra krav. Dessutom har du möjlighet att certifiera dig inom kravhantering med hjälp av kursen REQB - certifierad kravhanterare.

 

För vidare läsning rekommenderar jag att du läser "Molnets" påverkan på krav- och testarbete, Smarta Scenarier - för en bättre IT-beställning och Personas - din bild av slutanvändaren.

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln