Så du tror du kan forvalte?

Her brukes begrepet “forvaltning” slik det brukes i IT-bransjen. Det dreier seg om vedlikehold av og videreutvikling av eksisterende systemer. Men… vedlikehold høres litt defensivt ut. La oss heller tenke forbedring! Forvalter du et system, så skal det minimum fungere like bra i fremtiden, men aller helst bedre.

Hvordan havnet du her?

La oss først tenke over hvordan du havnet i rollen som forvalter. Noen hadde i sin tid et behov, og fikk laget et eller flere systemer. Kanskje var du involvert i dette arbeidet, kanskje ikke. Men det er egentlig irrelevant, for det viktige nå er at systemeieren har valgt nettopp deg til å forvalte systemene - systemeieren er nå din kunde. Rollen du har fått bør egentlig ses på som en ære. Det innebærer at kunden har vist tillit og valgt nettopp deg til å ta vare på systemene deres. Dette kommer med en forventning om at du sørger for å holde dem ved like, gjøre nødvendige oppgraderinger og tilpasninger når omgivelsene endrer seg, rette feil som oppdages, gjøre utvidelser av funksjonalitet, gjerne forbedring av ytelse, samt kontinuerlig generell forbedring av systemenes kvalitet. Ikke nok med det, du bør også hjelpe kunden med å forstå kundens egne behov, du bør kunne bidra i forbindelse med kommunikasjon med kundens kunder eller brukere av systemet, og gjerne selv komme med innspill til forbedringer av reell verdi. Skjønner du ditt fulle og hele ansvar, så er du allerede på god vei til å fortjene tilliten du er vist!

Mye av essensen i foregående avsnitt er i praksis å holde kunden fornøyd. Så, hva kan du gjøre for å holde en kunde fornøyd?

“Bevis din uskyld”

Irriterende nok kan det fra tid til annen dukke opp problemer. Det kan enten være noe som rapporteres av brukere av systemet, fra systemer som integrerer mot dine, eller fra systemer som dine har integrert mot. Eller fra andre potensielle kilder. I alle tilfelle, hvis kunden tror feilen ligger i systemene du forvalter, så står du i fare for å få en misfornøyd kunde. Dermed burde strategien være å bevise din uskyld, og gjerne så fort som mulig, for å unngå at kunden får smake på følelsen av misfornøydhet. Dette kan innebære å hive det du har i hendene i øyeblikket, for å feilsøke kjapt. Håpet er selvfølgelig å komme opp med en logg eller en troverdig forklaring som viser at dine systemer har oppført seg korrekt. For i så fall har du vist kunden at det er noen andre sitt problem, og du går fri.

Nettopp. Men hva løste du i forrige avsnitt? Ingenting. Det rapporterte problemet er fortsatt et problem, og det er god sjanse for at ingen er nærmere å finne ut av det. Kanskje effekten er at det inntil videre ikke er mulig å bruke dine systemer tilfredsstillende. Da har kunden hatt svært liten nytte av din innsats. Hva med heller å være hjelpsom og proaktiv? Innse at det er helheten som teller, og at intensjonen med systemene faktisk må opprettholdes.

Helhetlig feilsøking

Men hva kunne du gjort forskjellig, da? Du fant jo logger som viste at feilen ikke lå hos deg. Vel, kanskje er det ikke så mye som skal til. Du kan bruke den informasjonen du allerede sitter på til å komme med antakelser om hvor feilen faktisk ligger. Kan det være hos en leverandør av data? Kan det være i en database? Kan det være brukerfeil? Feil i integrerende systemer? Misforståelse rundt avtalte dataformater? Nettverkskonfigurasjon? Slike detaljer kan være svært besparende for andre som må lete etter feil, og kanskje går det raskere å få tak i rett person. Kanskje vet du selv hvem som bør kontaktes, og kan hjelpe til med det også. Og fortsatt er det en skjult bonus her: Ved å øke din egen bevissthet rundt “helhetlig feilsøking”, så øker din innsikt i helheten, og din forståelse for hvordan alt må henge sammen og hva som kan gå galt. Kanskje du til og med blir bedre i stand til å oppdage og kjenne igjen liknende feil i fremtiden.

Skal vi også ta med et par “bonuser for viderekomne”? En god forvalter har gjerne en kontaktliste tilgjengelig for hele teamet, der man kjapt kan finne ut hvem som bør kontaktes i hvilke tilfeller. Og hva med å forbedre overvåkning av både egne systemer, og de nødvendige integrasjoner? Jo tidligere et problem fanges opp, jo mindre forstyrrelser vil det skape!

Men… til nå har vi antatt at feilen man lette etter ikke lå i dine systemer. Sett at den gjorde det, hva da? Jo, da må du passe på å bevise at feilen har eksistert siden før din tid, for da har du jo fortsatt ikke gjort noe feil! Øh… Vent litt. Hva hjelper det kunden at det ikke er din feil? Ingenting. Alle feil/svakheter i systemer du vedlikeholder bør helst oppdages og registreres på eget initiativ, som effekt av at du forvalter systemene, og kunden bør informeres. Så kan kunden på sin side prioritere om dette er noe som må fikses, eller om man kan leve med risikoen/svakheten - i så fall en kalkulert risiko, hvilket jo er tillat. Men gjør en innsats for å forklare risiko og effekt!

Fortell hvor dumme feil de har gjort

I vår bransje skjer det skremmende ofte at folk er dumme. Det finnes mang en vits om brukere, og PEBKAC (problem exists between keyboard and chair) er jo et innarbeidet uttrykk. I denne sammenheng kan vi utvide brukerbegrepet til å gjelde både tradisjonelle faktiske brukere, men også utviklere og forvaltere av andre systemer. Ved integrasjon mot dine systemer er det naturligvis mye som kan gå galt, spesielt hvis utviklerne ikke vet hva de driver med. Og for ikke å snakke om de tullete feilene i systemene du selv måtte integrere mot!

Så, igjen, når noen gjør feil, så har det ingen verdi bare å fortelle dem at de gjør det feil. Du bør minimum forklare hva som er riktig måte å integrere på, og fortell gjerne om mulige alternativer. Men, hva mer kan man gjøre? Kanskje vi skulle innsett at en potensiell årsak til «dumme feil» er at dokumentasjonen, som du selv forvalter, ikke er så god? Og kanskje den ikke er så lett å finne engang? Hm, du er ikke så høy i hatten lenger? Det er godt, nå kan du benytte anledningen til å forbedre dokumentasjonen! Nå vet du jo til og med hva det var som var vanskelig.

Er vi i mål nå, eller går det an å gjøre det enda bedre, mon tro? Hva med å tenke litt fremover. Nå har du fått innsikt i hvor noen støtte på et problem. Da vet du hva de holder på med akkurat nå, og du kan også gjette på hva som blir neste utfordring. Kanskje du kan gi et par hint om det med en gang, like gjerne? Og et par ord om den overordnete veien mot målet? Dette fører dem raskere frem, og NÅ har du skapt verdi for kunden!

Hva så med måten man kommuniserer på? Selv om dine intensjoner nå er gode, så er det ikke sikkert det er så hyggelig for mottaker å få høre “du har gjort feil”, med kopi til kunden, og gjerne mottakers kunde også. Gjør det gjerne til en vane å tenke over hvordan du kunne ha likt å få en slik mail. Som alternativ til “du sendte inn feil verdi i felt X”, hva med “denne funksjonen virker sånn-og-slik, og man kan enten hente relevant verdi fra Z eller utlede selv fra Y”? Bygg det hele opp pedagogisk og høflig, uten å være nedlatende.

All kommunikasjon blir jo faktisk også en del av din kundes omdømme. Kan være greit å huske på.

Mål “suksess”

Det er jo kjekt å ha litt tall på hvor flink du er, gjerne sammenliknet med andre avdelinger. Hvordan kan du ellers bli verdsatt skikkelig, hvis alt bare blir subjektivt? Kanskje andre har kunder som av natur er mer fornøyde og skryter mer? Eller kanskje det til og med er kunden selv som ønsker et objektivt mål av din forvaltning? Mange firmaer har derfor innført ulike mål på suksess.

Siden vi allerede har vært mye inne på kommunikasjon, hva med det populære målet av svartid på henvendelser? Kanskje er det til og med kontraktsfestet både når du skal ha sendt et første svar, og når en løsning skal være klar? Greit, sett at en mail kommer. Det første du da gjør er å halvskumme gjennom et par avsnitt, og så skrive en setning om at du er på saken. Så kan du glemme den mailen en stund, inntil saken faktisk må være løst. Dette blir jo en fantastisk score i henhold til suksesskriteriene.

Og verdien for kunden? Ingen. Ikke mye, i hvert fall. I verste fall negativ effekt, hvis du til enhver tid lar deg forstyrre av mail, og avbryter det du driver med for å sende et kjapt, intetsigende svar. Ofte kan det være greiere å ta seg tid til å skjønne hver enkelt henvendelse før svar sendes. Kanskje burde henvendelsen videresendes til noen andre, eller en oppgave som tar litt kalendertid må settes i gang. Jo tidligere det skjer, jo bedre.

Dette betyr ikke at det aldri er riktig å sende et kort svar først. Har du mye i hendene, eller flere henvendelser kommer samtidig, så er man nødt til å komme seg gjennom alt i en eller annen rekkefølge. Og noen henvendelser tar tid å svare på, kanskje er det mange spørsmål, kanskje må det forskes en del på noen av dem. Strategien da kan være å sende et svar med den informasjonen man innledningsvis har, og opplysning om at man trenger noe mer tid på resten. Ikke bare auto-reply, dog, men et svar som inneholder noe informasjon. I mange tilfeller utgjør nok ikke dette noe så stor forskjell, mens i andre tilfeller kan det hende mottaker faktisk fikk nok informasjon til å kunne jobbe videre. Dette er da reell verdi for din kunde.

Hva med andre suksesskriterier, da? En annen populær måling er “hvor mye feil er det i systemene”. Effekten av å legge vekt på dette kan fort vekk være at du legger enorm innsats i å unngå eller fjerne feil. Og det er jo bra! Ofte, i hvert fall - men kan det være at du bruker altfor mye tid på dette? Og dermed er konstant forsinket i arbeidet ditt? Eller at du dropper mye funksjonalitet, fordi det ikke ble tid til det? Kanskje det ikke ga så mye verdi for kunden likevel, da? En balanse er nok tingen, og da er det greit å kjenne din kunde og dennes behov.

Et annet suksesskriterie kan være leveransetidspunkter. Bieffekt av det kan være at funksjonalitet blir nedprioritert, og feil oppdages ikke. Hm, hva med å måle antall saker som blir satt i produksjon, da? Vel, da bruker du gjerne mye krefter på å dele opp større saker i mindre saker, så det ser mer ut - eller du prioriterer småsaker fremfor de viktige større sakene. Men av og til kan man ikke bare fokusere på lavthengende frukt…

Moralen er: Vær forsiktig med “objektive” suksesskriterier!

For øvrig, i litt større team, så er det ikke uvanlig at flere i parallell begynner å jobbe med å svare på henvendelser, om man ikke har en strategi for koordinasjon. Det er jo dumt om både kjappe Kjartan og ivrige Iver begge undersøker det samme og skriver det samme svaret. Enda verre er det om den ene faktisk svarer feil. Det er en ærlig sak å ta feil i ny og ne, men det virker mer profesjonelt med ett feil svar først, for så å komme med en senere korreksjon, enn å si to forskjellige ting og kanskje så begynne å unnskylde teammedlemmer. Ulike strategier kan være å tilordne saker til ansvarlige, hvis man har verktøy for det, eller la det gå på rundgang i et team å ha hovedansvar for å svare eller delegere oppgaver. Ellers er en mulig strategi også å annonsere internt i teamet at “denne svarer jeg på”, så vet alle at det da snart kommer et svar og man trenger ikke selv å bekymre seg.

Et for øvrig glimrende verktøy for sporing av og delegering av oppgaver er Altassian Jira. Man kan også få automatisert det slik at mail til en support-adresse automatisk oppretter en sak i Jira.

Skjul uvitenhet

Oi, plutselig dukket det opp et spørsmål du ikke kan svare på. Og du burde egentlig ha kunnet svare. Hva da? Jo, det finnes ulike strategier for å skjule sin uvitenhet! En populær strategi er å vente lenge før man svarer på henvendelsen, og da enkelt og greit spørre tilbake “Trenger du fortsatt svar på denne?”. Er du heldig, så er det ikke lenger nødvendig!

Den strategien fungerer ikke alltid, og man kan ikke bruke den hver gang heller. En annen strategi er å gi litt ulne svar. I stedet for å svare direkte på spørsmål, så kjører du “politikerstrategien” med å svare på noe litt annet, eller komme med generelle vendinger for å dekke over hva du ikke kan. En variant av denne strategien er å komme med “kanskje-forslag”, som “kanskje det virker hvis du prøver å gjøre litt mer sånn”. Har du flaks, så virker det faktisk, eller mottaker kommer på sporet av noe selv.

Samtidig, felles for alle strategiene så langt, er at folk lærer seg at det ikke er så stort poeng å kontakte deg. Dermed vil det bli færre henvendelser fremover. Folk vil prøve å finne alternative kilder til støtte, eller bruker noen ekstra dager på å prøve å løse ting på egenhånd. Vinn-vinn for deg! Men ikke for kunden. Og dermed ikke for deg heller, egentlig.

Av og til er det ikke til å komme utenom at noe er vanskelig å svare på eller løse, og da får du bare la det gå som en lang oppgave over tid, som du vender tilbake til i ny og ne. Men sjansen er jo stor for at du også finner løsningen etter litt forskning. Råtipset da er naturligvis å oppdatere dokumentasjonen med funnene dine, så slipper du eller andre å gjenta samme forskning senere! Dette kan omfatte selve feilsituasjonen, men også generell kunnskap om domene, system, integrasjon eller relevante detaljer.

Avsluttende tanker

Underveis her har jeg tidvis fokusert mye på feil og feilsøking, og å støtte andre med deres integrasjoner mot dine systemer. Men det er selvfølgelig ikke bare det forvaltning dreier seg om. Det er ikke slik at når ingen rapporterer noe feil, så skal du bare sitte der og ikke gjøre noe. Det er i slike gode situasjoner du har ro til å vurdere hva som er best å gjøre med systemene fremover, det er nå du kan både foreslå og implementere gode forbedringer.

Jeg har mest fokusert på holdning og helhetsbilde for en god forvalter. For mer type praktiske råd, så har jeg også laget en slags huskeliste for en god forvalter. Bruk den gjerne som inspirasjon eller oppslagsverk til forbedring av egen prosess. Håpet er dog at du selv innser hvilke valg du bør ta vedrørende organisering, prosess og verktøy, når du kommer dit at du reelt ønsker å være den best mulige forvalteren av din kundes systemer!

For mer motivasjon, les også Hans-Ove sin bloggartikkel om forvaltningsgjeld.

God forvaltning!