Derfor har du IKKE brug for en on site .NET / Umbraco konsulent

Overvejer du at hyre en on-site .NET / Umbraco konsulent? Vi anbefaler at du tænker dig om en ekstra gang, da det kan ende med at blive en dyr affære.
Modellen med on-site konsulenter kan fungere rigtigt godt, hvis man har en konkret udfordring med sin Navision eller SAP opsætning. Har du derimod en mere langsigtet strategi og har et decideret udviklingsprojekt, kan du risikere et fejlbehæftet projekt, som du i værste tilfælde, kan blive nødt til at skrotte.

Udfordringen med IT ressourcer

Antallet af udvikler mandetimer er faktisk ikke det vigtigste eller proportionelt med at have en god IT løsning.
Det er snarere hvordan processen omkring udviklingen har været og hvilke initiativer, der er blevet iværksat for at sikre, at der er konsistens og en langsigtet plan, der kan arbejdes videre på.
Forskellige scenarier for hvordan et IT set up kan se ud, kan ses nedenfor:

IT projekt med én fast udvikler. Dette er den hurtigste måde at komme i gang på – men også den potentielt farligste. Med en Full Stack udvikler der laver det hele, sker der hurtige fremskridt, men der er en meget stor fare for at arkitekturen ikke er muligt at arbejde videre på og ikke kan overtages af andre.

Langt de fleste udviklere kan ikke se deres eget arbejde udefra, og arbejder under tidspres og får sjældent dokumenteret eller verificeret det der er lavet. Derfor sidder man som projektejer med en potentielt tikkende bombe i tilfælde af jobskifte, sygdom, barsel – men også hvis projektet bliver for stort kan det være en meget stor belastning for den ene person, der sidder med hele løsningen og kan nemt lede til stress og  uhensigtsmæssige beslutninger.
 
Anvendelse af en allround Full Stack udvikler er en farlig cocktail, fordi man samler alle ansvarsområder (Front-end, Back-end, Installation og test) et sted og der kan her nemt opstå farlige situationer.
 
IT projekt med to eller flere faste udviklere. Dette er den rigtige vej at gå. Men typisk kræver dette en stor investering, da man skal have et permanent udviklingsteam og ofte vil et udviklingsprojekt ikke have ressourcer til at kunne gennemføre en sådan ansættelse, da det vil være for kortsigtet.
 
I princippet kan det dog virke, men der er også en stor risiko for at miljøet omkring to eller tre udviklere kan blive for indspist og de kommer til at agere som ”intern IT”. Her bliver de en service organisation, hvortil det kan være svært at tiltrække de rigtige udviklingsprofiler til, da friheden bliver for lukket omkring et for lille miljø, og der kommer for lidt inspiration udefra.

Ad-hoc tilføjelse af eksterne konsulenter til et eksisterende projekt. Dette kan give god mening, hvis der er specifikke områder, hvor der ikke er interne kompetencer til at løse opgaven. Men ligesom ni kvinder ikke kan føde ét barn på én måned, er det ikke en løsning der skal vælges for at komme hurtigere i mål. Forøgelsen af ressourcer er ikke nødvendigvis proportionel med kvaliteten af arbejdet der udføres og kan under de forkerte forudsætninger have den modsatte effekt.

Tilføjelse af eksterne konsulenter med fast allokering. Med dette scenarie kan man have et ekstern setup, der kan bidrage til ens egen organisation. Dette kan typisk være i samarbejde med egen IT afdeling eller en outsourcing af udviklingsopgaver, der ligger uden for organisationens primære fokusområde. Ved at involvere konsulenter fra et større udviklingshus, hvor der er certificering, undervisning og et bredt fagligt IT miljø, sikrer man at der er et ekstern setup, der kan overleve medarbejder udskiftning, skiftende teknologi trends og ændringer i organisationen. Det er dog vigtigt her, ikke at blive fristet til at vælge én ekstern konsulent. Det er bedre at have to udviklere på halvtid end at lægge alle opgaver ved en person– selvom overhead kan være lidt større.

Ressource setup er dog kun forudsætningen for en god start. Hvis miljøet og processerne ikke er på plads, vil selv de dygtigste konsulenter kunne fejle i forhold til forventninger. Så at få et vellykket IT projekt handler ikke kun om at få de rigtige udviklere, men lige så meget om at have det rigtige miljø, hvori de gode resultater kan skabes. Det bedste er at have et struktureret og agilt setup, hvor man kan eliminere forkerte retninger hurtigt (og være fejltolerant) og sikre et langsigtet kontinuerligt fremskridt.

The trouble with programmers is that you can never tell what a programmer is doing until it’s too late.

Seymour Cray

Fasthold mål for alle med én projekt ejer (Project Owner)

Ofte lider IT projekter af enten ingen eller for mange projekt ejere. For at kunne prioritere forretningsmål og omsætte dette til udviklingsopgaver i den rigtige rækkefølge, er det nødvendigt med én person, der agerer projekt ejer mens projektet kører. Det er vigtigt at der er en central person, der prioriterer opgaver og kan holde sammen på forretningskrav så alle spørgsmål kan blive besvaret uden, at der opstår tvivl eller forsinkelse.
 
At projektejeren faktisk sidder fast i organisationen er en klar fordel, men kan også være en proxy- projekt ejer i tilfælde af, at der ikke er interne ressourcer til det.

Projekt ejeren er dog ikke den eneste vigtigste person for et vellykket projekt. Så for at undgå misforståelser omkring ansvarsområder og konfliktinteresser, bør det som udgangspunkt altid beskrives i opstartsfasen, hvem der har ansvar for hvad og hvilke roller de skal udfylde. Dette gør det også nemmere at analysere, hvad der går galt hvis der skulle opstå problemer.

Vær agilt for at kunne spore fremskridt hurtigt

At være agil skal dog ikke forveksles med blot at tilføje ressourcer efter behov eller tænke kortsigtet. Det er snarere et spørgsmål om, at agere pragmatisk og afprøve det, man gør mod virkeligheden så ofte som muligt. Der bør være en struktureret proces omkring hvordan opgaver beskrives (user stories, acceptkriterier m.m.), og der bør være én primær projekt ejer (se foregående afsnit) og et fastlagt roadmap der er forståeligt for alle udviklere, testere, projektledere og andre der deltager. Langt den bedste metode er Kanban, Scrumban eller Scrum med en digital platformsunderstøttelse i form af Atlassian JIRA eller tilsvarende, der så understøttes af daglige eller ugentlige prioriteringsmøder (tip, selvom Kanban ofte illustreres med yellow stickers på en opslagstavle er dette ikke en farbar vej at gå).
 
Udover dette basis setup af proces, er det også nødvendigt at have et understøttede teknologi med f.eks. GIT og continuous integration (TeamCity, Jenkins, Octopus eller tilsvarende) så alt hvad der er lavet, er sporbart og kan releases eller rulles tilbage, hvis det skulle være nødvendigt.
 
For at citere LinkedIn founder Reid Hoffmans citat ”at hvis man ikke skammer sig over sin første version af sit produkt, har man lanceret det for sent”. Dette er særligt vigtigt i en verden hvor IT jobmarkedet er brandvarmt, og man aldrig kan vide sig 100% sikker på at alle på projektet stadig er der om 2 måneder. For at sikre sin arkitektur bør man derfor lave korte udviklings loop, og sørge for at der releases kontinuerligt, og at der læres i mødet med virkeligheden. Hver gang udgivelses dato udsættes forhøjes chancen for, at der bygges noget på forkerte antagelser og risikoen for at udgive det bliver større.

If You're Not Embarrassed By The First Version Of Your Product, You’ve Launched Too Late.

Reid Hoffman, LinkedIn founder

Retrospektiv analyse

Det der adskiller de mest succesfulde udviklingsteams fra andre mindre succesfulde er typisk at de succesfulde er i stand at optimere deres egne processer, og hele tiden lave færre fejl og blive mere effektive. Dette er ikke noget der sker af sig selv, det kræver er meta refleksion omkring proces og vilje til at optimere og ændre egne arbejdsgange.

Det ligger i den agile model at skulle lave retrospektive review og optimere processen. Simple spørgsmål er her:
 

  • Hvad er ikke gået så godt
  • hvad kan forbedres – og ikke mindst
  • hvad vil vi prioritere at forbedre til næste gang.

Det siger sig selv at der i dette setup ikke er plads til korttidsansatte on-site konsulenter. De vil typisk blive prygelknabe for alt, hvad der kan og vil gå galt og vil på denne måde ikke indgå ligeværdigt i teamet og ikke kunne være med til at udvikle procesmodelen som ikke må undervurderes.

Opsummering

Det er selvfølgelig forskelligt for organisation til organisation, hvilke prioriter man har i sine projekter. Men skal der alligevel opsummeres til nogle hovedpointer må det være:
 

  • Hav et set up med interne og eksterne konsulenter der ikke er skrøbeligt og for person afhængigt.
  • Sæt klare mål og lad disse blive fulgt til dør af en projekt ejer eller proxy projekt ejer.
  • Arbejd agilt og udgiv software så ofte som muligt.
  • Lær af processer ved at holde retrospektive møder ofte.

Med ovenstående er man ikke sikret – men har gjort det absolut vigtigste - for at undgå de værste IT katastrofer.

Case: Team Danmark

Team Danmark begyndte at omlægge alle deres interne systemer til .NET i 2009, og Compent har været fast leverandør og sparringspartner siden begyndelsen.

Læs Team Danmark case her...

Andre blog indlæg
linkedin twitter facebook arrow-left arrow-right