Hvornår begynder et projekt at synke?
Ethvert IT-projekt starter på samme måde. Der er ambitiøse planer, en tidsplan, en præsentation af de første mockups og overbevisningen om, at virksomheden om nogle måneder vil bruge et moderne system. I begyndelsen ser alt lovende ud, men med tiden opstår de første førsinkelser. Deadlinen rykkes en uge, senere en måned. Antallet af fejl stiger, kommunikationen med leverandøren bliver stadig sværere, og de efterfølgende svar lyder: "Lidt endnu", "Det er bare en lille rettelse" eller "Vi er næsten i mål."
På et tidspunkt viser det sig, at virksomheden i stedet for et færdigt produkt har et ufuldendt projekt, som ingen vil overtage.
Det er et scenarie, der er langt mere almindeligt, end man skulle tro.
Den værste problem er ikke koden
De fleste virksomhedsledere antager, at hvis projektet ikke virker, skyldes det dårligt skrevet kode. Jo - nogle gange er det netop tilfældet. I praksis ligger problemet dog oftere dybere.
Der mangler dokumentation. Arkitekturen er blevet bygget "løbende". Der er ingen automatiske tests. Integrationer er lavet midlertidigt. Nye funktioner er blevet tilføjet uden analyse af virkningen på hele systemet. Som resultat kan selv en lille ændring forårsage flere fejl.
Det er lidt ligesom at renovere et hus uden en plan. Hvert enkelt rum kan stadig gøres fint, men med tiden viser det sig, at væggene ikke er, hvor de burde være, installationerne er tilfældige, og ombygningen bliver mere og mere kostbar.
Hvornår er det tid til at sige "stop"?
Et af de sværeste øjeblikke for en virksomheds ejer er beslutningen om at afbryde samarbejdet med den hidtidige leverandør. Mange virksomheder venter for længe med den beslutning.
Hvorfor?
Fordi projektet allerede har kostet mange penge.
Fordi det er synd for tiden.
Fordi man måske tror "det kan stadig lykkes".
Psykologien kalder det sunkne omkostninger. Jo mere vi allerede har investeret, desto sværere er det at indrømme, at den nuværende kurs fører ingensteder hen.
I nogle tilfælde er den bedste beslutning ikke at fortsætte med at putte flere budgetmidler i det samme problem, men at stoppe projektet og foretage en rolig analyse af situationen.
Kan ethvert projekt reddes?
Nej. - Og det er bedst at sige det ærligt.
Der er projekter, hvor reparation ville koste mere end at bygge dem fra bunden. Det sker også, at den anvendte teknologi allerede er forældet, eller at arkitekturen er designet på en måde, der umuliggør videre udvikling.
Derfor burde det første skridt aldrig være at give løfter.
Det første skridt burde være en audit.
Først efter en grundig gennemgang af koden, dokumentationen, infrastrukturen og processerne kan man svare på, om det er mest fornuftigt at reparere den eksisterende løsning eller starte et nyt projekt.
En god teknologipartner vil ikke sige, hvad kunden gerne vil høre.
De vil sige, hvad der er bedst for kundens forretning.
Hvordan ser det ud i praksis at redde et projekt?
Modsat hvad man måske tror, starter det ikke med programmering.
Først skal man forstå, hvad man har med at gøre.
Vi analyserer systemets arkitektur, kodekvalitet, kommunikationsmetoder mellem moduler, datasikkerhed, ydeevne og muligheder for fremtidig udvikling. Vi tjekker dokumentation, versionshistorik og anvendte teknologier. Ofte er det allerede efter få dage klart, hvor det reelle problem ligger.
Først danner vi en handlingsplan.
Nogle gange rækker det at rydde op i koden og rette et par centrale elementer. Andre gange er det nødvendigt at ombygge udvalgte moduler. Og nogle gange er den mest fornuftige løsning at bygge et nyt system og genbruge det, der allerede kan bruges.
Der findes ikke to identiske projekter.
Ligesom der ikke findes en enkelt opskrift på, hvordan man redder dem.
Hvorfor er det sværere at overtage et projekt end at starte nyt?
Det er et spørgsmål, vi ofte hører fra kunder.
Svaret er enkelt.
Når vi laver et system fra bunden, kender vi hver eneste designbeslutning. Vi ved, hvorfor en bestemt løsning blev valgt, og hvilke antagelser der lå bag.
Når vi overtager et fremmed projekt, må vi først genskabe den viden.
Det er lidt som at overtage byggeriet af et hus fra et hold, der efterlod byggepladsen uden planer, uden dokumentation og uden information om, hvad der er blevet udført.
Derfor kræver det at redde projekter ikke kun programmæssige kompetencer, men også arkitektonisk, analytisk og designmæssig erfaring.
En teknologipartner skal også være hos dig, når problemer opstår
Et godt softwarehus kendes ikke på, hvordan det starter et projekt.
Det kendes på, hvordan det reagerer, når der opstår vanskeligheder.
Ikke alt kan forudses. Forretningskrav, teknologier og brugernes behov ændrer sig. Det afgørende er, om teamet kan finde løsninger, kommunikere risici tydeligt og sammen med kunden tage de bedste beslutninger.
Det er netop derved, tillid opbygges.
Hvordan arbejder vi i Web24?
Vi griber overtagelsesprojekter an med stor forsigtighed.
Vi lover ikke guld og grønne skove efter den første samtale.
Først analyserer vi situationen. Vi tjekker, hvad der er udført, hvad der kan genbruges, og hvad der vil kræve genbygning. Først derefter udarbejder vi en anbefaling og en plan for de videre handlinger.
Vores mål er ikke at skrive endnu tusindvis af linjer kode.
Vores mål er at føre projektet til et punkt, hvor det reelt begynder at understøtte forretningsudviklingen.
Resumé
Hvis dit projekt er strandet, leverandøren er holdt op med at svare, tidsplanen kun eksisterer i teorien, og hver nye rettelse skaber flere fejl, betyder det ikke nødvendigvis, at alt er tabt.
I mange tilfælde kan problemet løses.
Men man må starte med ét skridt - en grundig analyse af situationen.
For før man begynder at redde et projekt, er det vigtigt først at finde ud af, hvorfor det begyndte at synke.
