Huskeliste for den gode forvalter

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.

Hvis alt du leser her er selvfølgeligheter for deg, så er du sannsynligvis allerede en knakende god forvalter. I motsatt fall, så får du kanskje noen innspill til hva du kan forbedre. Nettopp det er for øvrig mye av kjernen i forvaltning, å gjøre ting bedre.

1. Å forvalte systemer er en ære. Fortjen tilliten!

En systemeier, som regel en kunde, har vist tillit og valgt nettopp deg og ditt team til å ta vare på systemene deres.

2. Skjønn ditt fulle og hele ansvar

Man bør også hjelpe kunden med å forstå kundens egne behov, man 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. «Få kunden til å ta de gode valgene».

Jeg har skrevet mer om din rolle og ditt ansvar som forvalter i "Så du tror du kan forvalte?".

3. Kjenn systemet, omgivelser og integrasjoner

Ting som systemskisser bør finnes, og gjerne henges på veggen eller være synlig på annet vis. Det samme gjelder beskrivelser av oppsett av utviklingsmiljøer, beskrivelse av kodeprosessen, samt hvordan deploye til ulike testmiljøer, og eventuelt prodsettingsrutiner eller leveranserutiner.

4. Vit hvor eget ansvar begynner og slutter

Er det for eksempel andre som har driftsansvaret, så bli enige om hvordan overlevering foregår, hvordan prodsettinger planlegges og avtales, hvordan man får tilgang til å lese logger og feilsøke etc.

5. Men se gjerne lenger enn egen nesetipp!

Din innsikt kan hjelpe mange involverte aktører, selv om det ikke er i dine systemer et eventuelt problem ligger. Det overordnete målet er at alle systemer skal fungere, og alle skal få gjort det de prøver å få til. Man er på blindspor om motivasjonen utelukkende er å «bevise sin egen uskyld».

6. Positiv og hjelpsom kommunikasjon

Hvis noen spør hva de har gjort feil i integrasjonen mot ditt system, tenk på hvordan du formulerer svaret. Heller enn å svare "Du har gjort X feil", kan svaret vris til å foreslå endringer som vil fungere, og kanskje forklare hvorfor funksjonaliteten må være som den er. Du har da ytt mer bistand og ikke hengt ut noen som dum – alt dette blir jo også en del av kundens omdømme.

7. Wiki for dokumentasjon

Wiki-type verktøy egner seg godt for dokumentasjon som ikke kan legges i selve koden. Typiske Word-dokumenter kommer fort i usynk,der ikke alle har siste versjon, og ikke alltid er lett tilgjengelig fra der man der her og nå. Wiki, derimot, aksesseres enkelt via web, og har også vesentlig bedre sporing av differanse mellom versjoner.

8. Overordnet dokumentasjon

Et team vil alltid ha utskiftninger fra tid til annen, ergo bør det finnes overordnet dokumentasjon som gir en god pedagogisk introduksjon til forvaltningen.

9. Dropp «mellomnivå»-dokumentasjon

Her går det med enorme mengder tid og innsats, og mellomnivå-dokumentasjonen blir fort utdatert. Dokumentasjon/kommentarer i kode som supplement til overordnet dokumentasjon er gjerne ofte et bedre alternativ. Eksempler på mellomnivå kan være klassediagrammer, eller generell forklaring av kode.

10. Men dokumentér detaljer

For eksempel domenespesifikk kunnskap, ustandard løsninger og integrasjoner, spesielle datakrav, oversikt over relevante IP-adresser, brannmur, konfigurasjon og ikke-selvforklarende konfigurasjonsparametre, kontaktpersoner etc. Ofte er lister godt nok, eller eksterne lenker, mens av og til må man skrive selv.

11. Dokumentér det du måtte forske på

Sjansene er gode for at du eller noen andre vil lure på det samme senere en gang.

12. Secret server for konfidensiell informasjon

Med dette menes servere som kjører internt og er beskyttet med pålogging, og hvor man da kan tilgjengeliggjøre for eksempel passord og annen konfidensiell informasjon for hele team.

13. Versjonskontroll etc: Må være lett å få tak i produksjonsversjonen

Du bør alltid ha en enkel strategi for å få tak i produksjonsversjonen av kode, samt å kunne gjøre hasteendringer på denne.

14. Tenk gjennom hvordan du ønsker å organisere saker

I forvaltning vil det alltid være mange oppgaver, med både korte og lange frister. Det bør også enkelt fremgå om en sak er noe kunden venter på, noe kunden har sagt kan være kjekt å ha, et ønske fra brukere, eller rett og slett potensielt gode idéer som forvaltningsteamet har kommet opp med - uten at de nødvendigvis er akseptert av kunden ennå.

15. Påminnelser

Uavhengig av prioritet må noen saker gjøres på et gitt tidspunkt, for eksempel sertifikatbytter. Legg gjerne opp varsler på gitte datoer.

16. Frigjør deg fra «leveranser»

Dette er en gammeldags tankegang, som dog ofte fortsatt er nødvendig. Men visjonen bør være å frigjøre seg fra leveranser. Får man innordnet seg med kort vei fra utvikling til prodsetting, så kan i praksis enhver oppgave være sin egen “leveranse”/prodsetting.

17. Automatisering

For å hjelpe forrige punkt: Automatiser kjøring av enhets- og integrasjonstester, gjerne også ytelsestester, bygging og pakking, og om praktisk mulig også selve produksjonssettingen.

18. Planlegg support

Kanskje er det lurt med et sporingssystem á la det man bruker for utviklingsoppgaver. Men det er mye som kan gjøres selv med mailbasert support: En felles adresse som går til hele teamet er en god start, samt da å huske kopi av alle mailer til denne adressen. Sørg for å avtale hvordan man kan vise innad i teamet hvem som har/tar ansvar for en sak.

19. Unngå å glemme saker

Bruker man mail heller enn sporingssystemer, så finnes det også enkle triks for å huske å følge opp saker: Markér mail som uleste inntil de er håndtert, bruk oppfølgingsflagg eller tidsbestemte varsler, fest mail på toppen av innbokser etc.

20. Svar tidlig

Av og til tar det lang tid å forberede et svar, i det minste om det er mange spørsmål som skal besvares. I slike tilfeller er det lurt å sende et initielt svar med det man har av foreløpig informasjon (men reell informasjon, ikke «auto-reply»). På denne måten har avsender fått svar på noe, og har kanskje nok til å jobbe videre, mens de venter på komplett svar.

21. Unngå enkeltpersoners eierforhold til kode

Smertefull rullering kan være nødvendig for å få til dette, men i lengden vil det som regel lønne seg.

22. Skill produksjon og test

Så langt det er mulig, lag tydelige visuelle skiller mellom produksjon og test, for å unngå uhell. Bruk for eksempel rød bakgrunn i terminalvinduer.

23. God logging

Unngå type «det funker hos meg» - logg slik at det er mulig å skjønne hva en bruker har gjort, og hva som skjedde. Alternativt, sørg for at det er mulig å simulere en gitt brukers opplevelse i produksjon.

24. Overvåkning – vit om applikasjonene fungerer

Mye kan gå galt, til og med når en prosess tilsynelatende kjører, så sørg for å oppdage/bli varslet når dette skjer. Det kan også være relevant å overvåke eksterne systemer man er avhengige av.

Denne huskelisten er hva jeg kunne komme på av ting jeg enten gjør, eller ønsker å gjøre. Men det er gode sjanser for at jeg har glemt viktige punkter, så jeg inviterer dere, kjære lesere, til å legge igjen en kommentar. Gode innspill mottas med takk – i en ekte forvalters ånd. I alle tilfelle håper jeg du og dine kunder kan ha glede av listen. 

Les også "Så du tror du kan forvalte?", hvor jeg skriver om rollen og ansvaret man har som forvalter.