Inför en ny lagändring brukar det komma en första indikation cirka 1,5–2 år innan lagen träder i kraft. Därefter följer som regel en lång och utdragen beredningsprocess. ESMA, det organ inom EU som har ansvar att stärka investerarskyddet och främja stabila och korrekt fungerande finansmarknader, meddelar sedan inte sin slutversion förrän nio månader innan de ska träda i kraft. Under tiden kommer olika tolkningar och frågeställningar som gör det svårt att planera krav- och utvecklingsarbetet.
För att hinna med nödvändiga systemförändringar måste utvecklingsprojektet som regel påbörjas minst ett år i förväg. I ett så tidigt stadium, med den begränsade information som indikationerna ger, är det svårt att sätta rätt krav. För en större och traditionellt sett relativt trögrörlig IT-organisation, som det ser ut inom många banker och finansbolag, är detta en extra utmaning. Samtidigt ställs samma höga krav på den dagliga driften, som sköts av samma resurser som även behövs i utvecklingsprojekten.
Kort framförhållning och nya riktlinjer på vägen kan hanteras bättre agilt
Ett mer agilt förhållningssätt kan bidra till en effektivare utvecklingsprocess. Eftersom utvecklingen måste ske parallellt med att lagkraven formas kommer mycket av arbetet behöva baseras på vad man tror kommer att ändras. Det gör att du måste börja skriva krav, utveckla och testa på rimliga antaganden och den begränsade informationen som finns. Projekten blir därmed mycket dynamiska med många ändringar på vägen, vilket ställer höga krav på samarbetet i teamet. Framförhållningen är kort, vilket gör att det blir extra ont om tid för systemmässiga förändringarna. För vissa som är vana att arbeta mer traditionellt kan det agila arbetssättet ibland kännas osäkert och ovant, men många upplever det som ett roligare, mer utmanande och flexibelt sätt att arbeta.
Dra nytta av tidigare erfarenheter och gör en gemensam prioritetsbedömning
Utgå från den samlade erfarenhet som finns i teamen från tidigare, liknande projekt. Idag finns oftast tidigare versioner av de lagkrav som klubbas igenom, som till exempel för MIFID, EMIR och även AML, lagen om penningtvätt. Se till att dra nytta av lärdomar från förra gången, genom att se vad som eventuellt blev fel då och hur det hanterades.
För att skapa bästa förutsättningarna från början i utvecklingsprojektet är det viktigt att compliance, kravanalytiker, affärsledningen i ett tidigt skede gör en gemensam bedömning av vad som bör prioriteras. Börja med att kravställa utifrån de indikationer och förutsättning som verkar vara minst troligt att de förändras på vägen. Generellt brukar en 80/20-regel fungera bra, för att du ska behöva göra så få justeringar som möjligt.
I en allt snabbare och mer föränderlig värld – inte minst inom finansbranschen – blir det allt svårare att driva systemutvecklingsprojekt med en traditionell vattenfallsmetod. Allt högre krav ställs på nya flexibla arbetssätt och en mindre ”fyrkantig” inställning hos projektmedlemmarna. Med ett mer agilt krav- och testarbetet går det att skapa bättre dynamik i utvecklingsprocessen. Det lämnar även utrymme för att hantera en viss kalkylerad risk och förutsättningar som ändras på vägen.
Hur har ni valt att möta utvecklingsutmaningarna med ständigt nya lagkrav? Dela gärna med dig av dina erfarenheter. Eller hör av dig till oss på QESTIT så berättar vi mer om hur vi jobbar.
Webinar om kontinuerlig transformation
För ett tag sedan höll vår automatiseringsexpert Viktor Laszlo ett webinar om hur du levererar bättre produkter snabbare till kund, till både lägre kostnad och lägre risk. Nu kan du se webinaret on demand där Viktor pratar om det kontinuerliga arbetssättet som inkluderar CI, CD och CQA (Continuous Quality Assurance) och att det snart kommer vara nästintill ett måste för organisationer att gå åt det hållet. Speciellt om du jobbar med mjukvaruutveckling av produkter som ska gå till en slutanvändare.
