Tre grep for god teknologiledelse

Skal du rigge et team som skal drive teknisk utvikling av nettside eller programvare? Mangler du gode rutiner for å levere på tid og budsjett med forventet kvalitet? Eller er du uvant med å lede tekniske team, og trenger et krasjkurs for hvordan du skal komme i gang? I denne artikkelen hjelper vi deg med alt dette.

Uansett om det er tidsavgrensede prosjekter eller etablerte produktteam med forvaltnings- og utviklingsansvar for et produkt, er en god start å ha tverrfaglige ressurser i teamet. Selv om vi her skal ta for oss teknologiledelse, starter teknisk utvikling alltid med et forretningsbehov. Det vil si, det bør ligge et forretningsmessig behov bak et utviklingsløp.

Grep 1: La utviklere definere utviklingstid

I praksis er det nok ofte utviklerne som initierer et utviklingsløp, dels fordi de ser behov men også de mulige løsninger som løser behovet. I bunnen ligger en oppgave som ikke blir løst tilfredsstillende. 

Utviklere er de som best kjenner tekniske implikasjoner for å kunne løse oppgaven. De har best forutsetninger for å estimere utviklingstid (og med det utviklingskost) som kreves for å løse oppgaven. Samtidig vet vi at prosjektledere ivrer etter å levere en løsning så fort som mulig, med minimal utviklingstid. Utviklere må imidlertid ha privilegiet som ligger i å definere nødvendig utviklingstid. 

En forutsetning for utviklere til å inneha dette privilegiet er dog at de evner å gjøre realistiske estimater. Om de alltid leverer for sent spiller man ikke egen prosjektleder god. Om de derimot alltid leverer før tiden vil prosjektleder bli fristet til å kjøre ostehøvel på estimater, med en forventning om at det uansett blir levert før tiden. Ingen av delene gir gode prosesser.

Grep 2: Jobb i iterasjoner, fra MVP til endelig produkt

Det er ikke til å komme ifra at noen ganger er estimatene ikke forenlig med gjeldende fremdriftsplan. Når tidsaksen ikke kan rokkes ved er det naturlig å vurdere om kostnad eller kvalitet kan justeres. 

I utviklingsteam vil kostnad ofte være et produkt av hvor mange utviklere man har i sving. I utviklingsteam hjelper det imidlertid sjelden å bøte på tidsklemma med å øke kostnad i form av å kaste på flere utviklere. Å sette seg inn i komplekse tekniske problemstillinger krever nemlig tid, så vinninga går opp i spinninga. Flere utviklere er altså ikke en god akuttløsning. Man ønsker heller ikke å redusere kvaliteten i sluttproduktet. Da er spørsmålet - må første leveranse være sluttproduktet?

Å jobbe i iterasjoner der man fra en MVP, et minimum viable product, jobber seg fra en minimumsversjon til det endelige produktet, er hensiktsmessig i flere henseender. Ved å jobbe i iterasjoner tilnærmer man seg en agil metodikk der man lærer mer om kundebehov og optimal løsning underveis i utviklingsløpet. I motsetning til en vannfallsmetodikk, der man har et bilde av presumptivt beste løsning i forkant, jobber frem denne, og lanserer med brask og bram. 

Ved å lansere en minimumsversjon tidlig i utviklingsløpet, og samtidig analyserer bruksdata, lærer man mye. Kanskje er det vi tenkte som endelig versjon ikke det kunden egentlig trenger eller ønsker. Kanskje kunden egentlig ønsker en enklere versjon, eller noe helt annet enn vi trodde og satte kurs mot. 

Ved å jobbe i iterasjoner fra MVP mot endelig produkt kan man både prøve ut retninger med ikke-låste versjoner, samtidig som man har bedre forutsetninger for å forstå kundens behov. I sum - både sparte penger og bedre totalløsning. 

Grep 3: Etabler rutiner for å sikre god kvalitet

Utviklere er stort sett som oss andre, de kommer i alle former og farger. Noen jobber best individuelt, noen trives best med å jobbe i team. Men ved å bygge strukturer for arbeidsmetodikk tilrettelegger man for leveranser med høyere kvalitet, hele veien fra MVP til endelig produkt. 

Etabler rutiner for koderevisjon. Kode skrevet av en utvikler skal kanskje ikke kunne produksjonsettes før den er gjennomgått og godkjent av en annen utvikler. Gjør man dette jevnlig trenger man ikke mange minuttene pr revisjon, samtidig som det er et effektivt verktøy for å identifisere suboptimal kode. Med koderevisjon er det langt mindre sannsynlighet for å introdusere kode som gir dårlig ytelse, som vanskeliggjør fremtidige utvidelser, eller som rett og slett får appen din til å krasje.

Tilrettelegg for parprogrammering, altså at to utviklere skriver kode sammen. Du kan enten velge å se på det som å betale to programmere for å gjøre jobben til én, eller du kan velge å se på det som løpende kvalitetsheving av kode kombinert med kompetanseheving av utviklere. Som samtidig reduserer fremtidig risiko ved sykdom, eller at utvikler finner seg annen arbeidsgiver. Det skjer jo innimellom det også.

Testing er en del av utviklingen

Husk også alltid å legge inn i prosjektplanen tilstrekkelig tid for testing og feilretting. Koderevisjon og parprogrammering vil øke kvaliteten og redusere feilsituasjoner, men selv utviklere er bare mennesker, og feil kommer til å være tilstede. Alltid. Jo tidligere du planlegger for det, jo bedre leveranser vil du få.

Er det så enkelt? I prinsippet ja. Utfordringen ligger i å la alle ledd i en leveranse, fra bestiller til utfører, forstå og respektere hele prosessen. Utfordringen ligger i å etablere samspill mellom de uilke fagdisipliner og overlevering av stafettpinner. Utfordringen ligger i å etablere rutiner som tilrettelegger for de ulike fasene i en leveranse. 

Får man til det vil man oppleve at man går fra å jobbe med usikkerhet rundt hvordan denne MVPen blir et fullverdig produkt, til glede over å få være med å jobbe frem det som starter med en strekskisse i gråtoner. Og ender som et komplett verk med alle nødvendige farger i paletten på plass.