« Hem

Det svåra med kravhantering

Jag har ju tidigare skrivit om att det är jäkligt svårt att tidsuppskatta arbetsuppgifter när det gäller IT, och ytterligare ett problem som relaterar till detta är att hantera de krav som finns på den lösning som ska byggas. Till skillnad från  tidsuppskattningen är det här något som faktiskt tas upp i informatikutbildningen, så har du läst systemvetenskapliga programmet är du antagligen medveten om problematiken.

dilbertProblematiken simuleras i åtminstone en kurs där lärare agerar ”kunder” som plötsligt ändrar sig under ett projekt, och jag minns att många studenter blev irriterade på detta. I skolan är man inte van att nya saker dyker upp mitt under ett projekt, allt brukar (och ska enligt regler kring betygssättning) vara specificerat från början, så studenten vet exakt vad som förväntas. I yrkeslivet är läget dock ett annat, vilket lärarna i informatik gör sitt bästa för att förbereda studenterna på.

Jag tycker att de gör ett bra jobb med detta, men det är ändå otroligt stor skillnad att vara med om det i verkligheten. Problemet med att nya krav dyker upp från kunden är dock inte så stort för mig, eftersom jag mest jobbar med mindre, ganska avgränsade uppgifter som redan definierats. Det största bekymret för mig är snarare att förstå de krav som redan finns. För det mesta går processen till såhär:

  1. Jag får en uppgift, ofta specificerad via mail
  2. Jag tänker: jag fattar. Det här fixar jag direkt.
  3. Jag startar Visual Studio, BizTalk eller vad det nu kan vara för programvara som krävs
  4. Och tänker: men vänta här nu. Vad exakt är det som ska hända här egentligen?

Det som verkar så lättfattligt i mailet blir plötsligt betydligt mer oklart när jag ska börja skriva koden, och jag måste ofta gå tillbaks och ställa mer frågor för att kunna lösa uppgiften. Ju mer detaljer jag grottar ner mig i, desto fler blir frågetecknen och ofta visar sig uppgiften vara betydligt större och mer komplicerad än jag trott från början.

Varför är detta så svårt egentligen?

Jag har en teori och det är att IT är så otroligt abstrakt, både för den som ska använda lösningen, men också för den som ska programmera, innan denne har verkligen börjat koda. Ska man bygga en bro är det betydligt enklare: vi ska från punkt A till punkt B och eventuella problem längs vägen är betydligt lättare att förutse. Alla kan direkt se att en promenadbro över en liten bäck kommer vara betydligt enklare än en bro för biltrafik över en stor älv.

1tower-bridge

I IT är det inte lika enkelt: det som från början kan se ut som en promenadbro visar sig vara en klaffbro över ett vattendrag med båttrafik när kraven börjar analyseras. Det som från utsidan, och kanske främst från en användares sida, ser enkelt ut, är bara toppen på ett isberg av kod och komplexa beroenden, som ofta är svåra att förutse. Och framför allt: ingen skulle föreslå att man skulle bygga över Mälaren på ett par veckor, men inom IT händer det ständigt.

Jag har själv försökt mig på det – jag trodde att jag skulle kunna bygga en hemsida med ett eget CMS på några veckor, utan att inse de många timmar som ligger bakom ett administratörsgränssnitt som ex. WordPress. För att göra en lång historia kort: det gick inte alls. Det blev bara en hemsida och administratören fick administrera i HTML istället… Här har vi ett praktexempel på när en inte tillräckligt tydlig kravbild totalt pajar den tidsuppskattning som gjorts, och jag hade egentligen två val: öka tiden eller minska på kraven, och jag valde det senare.

Men, precis som med tidsuppskattning så går det att bli bättre på det här också! Ju mer man jobbar med en viss typ av lösningar, desto mer förförståelse får man för de olika delar som kan bli besvärliga, och man lär sig också att ställa mer och bättre frågor kring vad som ska göras. Man ser helt enkelt tydligare om det är en liten träbro eller en järnvägsbro som ska byggas, och kan anpassa jobbet därefter.

Nu har klockan slagit fem denna fredag, och jag lämnar er med den här klassiska bilden kring kravhantering. Det är möjligt att den är en sliten klyscha i sammanhanget, men den illustrerar ändå problematiken väldigt bra.

business-requirements-management

Trevlig helg på er!

Leave a Reply

Language: