Vi får indimellem forespørgsler på en on-site .NET / Umbraco udvikler der kan løse udviklingsopgaver on site. Modellen med on-site konsulenter er formodentligt det rigtige hvis man har en konkret udfordring med sin Navision eller SAP opsætning, men anvendelsen af kort tids on-site konsulenter er en risikabel affære, hvis man har en mere langsigtet strategi og har et decideret udviklingsprojekt.
Udfordringen med IT resourcer
Antallet af udviklertimer 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.
Fasthold mål for alle med én projekt ejer (Project Owner)
Ofte lider IT projekter af enten ingen eller for mange projektejere. 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 projektejer 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. Projektejeren 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 projektejer (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.
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 udviklere 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 projektejer eller proxy-projektejer.
- 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.