För mig är det en stark drivkraft att förstå hur min insats har påverkat ett initiativ, såväl utifrån projektets framdrift som den slutliga lösningen. Med det som utgångspunkt försöker jag se hur jag kan förbättra mitt sätt att arbeta som kravanalytiker.
Nu är det över två år sedan jag senast skrev mitt senaste inlägg på kravbloggen. Sedan dess har jag varit fullt upptagen som kravanalytiker i ett större uppdrag. När jag började närma mig slutet kom jag att titta igenom mina gamla blogginlägg. Det fick mig att reflektera över hur väl hade jag själv hade lyckats att leva upp till budskapet i mina inlägg. Är det alltid så lätt att trots sin erfarenhet sätta upp förutsättningarna för sitt arbete enligt de principer som jag redogjort för?
Det här inlägget tänkte jag därför göra till en form av retrospective på min egen insats där utgångspunkten är mina tidigare inlägg!
Krav som beslutsunderlag var mitt första inlägg. För att kunna värdera en tilltänkt lösning och sätta rätt scope utifrån en given behovsställning samt estimera insatsen behöver man successivt bryta ner en kravställning. Allt ifrån att tydliggöra behovsställningen till att definiera högnivåkrav som sedan bryts ner i detaljkrav. För varje steg måste man bedöma om vi löser behovsställningen och estimera insatsen. Hela tanken är att i tid kunna ta ställning till om det är det mest relevanta man arbetar med och om det är nödvändigt utifrån affärsnyttan att gå vidare och realisera en tilltänkt lösning.
När jag kom in i projektet var förstudien klar och ramarna för projektet vara mer eller mindre satta. Ersätta ett befintligt systemstöd med ett nytt. Utgångspunkten var ett lagkrav som vart tvunget att uppfyllas så själva problemställningen var tydlig. Däremot var kraven på högnivå otydliga. Utöver de gamla funktionaliteterna skulle även ett antal nya utvecklas, that was it. Tiden för leverans var satt på ett år. Vad man hade missat i förstudien var dock att man ville förbättra existerande funktionaliteter utifrån nytt sätt att arbeta för att höja effektiviteten samt införa nya funktioner som baserade sig på helt nya processer.
Med andra ord skulle vi komma att basera kravställningen på vad jag brukar kalla omogna processer. Vi var helt enkelt tvungna att börja med att definiera processer och arbetsrutiner innan vi överhuvudtaget kunde påbörja själva kravställningen. Målbilden var således ambitiös men inte tillräckligt analyserad, vilket gjorde att den första fasen blev betydligt längre än vad initialt hade uppskattats. Hade man däremot i förstudien tagit höjd för att närmare definiera högnivåkrav och förstått hur de påverkade existerande processer, hade man med största sannolikhet haft en bättre bild av det fullständiga scoopet för projektet och därmed en bättre grund för estimering och prioritering.
Lärdom: Det är viktigt att kravanalytiker att komma tidigt in i ett initiativ för att bland annat förse projektet med input kring förutsättningarna kring kravarbetet. Att redan i förstudien skapa en förståelse för hur nya processer påverkar upplägget av kravarbetet och önskade bryta ner frågeställningar / behov till högnivåkrav för att närmare förstå omfattningen och komplexiteten. Utan att göra detta är det svårt att förutse och estimera arbetsinsatsen.
Mitt andra inlägg kallade jag Dags att överge begreppet ”överlämning” i kravarbetet. Ett krav är aldrig ”klart” förrän de är omsatta i en lösning är mitt enkla budskap. Bakom varje krav finns ett syfte som går tillbaka till verksamhetsbehovet och skall komma till uttryck i lösningen. Som kravare är det av stor betydelse att säkerställa att detta syfte förverkligas. Mitt budskap var att ”Överlämning” lätt kan komma att ses som ett sätt att överlämna ansvaret för en kravmassa. Jag hävdar att en kravanalytiker måste involvera sig i lösningsdiskussionen och visa att man är intresserad hur en tilltänkt lösning ser ut och försäkra sig om att just syftet förverkligas.
I det aktuella projektet så var det första gången de tog hjälp av en Business Analyst. Vanligtvis hade utvecklarna själva tillsammans med projektledaren ansvarat för att ta fram en kravställning. Mao hade de själva till stora delar haft ansvarat för både krav och design.
Inledningsvis skulle jag som kravanalytiker endast presentera kraven för utvecklarna som sedan skulle ta vid och ta fram en lösning. ”De vet vad skall göra” var utgångspunkten. Det visade sig att det inte alltid var lätt att förstå kraven, särskilt de som berörde förändringarna av de existerande funktionaliteterna som de själva en gång varit med och byggt. Två konsekvenser uppkom på grund av detta. Dels kom lösningen inte att uppfylla de bakomliggande syftena dels fick jag som kravanalytiker inte tillräcklig återkoppling på begränsningar som hade påverkan på kraven.
Därför introducerade vi workshops där vi gick igenom lösningsdesignen. Nu fick vi en bra förståelse för hur kraven skulle implementeras och därmed möjlighet att värdera hur lösningen slutligen skulle stödja verksamheten. Missförstånd kunde redas ut och kraven kunde vid behov kompletteras eller ändras. Även test kom att delta vilket gjorde att deras förståelse och möjlighet till förberedelse förbättrades. Detta ledde till att vi fick en bättre transparens i projektet och förståelsen för kraven och lösningsförslagen ökade.
Lärdom: Krav och lösning måste samverka hela projektet igenom för att säkerställa att rätt lösning tas fram. Som kravanalytiker måste man involvera sig i och förstå lösningsförslagen för förstå hur den slutligen kommer att stödja verksamhetsbehovet.
Att skapa samsyn med hjälp av processer: Vår uppgift som kravanalytiker är enkelt uttryckt att få fram kraven. För att ett stödsystem skall nå sitt syfte att stödja en verksamhetsprocess så måste vi förstå hur processerna i verksamheten fungerar eller behöver förändras. Att kartlägga processerna och ha dessa som grund för kravställningen skapar samsyn bland involverade kring vad som måste göras och underlättar definitionen och prioriteringen av kraven.
Som tidigare nämnts skulle projektet ersätta ett befintligt stödsystem med målet att introducera ny funktionalitet och förbättra existerande. För den nya funktionaliteten fanns inga processer utan vi började med i princip bara en one-liner; ”Jag vill kunna simulera för att säkerställa resultatet av en konfigurering”. Omogna processer kräver ett helt annat tillvägagångssätt. Vi blev helt enkelt tvungna att börja definiera de processer och rutiner som behövdes först för att överhuvudtaget kunna kravställa en tilltänkt lösning.
Detta hade inte beaktats och behovet av att definiera processerna hade således inte kommit att estimerats, vilket självklart påverkade tidsplanen för projektet. För att vinna tid kom jag att arbeta mycket tidigt i projektet med UX för att med hjälp av wireframes kunde modulera fram ett användarflöde. Genom att kontinuerligt presentera ett underlag gav vi beställarna något påtagligt för dem att utvärdera och komma med förbättringar. Tillvägagångssättet är inte optimalt snarare bakvänt men det gav en look and feel som gjorde att vi kunde bryta mark och ta oss framåt.
Lärdom: Jag kommer här tillbaks till min första lärdom ovan. Hade analysen gjorts i förstudien hade man fått en bättre förståelse för behovet att fokusera på verksamhetsprocesserna först för att sedan påbörja kravarbetet. Vi gick för fort in i utveckling.
I inlägget Sättet för hur kravarbetet bedrivs måste få mogna fram ville jag peka på behovet av att iterera fram ett arbetssätt. Arbetet med att omsätta behov till en fungerande lösningen kräver många olika rollers involvering. Allt från beställare, utvecklare till testare. Vi har olika infallsvinklar, erfarenheter och driv. Att sätta en mogen process från början är alltid svårt. Men med ett medvetet fokus på att ständigt förbättra arbetssätt och samverkan i initiativen växer man tillsammans. Att iterativt arbeta fram en gemensam arbetsprocess skapar en stabil grund för att bli bättre på att leverera enligt önskemål och tid.
Att introducera kravarbete i en organisation som tidigare aldrig har arbetat med en kravanalytiker ställde saker på sin spets. I det här projektet var rollen begränsad inledningsvis till endast att ”skriva” kraven. Detta ledde till felsteg i form av att vi bl.a. inte lyckades inledningsvis ”kalibrera” kraven med lösningsförslagen och fick antingen backa på krav eller leva med inte alltid optimala lösningar. Först ett halvår in i projektet kom diskussionerna igång som gjorde att vi fick en bättre förståelse för projektets svårigheter och bristerna i samarbetet. Kravarbetet gick ifrån att vara bara en initial fas med att samla kraven och dokumentera till att bli en integrerad samarbetspartner med både utveckling och test.
Lärdom: Att bli effektiv i hur man levererar kräver en hel del fokus på arbetssätt. Vid uppstarten av ett nytt initiativ bör man ha en genomgång med projektmedlemmarna för att diskutera bästa tänkbara upplägg av arbetsformerna. Både för att möta projektets mål men även för att dra nytta av varandras kunskaper och erfarenheter på bästa möjliga sätt. Man bör även tidigt i projektet börja med retrospectives och inte vänta tills projektet har uppenbara problem.
Projektet bjöd på sina utmaningar i min roll som Business Analyst men jag trivdes oerhört och är tacksam för alla kunniga och engagerade människor jag fick träffa. Det är inte alltid lätt att ta sig an uppgiften enligt skolboken eller använda sig av sina erfarenheter fullt ut. Mao att leva som man lär är inte alltid så enkelt. Det viktiga är dock att man utifrån givna förutsättningar gör sitt yttersta för att påverka och förbättra i en riktning som gör att ett projekt levererar vad det är sagt att göra. Mao man måste kunna agera flexibelt.
Känner ni igen er i något av det som beskrivits eller vill bolla tankar och erfarenheter hör gärna av er med era reflektioner.
Daniel Burén, Knowit Require i Malmö