torsdag 26. august 2010

Utvikling er enkelt, det er drift som er vanskelig

Jeg har en far som var kjøpmann, og som i Trondheim drev flere dagligvarebutikker. Som gutt dro jeg ofte innom butikken på Heimdal, 10 minutters sykkeltur unna hjemmet. Jeg var en ivrig sønn som gjerne ville jobbe, noe jeg ikke fikk lov til før jeg ble konfirmert. Derimot lurte jeg meg til noen småoppgaver innimellom som flaskegutt (rydde tomflaskene), noe jeg kanskje angrer på 3 prolapser senere. Det var 2 ting jeg så som flaskegutt: 1) Jeg hadde en far som jobbet veldig mange timer, og 2) det nye data-kassasystemet fra Siemens-Nixdorff var meget spennende. De to som installerte systemet hadde 13 år gamle meg som nysgjerrig tilskuer hver dag etter skolen var ferdig. Der og da lovte jeg meg selv at jeg skulle bli dataekspert, og ikke slite time etter time i et butikklokale.

Noen år senere startet jeg som student på datalinjen ved Melhus Videregående (noe naivt trodde jeg dette var utdanningen for dataeksperter). Siste studieår ble jeg gitt følgende råd av datalæreren: ”Ikke begynn som utvikler. Jobb heller med drift.” Selv om jeg takket for rådet, så visste jeg umiddelbart at jeg ikke kom til å følge det. Å ta vare på det eksisterende virket for meg umåtelig kjedelig. Å skape noe nytt virket derimot som veldig mye mer spennende. Lite visste jeg da at jeg senere kom til å jobbe med drift for en av Norges mest suksessfulle merkevarer, nettopp for å kunne få ro til å skape nye ting.

For dette forholdet mellom det nyskapende og det ivaretaende er spennende for en innovasjonskonsulent. I tiden som konsulent i Devoteam daVinci, så vi at det som hindret bedrift etter bedrift fra å innovere, var problemet med drift og forvaltning. Driftsavbrudd, selgere som klaget, kunder som ønsket en ny knapp og utviklere som kranglet med driftere, var mer enn nok å bruke tiden på. Jeg fikk en aha når jeg pratet med med Kris Halvorsen hos Intuit, ”Americas most admired company” mange år på rad. Jeg intervjuet han om innovasjon, noe han vet mye om etter å ha arbeidet som forsker hos kjente Xerox Parc og i dag som Innovasjonsdirektør hos Intuit i spennende Silicon Valley. Vi diskuterte Google, og jeg spurte hvilken prosess de benyttet for å utvikle nye programmer. Det var da han kom med den for meg legendariske setningen (som er den setningen jeg har sitert flest ganger i mitt liv): ”Du vet for Google så er ikke utvikling vanskelig. De setter en 4-6 menn og kvinner sammen, så skaper de noe. Derimot så har de sin kjernekompetanse på drift. Utvikling er enkelt, det er drift som er vanskelig”.

I min tid hos FINN.no ble jeg noe motvillig leder for drift og driftsutvikling. Jeg hadde fått muligheten til å bli med i FINN.no sin innovasjonssatsning, men en stilling som leder ville gi meg en tydeligere rolle og mer ansvar. Jeg tok sjansen, og min kjepphest ble å la utvikling utvikle for enkel drift (noe som nok frustrerte en del prosjektledere og produktsjefer som jeg ikke nådde helt fram til). Økende antall feil i teknologiplattformen førte til frustrerte kunder og driftsansatte. Noe måtte gjøres, og rådet en meget erfaren lederkonsulent ga meg var å sette opp overleveringskrav, det vil si å bygge en barriere mellom utviklerne og drift. Heldigvis hadde vi begynt å diskutere Lean Software Development, som sier det totalt motsatte: Riv ned alle barrierer. I dag har FINN.no en god dialog mellom drift og utvikling, en kritisk suksessfaktor. Vår dyktige driftssjef Einar og hans team gjorde det mulig for FINN.no å lansere en ny versjon hver 3. uke, noe andre selskaper med månedslange test og releaseprosesser bare kan drømme om. I tillegg gjorde utvikling og QA det enkelt å være en driftsmann gjennom å angripe feil på et tidlig stadium. Vi omformet kulturen i selskapet til kun å utvikle nye funksjoner som holdt god funksjonell og driftsmessig kvalitet, håndhevet gjennom en QA avdeling. Med stabil drift kom roen til å kunne utvikle genuint nye funksjoner. Antall feil gikk ned fra mange hundre, til noen titalls.

Problemet med drift versus utvikling har jeg også sett hos andre selskaper. De har en titalls utviklere, men ledelsen er missfornøyd med hastigheten på nyutviklingen. Det er da lett å anta at utviklerne er inkompetente, og outsource utviklingen til dyktige utviklere på utsiden (for å sitte igjen med driftsansvaret selv). Men problemet er ofte at utviklerne ikke får tid til å utvikle nye ting. De har travle oppdragsgivere som gjennom mange år har stresset nyutvikling, men til slutt faller korthuset sammen. Manglende eller helt fraværende driftskompetanse (mange utviklere som meg synes drift er kjedelig), har ført til systemer som stadig trenger håndspåleggelse. Manglende ro gjør at utviklingen tar lengre tid, som igjen fører til økende planleggingsarbeid og trykk fra oppdragsgiveren. I slike tilfeller finnes ingen enkel medisin. Jeg har tidvis forsøkt å forklare direktører uten teknisk forståelse hvorfor hans 21 år gamle selvlærte nevø kan lage en programsnutt raskere enn hans team på 10 utviklere med mastergrad.

Tidvis kan man fryde seg over utviklingsprosjekter som har gått galt. I en av mine tidligere jobber var en produktsjef utålmodig, og ville ikke vente lenger på å få utviklingsprioritet. Uten teknisk støtte fra vårt tekniske team startet han utvikling og drift via et tredjepartsfirma. Løsningen som ble utviklet ble plugget inn i våre eksisterende nettsider, og tusenvis av samtidige brukere tappet det lille datasenteret for all kraft. Resultatet var en ydmyk produktsjef, og en underleverandør uten et fungerende driftssenter.

Men det er ikke kun IT bransjen som har dette problemet. Jeg kunne lese med interesse om nye Riksveg 2 som allerede er ødelagt av telehiv. Årsaken er tilsynelatende at de som lager veien ikke skal drifte den. De velger dermed de billige løsningene, mens driftsbudsjettene blir høye.

Det er for meg et paradoks at skillene mellom drift og utvikling fortsatt er så store. Mange velger å outsource enten driften eller utviklingen (dette blir en senere blogg artikkel), med store kostnadsmessige konsekvenser. Dessverre er det veldig vanskelig å måle kostnaden av dårlig kommunikasjon og forståelse mellom drift og utvikling. Derimot kan vi bli inspirert av selskaper som Google og eBay, som begge har sett dette. EBay har sterkt fokus på å utvikle for effektiv drift. Google har valgt å automatisere og profesjonalisere driften i så stor grad som mulig. Vi kan også bli inspirert av Intel (Open Innovation av Henry William Chesbrough), hvor inspirasjonen bak etableringen var å lage et selskap med minimal barriere mellom forskningen og produksjonen. Resultatet er innovasjoner som mikroprosessoren og EPROM, og et selskap som raskere enn noe annet klarte å omgjøre forskning til massemarkedsprodukter.

Dermed går min oppfordring til Norge: Tear down the wall!!

2 kommentarer:

  1. Bra innlegg! Begynner men å lete, finnes det mange eksempler på underfokusering på drift. Se for eksempel på skolene.

    SvarSlett
  2. Takk Niklas! Man kan jo misstenke skolene for å mangle driften totalt! Som deltager i en statlig referansegruppe for smidig prosjektstyring, forsøkte jeg å argumentere for større driftsfokus i utviklingsprosjekter. Mine tanker fikk usedvanlig liten gjenklang hos de andre, som ikke skjønte hva drift hadde med utviklingsprosjekter å gjøre.... så det er en lang vei å gå!

    SvarSlett