<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=614121&amp;fmt=gif">

BLOGG

Her finner du nyheter om Cefalo og fagstoff om IT-outsourcing.

4 essensielle råd for å modernisere gammel software

Asif Kamal | 01.08.2019

Forårsaker bedriftens software mer trøbbel enn den er verdt? Adresser disse punktene før du igangsetter et dyrt prosjekt.

Det skjer mange bedrifter før eller siden: Programvaren som pleide å bære dere på skuldrene sine har sakte men sikkert sunket sammen under vekten, og endt opp som et monster av bugs og utdatert spagetti-kode ingen lenger husker ideen bak. Du trenger en skikkelig renovasjon, men oppgaven foran deg virker stor og uhåndterlig. 

Selv om du har skikkelig gode kodere på laget, er det likevel ikke nok. Skal bedriften din lykkes med å modernisere software som ikke fungerer bra nok lenger, er du avhengig av god prosjektstyring og riktig holdning til oppgaven. 

Følger du disse fire rådene, ligger du allerede langt foran de fleste.

1. Vit hvilke problemer moderniseringen skal løse

Ofte er årsaken til at bedrifter investerer i modernisering av software-løsningen sin, at den har blitt for stor og uoversiktlig til at den er hensiktsmessig å bruke lenger. Det mangler en overordnet plan, og delene interagerer med hverandre på en måte som leder til mye bugs. Typisk er utviklerne som opprinnelig skrev store deler av koden borte, og den er vanskelig å tolke for dem som jobber der i dag.

Før du setter et nytt utviklerteam på saken, er det utrolig viktig å vite hva som leder til problemene dere opplever, og ha en plan for at det samme ikke skal skje i den nye varianten av programvaren. Du kan ikke bare skifte kodespråk og håpe at denne gangen blir alt nytt, fresht og moderne. Da sparker du kun problemene bare et år eller to lenger frem.

Nøkkelen er å tenke langsiktig, og skrive programvaren på en skaleringsvennlig måte som tar hensyn til at antallet brukere kan komme til å øke drastisk. Det er vanlig at de mest kritiske problemene først dukker opp når det kommer inn flere brukere enn det opprinnelig var tiltenkt. Skriv for morgendagen, ikke bare for i dag.

2. Sett en solid fremdriftsplan

En annen utfordring med å modernisere software, er at det i seg selv ikke skaper nye verdier for bedriften. Det er heller en plattform som enklere lar deg skape verdi etter at den er ferdigstilt. For at ikke prosjektet skal skli ut og det tar altfor lang tid før du begynner å skape verdi, er du helt avhengig av å planlegge fremdriften godt. 

En av våre egne utviklere, Asif, sa det kanskje best: Det finnes ingen grense for hvor mye du kan optimalisere koden, så det er viktig å finne en balanse mellom tid og kvalitet. Har du ingen tydelige deadlines, kan koderne sitte og finpusse i det uendelige. 

Antakeligvis vil det likevel oppstå uforutsette forsinkelser og hindringer, men sett av nok tid til at det ikke spenner bein for hele prosjektet, og ta tak i dem så fort som mulig.

3. Kost på deg et proof of concept!

Den kanskje største kjeppen i hjulene for å bli ferdig i tide, er å starte direkte på fullversjonen av programvaren din. Selv om det frontloader utviklingsprosessen litt, er du nødt til å prioritere å få på plass et proof of concept først. Det betyr at utviklerne lager en prototyp i forkant, for å teste om ting faktisk vil fungere som antatt.

Det er dessverre ikke uvanlig at bedrifter dropper dette i håp om å bli raskere ferdig, og dermed begynne å generere verdi raskere. Dessverre blir resultatet ofte at helt grunnleggende problemer først oppdages i slutten av utviklingsprosessen, når den ferdige softwaren skal rulles ut. 

Den tiden du sparte i begynnelsen av prosjektet smaker ikke like søtt når du blir nødt til å demontere hele byggverket for å reparere grunnmuren.

 

4. Rull ut programvaren gradvis

Mennesker er vanedyr, og det er ikke uvanlig å få klager fra brukerne når du endelig ruller ut ny programvare som er annerledes enn de er vant til. Ved gradvis å rulle ut nye varianter av forskjellige features ved programvaren, kan brukerne bli vant til den i eget tempo, og du får samtidig uvurderlig feedback på hvordan den fungerer i praksis, og om det er ting du må endre på.

Når du utvikler en ny variant av gammel programvare, betyr det dessuten at utviklerne en stund vil få nesten dobbelt opp med arbeid. Ikke bare skal de skape en ny software-løsning, men de må samtidig drifte den gamle. Ved å bytte ut gamle versjoner av features med nye ettersom de fullføres, vil arbeidsmengden avta litt etter litt, etter hvert som den gamle, upraktiske løsningen avvikles. Dermed får utviklerne mer tid til å utvikle, noe som gir gjenklang både i trivsel og effektivitet.

 

New call-to-action