På de flesta företag finns processer för hur kravarbetet ska utföras. Vad som ska göras, när och på vilket sätt. Ofta används en agil approach och ibland kombineras det med en projektstyrningsmodell. Som ”kravare” har man också ofta flera arbetssätt i sin verktygslåda. Allt från det klassiska upplägget med Elicitation, Analysis, Specification och Validation, till User Stories, Use Cases 2.0 och Volere. Det finns med andra ord gott om arbetssätt och metoder beskrivna, och som kravare vet man vad som är viktigt för att resultatet ska bli bra.
Det var bara det där med verkligheten.
I ett projekt är ofta tid en väldigt viktig faktor. När projektet drar igång ligger också ofta de som jobbar med lösning i startgroparna. Lösningen ska bygga på kraven, så det gäller att snabbt leverera något som det går att börja utveckla från. Det rullar sedan på, och ofta fortsätter det i samma tempo. Då gäller det att anpassa kravarbetet efter förutsättningarna.
När verkligheten slår till blir man tvungen att prioritera. Vilka delar i kravarbetet är viktigast att leverera? ”Good enough” blir ledordet. Aktiviteter som tar längre tid eller är komplexa skjuts på framtiden. Det som händer är att man avviker från processer och metoder. Hoppar över delar. De där sakerna som man vet är viktiga för resultatet blir bortprioriterade. Spårbarhet, koppling till projektmål, motivering till varför de olika kraven behövs och formulering av icke-funktionella krav/kvalitetsattribut hamnar i skymundan.
Hur kommer det sig att det så ofta blir på det här sättet? Processer och metoder finns för att hjälpa oss och säkerställa att arbetet blir bra genomfört, men ändå avviker vi från dem. I verklighetens projekt finns helt enkelt inte tiden för det. Skulle det hjälpa att planera projekten annorlunda? Kanske, men det är inte säkert att det skulle gagna projekten om det i slutändan resulterar i en återgång till en mer vattenfallsbaserad approach. Och tid kostar pengar.
Är det kanske så att det höga tempot skapas av att för få resurser arbetar med kraven? Med fler resurser finns möjligheten att leverera mer på samma tid, för att på det sättet säkerställa att alla viktiga delar i kravarbetet blir utförda. Men fler resurser kostar också mer pengar.
Kan det vara så att de metoder och processer vi förväntas använda egentligen innehåller för mycket? Går de att anpassa för att bättre motsvara de krav som verkligheten ställer? Självklart ska de vara anpassade efter de förutsättningar som finns. Men även med anpassade metoder och processer finns en tendens att steg hoppas över. Kan vi då vara säkra på att slutprodukten uppfyller behoven?
Hur kan vi då hantera denna verklighet? Bland det viktigaste bör vara att avsteg och genvägar faktiskt dokumenteras inom projektet. Det behöver inte vara någon omfattande dokumentation, men det behöver framgå vilka val som gjorts och varför. Genom att göra på det sättet blir det också transparent vilka val som görs och valen blir mycket mer medvetna.
Många projekt, speciellt inom IT, blir inte lyckade. Om avsteg dokumenterats ökar möjligheterna att förstå varför. Framförallt framgår det om förutsättningarna för projektet var det som skapade svårigheter. Orealistiska krav på tidplanen kan exempelvis ha orsakat projektets misslyckande, och inte projektet som sådant. Projektet kan ha varit väldigt lyckat – men tvingats till för många avsteg.
Transparens gällande avsteg och genvägar kan göra att nästa projekt hanteras annorlunda. Processer och metoder kan vidareutvecklas, resurser kan ses över och förutsättningar kan påverkas. Verkligheten behöver inte vara något problem, den behöver bara synliggöras.
