«Programmerere forstår ikke brukernes behov” Jeg måtte slutte å lese halvveis igjennom, ble så provosert. Lang, gjennomtenkt artikkel om IT i offentlig sektor. Det koster mer enn det sparer og gjør arbeidshverdagen vanskeligere enn før. Mange gode poenger. Gode relevante eksempler. (Her er den, for de som betaler for Dagens Næringsliv: http://www.dn.no/magasinet/2015/03/31/2128/Teknologi/ute-av-ctrl) Men å skylde på programmererne? SOM OM VI HAR NOE SOM HELST VI SKULLE SAGT OM HVORDAN OG HVA SOM BLIR LAGET?!?! …provoserer meg altså, bittelittegrann liksom.
Jeg har akkurat jobbet som programmerer i offentlig sektor i 2.5 år. Ganske kjapt begynte jeg å reagere på oppgaver jeg ikke følte var helt hensiktsmessige. «Hvorfor (I ALLE DAGER) skal vi gjøre dette?» «Dette her er jo direkte skadelig!» «Hvem har bestemt dette?» Det ble tidlig klart at ingen i IT-avdelingen følte noe særlig ansvar for selve oppgavene. Man himlet med øynene og sa «Ja, sånn er det bare. Tro meg, vi har prøvd og prøver fortsatt å si ifra, men det nytter ikke». Jeg begynte å foreslå at vi måtte sette opp mer og bedre kommunikasjon med departementet. Ble ganske overrasket over svaret jeg fikk: «Kommunikasjon med departementet? Jammen vi har ikke lov til å kommunisere med departementet» Helt sant. Det var det en eller annen i 4. etasje som visstnok kunne gjøre, men ingen visste helt hvem.
I hele tiden jeg var tilsatt i staten så jeg noen fra departementet mitt en hel gang. Etter valget kom den nye ministeren innom kontoret. Det ble holdt veldig korte introduksjons og hilse-presentasjoner og han var ute av døra igjen en halvtime etter han var kommet. Men det er fortsatt mye mer enn det jeg fikk sett brukere av saksbehandlingsløsningene jeg jobbet på. De så jeg aldri. Tross mange forslag og forespørseler fikk jeg aldri oppleve hvordan brukerne av det jeg lagde jobbet. Brukerstøtte-systemet var vi også skjermet fra. Ingen av oss fikk vite hva det var folk klaget over. Eller kanskje roste oss for. Hvem vet. Vi var helt isolert.
OGSÅ SKYLDER DERE PÅ OSS! Det er PROGRAMMERERNE som ikke skjønner brukerne. Tror dere vi bestemmer hva vi lager? Tror dere vi får bruke programmene vi lager? Tror dere vi får møte brukerne? Tror dere vi får høre brukerservice-henvendelsene som sendes inn? Vi gjør ikke det! Vi får bare tilgang til ferdiglagde oppgaver i et prosjektstyringsverktøy. Som enten blir tildelt oss, eller hvis vi er veldig heldige kan vi kanskje velge hvilke oppgaver vi får lov til å løse. «Vis ligningsinformasjon på skjermbilde X» «Det skal ikke være lov til å registrere en klage etter klokka 2 på en onsdag, med mindre saksbehandleren jobber for kommunen, søkeren er ung og ufør i overgangsordningen fra 2009, det var skuddår i fjor og bikkja til naboen bjeffer 3 ganger før soloppgang»
Dette er det vi har å gå på! Vi får ingen anledning til å sette oss inn i brukerens situasjon. Det har andre gjort for oss. Gjerne FØR prosjekt-beskrivelsen gikk ut på anbud for 5 år siden!
Også skylder dere på oss! Vær så snill.
Jeg gjorde ikke annet enn å BE om at vi ikke VÆR SÅ SNILL kunne FÅ LOV til å bedre sette oss inn i hvordan brukerene våre hadde det. Jeg burde jo selvsagt bare gjort det likevel. Burde bare troppet opp på saksbehandlernes kontorer rundt omkring. Burde også troppet opp i KMD og nektet å gå før jeg fikk snakket med noen av de som var ansvarlige. Skammer meg litt over at jeg ikke bare gjorde det. Idiot som jeg var satset jeg heller på at ledelsen kom til å høre på mine forslag. Jeg burde selvsagt tatt på meg det ansvaret selv. Føler jeg sviktet det norske folk litt der. Beklager.
(Jeg er forresten ikke helt komfortabel med å klage over min tidligere arbeidsgiver på denne måten. Når det kommer til IT i offentlig sektor er jeg overbevist om at vi var av de aller beste IT-avdelingene. Det mener jeg. Vi leverte fungerende software. Vi hadde ingen skandaleprosjekter til flere hundre millioner som bare måtte skrotes. Det er masse bra folk der jeg var. De har mye de kan og burde være stolte av. Kanskje viktigst av alt er at ledelsen har forstått viktigheten av å ta ansvar for utviklingen. Konsulenter blir brukt, men de tas inn som en del av det interne utviklingsmiljøet. Vi var ETT team som jobbet SAMMEN. Ikke en kunde vs en leverandør, slik offentlig sektor ellers gjerne opererer når software skal utvikles. Jeg har vært med på et slikt «kunde/leverandør» prosjekt som konsulent og det gjør jeg aldri igjen for å si det sånn. Standardkontraktene som brukes av offentlig sektor når de legger softwareutvikling ut på anbud legger opp til en helt hinsides byråkratisk og konfliktfylt prosess. Heder og ære til mine tidligere sjefer for å spare oss og seg selv for dette helvetet.)
Hello world 
Ett av eksemplene i artiklen på DN (F8 er “lagre” i ett program, “slette alt uten å lagre” i et annet) er et av dem som jeg reagerer mest på – hvorfor må alle lage sine egne tastatursnarveier?! Vi har hatt standarder for lagring, åpning og lukking av programmer i årtier etter hvert…
Når det er sagt, kommer jeg nå fra et ganske langt forvaltningssamarbeid med offentlig forvaltning der jeg var leid inn fra et konsulentselskap. Vi jobbet daglig ut fra perspektivet “vil dette gjøre det enklere for brukeren?”. Det målet var langt fremme i planleggingsprosessene og ikke en feature ble implementert uten at spørsmålet ble besvart med et “ja”. Eller til nød “ja, for de fleste”.
Samtidig vet jeg om flere andre prosjekter i samme offentlige etat som ikke har det fokuset, og som bruker må man forholde seg til alle de ulike programmene.
Det er dessverre typisk for både private og offentlige ikt-prosjekter over en hvis størrelse (rart nok ofte når grensen ‘too big to fail’ passeres) at det lages såpass mange lag med prosedyrer at alle former for feedbackloops forsvinner; ingen tilgang på kunder/brukere (de håndteres av kundeansvarlig), ingen tilgang på supporttickets (bortsett fra kanskje 3.linje, når 1. linje har gitt opp og 2. linje har prøvd en omstart); ingen tilgang på beslutningstagere (de sitter i en annen avdeling, du ikke har lov å tale med – som du var inne på); ingen tilgang på arkitektene (de var inne før bestillingen gikk på anbud og er nå helt andre steder i verden). I den situasjonen kan man ikke utvikle god software.
Vi som programmerere sitter igjen med et forferdelig valg:
– Vi kan skrive den koden vi blir bedt om. Det blir det ikke bra brukeropplevelser av den.
– Vi kan insistere på å få endret prosessen. Fungerer kun hvis du får alle interessenter med på det, tror jeg. Det er vesentlig mer vanskelig å endre prosessen enn å endre kode, er min erfaring.
– Vi kan skrive den koden vi tror vil være best ut fra den informasjon vi har. Denne kan være farlig. Både fordi du som programmerer kan komme til å bryte deg mot vedtatte sannheter og fordi du simpelthen kan bli sagt opp for ikke å levere det du skal. Samtidig kan du også være heldig å lage akkurat den tilpasningen som gjør at produktet ikke blir direkte selvmordsinduserende.
Når DN skriver at det er programmerenes feil, er det riktig. Men som du skriver, er det ikke fordi vi egentlig har noe valg.
“Det er vesentlig mer vanskelig å endre prosessen enn å endre kode, er min erfaring.” -> absolutt, men det betyr ikke at vi ikke må forsøke. Jeg tror det er en fare for at litt for mange utviklere (ikke alle) ikke er så opptatt av prosessene – dessverre. Og de gidder ikke å fighte det som må til.
Jeg har troa på å jobbe iterativt også med prosessforbedringer. Hvis du og teamet ditt har en ide om hvordan dere ønsker at prosessen burde se ut, så kan dere forsøke å ta mange små steg. Gjennom å bygge tillit gjennom resultater over tid, tror jeg det også er mulig å endre prosessene.
Den største utfordringen tror jeg ligger i organisasjonsstrukturer, hvor organisasjonen er delt inn i siloer som jobber for isolert, fremfor team som dekker alt fra brukerdialog til drift via utvikling/test).
I en siloorganisasjon blir det vanskelig med feedback og muligheten for læring blir dårlig. Samtidig blir ansvarsfølelsen dårligere jo lenger bort fra brukerne en kommer.
Jeg er helt enig – og har også i mange år forsøkt den strategien med små endringer i en silobefengt offentlig etat. Men når noen av dem som sitter i siloene er tilfreds med å sitte i siloene, og når dem som leder ikt-avdelingen hører på dem som liker seg i siloene sine, er det vanskelig å endre prosessene.
I praksis fikk vi endret mye, internt i teamet, i jobben opp mot produkteiere, i kommunikasjon mot brukere gjennom å levere ofte, i små iterasjoner. Vi fikk kjapp feedback fra alle de viktige aktører og leverte altså verdier for brukerne. Løsningene har fått mye skryt, også i offentligheten.
Mot ikt-avdelingen som tjenesteleverandør, der imot, skar det seg ofte fordi silo-organisering ikke passer godt med kjappe, små leveranser. Å rulle ut en ny tjeneste til brukerne kunne involvere 6-7 ulike siloer, som hver trengte å gjøre 10-15 minutters jobb. En slik utrulling tok gjerne uker. Man lærer over tid å lage utrullinger som treffer færre siloer om gangen, slik at ikke all tiden går med å lage prosess. Automatisering på tvers av siloer er først på vei inn i tankesettet nå nylig.
Det værste er at det er utrolig mange som uttaler seg, som ikke har et snev av forståelse for noen av sidene. JA, det finnes inkompetente både programmerere, mellomledere, interaksjonsdesignere, sjefer og kunder der ute. JA, det blir gjort dumme beslutninger. JA, det blir brukt mye (skatte-) penger på disse tingene. JA, noen av løsningene blir totale fiaskoer.
Men fy faen så mye bra som blir gjort. Kanskje ser det litt skakkete ut, men folk der ute skal VITE hvor bortskjemte vi er i Norge. Vi er – med store forsprang – blant de mer moderne landene i verden når det kommer til offentlige IT-løsninger.
Godt poeng. Men det bra som blir gjort, blir sjeldent omtalt. Verken i media eller internt i enkelte organisasjoner.
Viktig å lære av både de gode og dårlige erfaringene, slik at en kan gjøre mer av det bra og mindre av det dårlige.
Det virker litt som en avsporing – ikke at jeg er uenig…
Poenget til Christin synes å være at prosessene omkring utviklingen forhindrer henne som utvikler i å levere gode løsninger. Uansett hvor kompetent hun selv føler hun er, er hun forhindret i å få tilbakemeldinger som skal hjelpe henne å levere gode resultater for brukerne. Hun skriver at dersom hun fikk tilbakemeldinger underveis og disse tilbakemeldinger systematisk ble brukt til å lage bedre løsninger, ville vi sluppet noen av de fadesene som står beskrevet i DN-artiklen. Men at måten vi i dag lager (offentlige) løsninger innebærer at alle beslutninger er tatt lang tid før brukerne kommer i nærheten av systemet. Så for henne blir det urettferdig å peke fingre på de uskyldige programmerere som ikke kan noe for at produktet virker tungvint i bruk (hvis det er brukbart i det hele tatt).
Løsningen er jo relativt enkel (og jeg er redd det er den enkelheten som forhindrer den i å bli godtatt i byråkratiet – hvordan får man passet inn tre lag med managers her?); lag software i samarbeid med brukerne. Ikke lag big design up front.
Create-Adapt-Repeat.
Mellomledere og byråkrater totalt uten innsikt er på ingen måte et problem som er ekslusivt for offentlig sektor.
De fleste konsulenter i privat sektor måles kun etter hvor mange timer de klarer å fakturere, et system som aktivt belønner middelmådige konsulenter som aldri noensinne klarer å gjøre noe som helst ferdig men bare produserer uendelige mengder med verdiløst papir. Jo mer penger man klarer å vri ut av et statlig prosjekt på denne måten uten at oppdragsgiver sier stopp, jo større hytter og båter kan sjefene kjøpe seg.
Situasjonen er så absurd at det eneste oppdragsgiver kan gjøre er å forsøke å skaffe sine egne ansatte som må kunne akkurat det samme som leverandør, bare for å forsøke å forsvare seg mot den systematiske svindelen. Disse produserer enda mer verdiløst papir og de tilfellene der de faktisk klarer å gjennomføre et prosjekt uten milliardoverskridelser hører vi aldri noe om.
Å kortslutte hele prosessen ved å sette brukere og utviklere i samme rom fungerer fint for mindre systemer, konsulentselskapenes forsvar mot dette er å designe enorme sammenflettede strukturer med lukkede og diffuse standarder der enhver liten endring betyr nye kjempeprosjekter. Målet er å gjøre systemet så komplekst at ingen tør annet enn å følge leverandøren sin anbefaling selv om det innebærer økonomisk selvmord.
Utviklerne er ikke engang med i regnestykket, sånne kan man vel leie inn fra India? Mye billigere, og de sier jo selv at de er like dyktige. Mange av dem er dessuten villige til å se bort fra sånne detaljer som overtid, arbeidskontrakter og pensjonsavtaler.
Pingback: Gigantprosjektet er dødt! Leve gigantprosjektet! | Hello world
Pingback: When big IT projects fail | Christoffer Osland