Igennem de sidste 15 år har jeg arbejdet med it og softwareudvikling i forskellige afskygninger. Alt fra websider, CMS-systemer og til større it-systemer som fx regnskabs- og lønprogrammer i forbindelse med mine tre virksomheder Billy, Salary og Bilagscan.
Softwareudvikling ser let ud, og det kan umiddelbart ikke være det sværeste i verden at beskæftige sig med. Men dette er alt andet end sandheden, og derfor kuldsejler mange it-projekter med overskredne deadlines og et budget, som brister.
Selvom to it-projekter sjældent er ens, har jeg her samlet otte ting, som du bør vide, når du arbejder med softwareudvikling, hvis du vil undgå økonomiske katastrofer og brølere.
#1 Hyr de rigtige programmører til projektet
Det er i forvejen svært at finde kompetente udviklere til et it-projekt. Ovenikøbet skal du gå efter udviklere, som har løst lignende opgaver og har viden inden for nøjagtigt det område, dit projekt falder indenfor. Især ved de mere komplekse systemer bør du vælge ud fra erfaringer inden for netop dette felt, da udvikling ikke bare er udvikling, men i høj grad også handler om domæneviden. Udviklere af regnskabsprogrammer er et godt eksempel på det, fordi det kræver en vis indsigt i regler og regnskabslovgivning at kunne levere sublim software.
#2 Arbejd i små, agile trin/sprints ad gangen
It-projekter kan være svære at estimere, og det kan tage lang tid at sammensætte en komplet kravspecifikationsplan. Men hvis du begrænser nye udviklingsinitiativer til en overskuelig størrelse, som kan løses inden for relativt kort tid, mindsker du risikoen for at miste overblikket og kan lettere styre udviklingen og dit udviklerteam. Det er klart, at hvis projekterne er store, kan hele projektet ikke udvikles på to uger, men til gengæld kan du med fordel stadig holde fast i førnævnte sprints.
#3 Opdel ansvarsområderne skarpt
Der er mange ansvarsområder i it-udvikling. Fx er der både en feature-ansvarlig, en chefarkitekt og en salgsansvarlig. Hvis ikke du opdeler ansvarsområderne eller bliver bevidst om de forskellige stillinger, havner du i en situation, hvor de forkerte personer tager beslutninger om produktet, hvilket kan have store konsekvenser senere i forløbet. Fx er det vigtigt, at én person har fokus på, hvad der er kommercielt vigtigt for succesen, mens en anden prioriterer de løbende produktidéer (både dem, der kommer fra kunder, og dem, som kommer fra dit team). Og endelig skal der som minimum være en, der har det tekniske ansvar for arkitekturen, så softwaren løbende har en høj kodestandard, som gør det lettere at videreudvikle i fremtiden, og så man undgår at oparbejde ”kodegæld”.
#4 Lad ikke nødvendigvis udvikleren styre de strategiske beslutninger
I forlængelse af #3 gælder det også om at etablere en kultur, hvor man har respekt for de forskellige arbejdsområder, sådan så udviklingsafdelingen også respekterer den kommercielle side af en virksomhed og omvendt. Et stort problem og en udfordring for mange nybegyndere og endda øvede inden for it-udvikling er, at man lader den dygtigste udvikler tage nogle kode-relaterede beslutninger, som ender med at være dybt strategiske for hele virksomheden – ofte uden at hverken udvikleren eller direktøren forstår dette overgreb på virksomhedens langsigtede strategi. For at undgå denne fejl skal den ansvarlige udvikler informere direktøren (eller den salgsansvarlige) om konsekvenserne af de forskellige kodevalg, som opstår undervejs i udviklingen. Nogle beslutninger er uden strategisk betydning, mens andre bestemt kan være det. Her er et åbent informationsflow og faste ledermøder, hvor du diskuterer for og imod større beslutninger med udviklerteamet, vejen frem.
#5 Roadmaps er gode, men overhold følgende principper
En ting, som kunder er optaget af, er roadmaps. Dvs. hvilke features der kommer i fremtiden, og hvornår man som kunde kan forvente, at de er en del af produktet. Netop fordi it kan være svært at estimere, og tingene kan ændre sig undervejs, er det en god idé at dele roadmaps op i følgende niveauer:
• Idéer
• Under udvikling
• Implementering
• Afsluttet.
Det er en smagssag, om man vil fastsætte datoer for nye features, men personligt er jeg tilhænger af, at man blot fortæller, hvilke ting man arbejder på, og evt. angiver, hvornår man forventer at lancere disse features. Det er dog ikke anbefalelsesværdigt at have datoer for samtlige features, da dette aldrig vil afspejle virkeligheden.
#6 Skær ind til benet
Det er let at udvide et it-projekt, og noget af det nemmeste er at føje idéer til kravspecifikationsplanen. Men på et tidspunkt skal tingene udvikles, og hvis projektet bliver for omfattende med for mange features, skrider deadlines, og alt andet kan blive skubbet og i værste fald kuldsejle. Hold øjnene på bolden og gå altid tilbage til, hvad kernen af projektet er, for derved at sikre, at du kører projektet i mål inden for rammerne. Således kan du også bedre estimere tingene og vide, at det, du får udviklet, er noget, du kan bruge til at vækste forretningen, og som kunderne sætter pris på.
#7 Tal med kunderne og få løbende inputs tidligt
En klassisk fejl i it-udvikling er, at man kommer for langt væk fra slutbrugeren og derved bruger ressourcerne forkert. Især ved nye it-projekter kan du miste adgang til god viden fra brugerne, hvis du venter for lang tid med at lancere. Der er helt sikkert en omkostning ved at lancere tidligt, for det betyder, at du skal fokusere på support og vedligeholdelse, men gevinsten ved at få inputs fra brugere så tidligt som muligt kan være uundværlig, hvis du sigter efter et verdensklasseprodukt. Opsummeret er det derfor altafgørende, at du giver dine brugere let adgang til at levere inputs til forbedringer og produktønsker.
#8 Deadline overskrides som hovedregel
It-projekter forsinkes, det er hovedreglen, som du skal lære at leve med. Men hvorfor sker det, og hvorfor budgettere med det? It har det med at være mere omfattende, end overfladen viser, og hvis man helt vil undgå forsinkelser, kræver det et enormt kravspecifikationsplansarbejde – ressourcer, som lige så godt kan gå direkte til udvikling. Og det er den afvejning, man må gøre sig: ekstrem forberedelse eller løbende, små sprints, som gør det lettere at holde et stramt fokus. Én ting er dog sikker – udvikling er som et isbjerg: Først når du går i gang, opdager du de store udfordringer, som du ikke i samme detaljerede grad ville kunne identificere i planlægningsprocessen.
Next step: It vil altid være svært at estimere
It er en svær størrelse at arbejde med, da mange systemer og processer ofte udgør selve løsningen. Udefrakommende ting kan derfor let påvirke resultatet og skubbe deadlines. Men hvis du arbejder systematisk og disciplineret, mindsker du risikoen for fejl, og du bliver bedre til at estimere tid og pris for et givent it-projekt.
Andre relevante blogindlæg om emnet:
”Stol aldrig på en udvikler”
”Derfor kan du godt stole på en udvikler”
Yderst relevant checkliste og erkendelserejse for både små projekter, som apps, men bestemt også for større. Jeg kom til at tænker på Banedanmark og deres signal projekt til 20 mia DKK (and counting….) – hvor den er lige så relevant.
Udfordrigen, som jeg ser det, er at lukke hullet mellem realiteterne i it projekter (din liste) og forventningerne hos projektets sponsor, om det så er investorer, en CEO eller anden stakeholder.
Tak Jesper. Ja total enig.
Listen er lige så relevant for store, etablerede virksomheder, som helt små projekter – omend konsekvenserne ved fejlene er forskellige.
Jeg hører stadig om it-projekter, hvor de kører projektet efter “vandfaldsmodellen” og først undervejs (til sidst) konstaterer de, at projektet må aflyses og det hele kan skrottes. De kan i stedet med fordel bruge scrump – bare for at nævne ét eksempel på en konkret model, der egner sig bedre.