Min tur til å være prosjektleder

I år var det min tur til å være prosjektleder! Dagen jeg ble forespurt om å lede dette prosjektet fikk jeg blandede følelser.

hyttekoding_2014

Først følte jeg en spenning, siden det var noe nytt. En ny utfordring, noe jeg elsker. Spenningen forsvant fort og ble etterfulgt av svak panikk og stress. Jeg hadde aldri ledet et team av utviklere før, men hadde naturligvis jobbet i team tidligere og hadde en del tanker rundt det å være prosjektleder. Noen av ideene fungerte og noen fungerte dessverre ikke like bra som jeg hadde håpet.

ITverket gjennomfører hvert år sommerprosjekter ute hos kunder, og kunden min i år var Patentstyret. Patentstyret er en statlig norsk etat som mottar og behandler årlig tusenvis av søknader om patenter, varemerke- og designrettigheter. I tillegg mottar de også forespørsler om statistikk fra media, forskere, selskaper, osv om søknadsinngang. Spørsmål fra media kan f.eks være “Hvor mange søknader kommer fra vårt fylke” eller “Hvor mange innvilgede søknader fikk vårt fylke i fjor”. I dag besvares disse forespørslene manuelt ved å hente ut data og aggregere denne dataen manuelt, gjerne i Excel ark e.l. Denne prosessen er tidkrevende og sjansen for å gi ut feil tall er høy. Patentstyret har derfor hatt et ønske om å lage en mer selvbetjent nettbasert løsning hvor man kan gå inn og hente denne dataen selv i form av grafer og tabeller.

ITverket ble hyret inn for å lage en statistikkportal hvor brukere selv kan hente ut tall og data for de vanligste spørsmålene. Prosjektet ble kjørt som et sommerprosjekt med studenter fra NTNU, noe vi har hatt god erfaring med fra tidligere år. Målet med å ha sånne sommerprosjekter er mange, men et av de viktigste målene er å øke lederkompetansen til ansatte i selskapet. Hvert år blir det valgt nye prosjektledere og disse er vanlige utviklere hos ITverket.

Teamet bestod av fire flinke studenter fra NTNU, en utvikler fra kunden som skulle bistå oss med interne systemer og produksjonsdatabaser, samt meg selv som prosjektleder. I tillegg hadde vi en ressursperson med dyp fag- og forretningskunnskap. Patent, varemerke og design er et intrikat og vanskelig fagfelt med mye juss og regler, og han var en uvurdelig ressurs. Dette var et studentprosjekt der studentene skulle stå for hoveddelen av utviklingen, og min rolle var å lede prosessen, samt bistå med arkitektur og hjelp ved tekniske utfordringer.

Vi valgte å bruke Scrum som arbeidsmetodikk. Scrum og agile gir noen helt klare fordeler som gjorde at Scrum ble det foretrukne valget i dette 6 ukers prosjektet. Den største fordelen, blandt mange, er raskere igangsettelse av prosjektet og hurtigere tilbakemelding fra kunden. Vi hadde seks sprinter på én uke hver. Vi følte at 1 ukers sprinter ga oss mange nok iterasjoner til å prøve og feile underveis. Risikoen er selvfølgelig at man bruker unødigvendig mye tid på administrasjon, møter osv, men i dette tilfellet var det den beste løsningen.

I tillegg til å bruke Scrum, ønsket vi å gjøre en liten vri ved å bruke deler av Kanban samtidig. Kanban er i likhet med Scrum en form for smidig arbeidsmetodikk. Likhetene mellom disse to er mange, men det er også noen forskjeller. Blandt annet visualiserer man arbeidsflyten mye bedre ved å bruke et Kanban brett. Man får mye lettere oversikt over hvor i prosessen utviklerne er med sin oppgave, hvilken oppgave de jobber med osv. I dette prosjektet hadde vi tre faser; Todo, WIP (Work In Progress) og Done og i tillegg til disse tre, en backlog hvor utviklerne kunne ta oppgaver når Todo var tom. Det er flere faser man kunne tatt med som f.eks Design, Testing, osv, men prosjektet var for lite i tid, ressurser og kompleksitet til at vi tok med flere faser. Kanban legger også opp til en begrensning av hvor mange løpende oppgaver man kan ha i hver fase. Vi la en begrensning på to oppgaver i Todo og én i WIP. Dette gjorde at man fokuserte kun på den ene oppgaven og dersom man fikk problemer løste vi det der og da, i stedet for å starte på en ny oppgave.

Scrum etter min erfaring sier ingenting om verktøy. Det er en prosess og arbeidsmetodikk. Jeg har brukt flere såkalte “Scrum verktøy” og de er av varierende kvalitet. De har vært vanskelig å bruke, sette opp og få en god oversikt over oppgaver, statistikk osv. I tillegg har det i tidligere prosjekter vært mye fokus på verktøy og mindre fokus på samtaler og diskusjoner med kunden. Verktøyet har hatt en tendens til å ende opp som en statisk database med oppgaver som aldri endrer seg. I dette prosjektet ville jeg dermed prøve noe nytt og valgte derfor å bruke penn og papir. Det gjorde at vi fokuserte mindre på verktøy og mer på samtaler med kunden, men det førte også til mindre kontroll og dårligere oversikt over oppgavene som var igjen. Oppgaver ble først opprettet i sprintplanleggingen ved å gå gjennom kravspesifikasjonen, noe som gjorde at planleggingen tok lenger tid enn nødvendig.

Erfaringen fra dette prosjektet har i all hovedsak vært veldig positiv. Studentene tilegnet seg mye teknisk kunnskap og lærte hvordan virkelige prosjekter gjennomføres. Jeg på den andre siden fikk god erfaring som prosjektleder. Mange av valgene vi tok fungerte veldig bra, men vi støtte også på noen problemer underveis. Vi hadde daglige standups, og selv om jeg prøvde å være hard på tidsbruken, skled vi noen ganger ut i utstrakte diskusjoner. Det føltes unødvendig å inkludere alle på teamet i diskusjoner som for eksempel kun to personer hadde nytte av. Dette førte til at man ofte koblet ut og sløste medtid.Roteringen av arbeidsoppgavene fungerte veldig bra i første halvdel av prosjektet, men under siste halvdel skled det litt ut. Dette var nok fordi vi begynte å merke tidspresset og studentene hadde en naturlig gravitasjon mot enkelte typer oppgaver.

Den viktigste komponenten i hele systemet er data, og her trengte vi mye data. For å redusere trafikk mot produksjonsdatabasene og for å isolere systemene mest mulig valgte vi å lage uttrekk av data fra produksjonsmiljøet. Det vil si at statistikkportalen har sin egen transformerte kopi av produksjonsdata, noe som igjen betyr at man må lage skript for å trekke ut denne dataen.

Uttrekk av data fra produksjonsmiljøet tok mye lenger tid enn ventet og dette førte til at andre oppgaver som kvalitetssikring av spørringer og data først ble startet de siste par ukene. Selve kvalitetssikringen tok også mye lenger tid og burde startet mye tidligere og gjort kontinuerlig under hele prosjektet. Men siden vi ikke hadde produksjonsdata å jobbe med ble dette naturligvis ikke gjort. Dette førte til at prosjektet ikke ble ferdigsatt ved slutten av prosjektet og det gjenstår i dag noen oppgaver, som kvalitetssikring av data, oversettelse av tekster, m.m.

Dersom jeg skulle ledet enda et sommerprosjekt en gang i fremtiden ville jeg ha gjort noen ting annerledes. Jeg ville startet med vanskelige og usikre oppgaver mye tidligere. Selv om ingen har skyld, gjorde forsinket uttrekk av data og oppsett av servere at prosjektet ikke er satt ut i produksjon per dags dato. Jeg ville ha revurdert å bruke et verktøy som er rettet mot en smidig arbeidsmetodikk.. Gode verktøy gjør det lettere å håndtere kompleksiteten som kan oppstå i smidige prosesser hvor krav og prioriteter endrer seg fra dag til dag. Det gjør det lettere for f.eks produkteier å omprioritere, legge inn nye endringer og krav, osv.

På tross av enkelte problemer underveis i prosjektet vil jeg si at det har vært en overveldende suksess, noe kunden også har uttrykt gjentatte ganger. Prosjektet ble ved flere anledninger presentert til sentrale personer i Patentstyret og teamet fikk bare positive tilbakemeldinger. Ved siste presentasjon for avdelingslederne, markedsføringsavdelingen og deler av ledergruppen ble overlevering mottatt med stående applaus. Kunden har uttrykt at de har fått mye mer enn de kunne forestille seg på seks uker. Løsningen som ble lagd gir mye og god informasjon på en oversiktlig og lettfattelig måte.

Studentene var utrolig flinke og tok til seg mye kunnskap, både teknisk og forretningsmessig, veldig fort. Fordelene ved å delta i et sommerprosjekt er mange for en student. Den viktigste fordelen er å kunne delta i et virkelig prosjekt som kunden/selskapet har nytte av. Man ser hvordan virkelige prosjekter blir gjennomført og kan ta med seg dette tilbake til skolen. Studentene får også knyttet kontakter med andre utviklere og selskaper og kan dra nytte av dette i jobbsøkersammenheng, enten det er hos ITverket eller andre selskaper.

Jeg har alltid vært en utvikler og dette var første gang jeg kunne prøve meg som prosjektleder. Min erfaring som prosjektleder i dette prosjektet har i all hovedsak vært veldig bra og jeg har lært utrolig mye. For meg har denne rollen tidligere vært diffus og litt uklar, men denne sommeren gikk det opp for meg hvor mye arbeid det er å være en prosjektleder. Man må hele tiden ligge foran utviklerne med tanke på arbeidsoppgaver, planlegging av neste sprint, kommunikasjon med kunden og utviklerne. Jeg vil påstå at jeg har vokst som utvikler ved å være prosjektleder.

Resultatet er nå tilgjengelig på Patentstyret sine hjemmesider: http://statistics.patentstyret.no