Det er aldrig sjovt, når en medarbejder stopper. I en IT-afdeling kan det tilmed have store konsekvenser for driftsstabiliteten eller hastigheden på den nødvendige IT-udvikling.
Hos CapaSystems oplever vi heldigvis kun meget lille udskiftning blandt medarbejderne. Alligevel tager vi opgaven alvorligt og sørger altid for, at vigtige udviklingsprojekter ikke falder mellem to stole, hvis en vigtig medarbejder trækker stikket.
Når en IT-medarbejder i udviklingsafdelingen forlader foretagendet, er der typisk to risikotyper, som er vigtige at håndtere:
- Tabet af bruger-/kundeviden, som medarbejderen har bygget op.
- Tabet af teknisk viden om de løsninger, som medarbejderen har arbejdet på.
I denne artikel får du nogle bud på, hvordan du kan minimere disse risici.
Brugerkendskab på rekordtid
Slutbruger- og kundeviden tager typisk lang tid at tilegne sig. Du skal have mødt kunderne, talt med brugerne og testet mange løsninger, før du kender dine brugeres faktiske præferencer. Derfor kan det også være enormt svært at indtage rollen som ny IT-udvikler, hvis du overtager pladsen fra en garvet medarbejder med mange års virksomhedsspecifik erfaring.
Selvom brugerkendskab og viden om brugernes behov bygges op over tid, kan du som IT-chef alligevel hjælpe dine nytilkomne udviklingsmedarbejdere til at skyde genvej i indlæringen.
Brugerpersonaer kickstarter forestillingsevnen
Først og fremmest kan du som IT-chef sørge for, at jeres viden om brugerne er nedskrevet og formaliseret. For at give dine medarbejdere et klart billede af den typiske bruger er det en god idé, at I benytter jer af såkaldte ”brugerpersonaer”, som blandt andet kendes fra Scrum-metoderne.
I sin grundessens er en persona en fiktiv beskrivelse af en typisk bruger. Beskrivelsen indeholder typisk viden om den typiske brugers alder, uddannelse og brugsmønstre, så det er let for din medarbejder at danne et billede af brugeren.
En brugerpersona sætter gang i dine medarbejderes forestillingsevne og empatiske evner. En persona betyder, at din nytilkomne medarbejder selv kan forestille sig, at det eksempelvis er problematisk at lave skrifttypen for lille eller knapperne for små, hvis dine typiske brugere er over 50 år. En sådan fejl vil for mange 50-plus-brugere nemlig betyde, at de skal finde læsebrillerne frem.
En sådan persona er faktisk også rigtig god at bruge, hvis I har brug for at outsource nogle af jeres IT-aktiviteter.
User Journeys udpeger brugerens problem
Ligesom personaen giver forståelse for slutbrugeren, kan du også arbejde med brugerrejser (User Journeys), som beskriver, hvad det er, din bruger ønsker at lykkes med. En brugerrejse indeholder en række trin, der bedst viser, hvordan brugeren kommer igennem produktet. Typisk vil en brugerrejse indeholde op til 15 trin, der bedst repræsentere de scenarier, hvor en bruger interagere med det, du designer.
Når I nedskriver både brugerpersonaen og de brugerrejser, de ønsker, giver du nye medarbejdere et forspring i forståelsen af slutbrugeren. Noget, som gør, at I kan holde en høj standard for brugervenligheden af de services, I udvikler, selvom en erfaren medarbejder har fundet nyt job.
Teamwork sikrer kompetencernes overlevelse
Når travlheden melder sig, og deadline for dit udviklingsprojekt kommer hastigt nærmere, kommer man let til at vælge de løsninger, som hurtigst kan løbe projektet i hus. Det betyder ”alle mand ved årerne” og fuld fart frem. Men selvom effektivitet er vigtigt i nutidens IT-afdelinger, så er det ikke nødvendigvis svaret her.
I udviklingsprojekter betyder den øgede hastighed nemlig ofte, at kvalitetssikringen går fløjten. Ikke nødvendigvis den kvalitetssikring, der handler om, at slutproduktet er i orden, men den kvalitetssikring, der betyder, at andre IT-medarbejdere kan overtage en opgave fra en kollega.
Det er nemlig også kvalitetssikring, at der er mere end én medarbejder i IT-udviklingen, der har kigget på den kode, der er skrevet. Som forstår koden og er enig i måden, den er skrevet. Det er kvalitetssikring, fordi det sikrer kvaliteten og supporten på de programmer, I har udviklet, også selvom en medarbejder stopper.
To kokke om koden
Hos CapaSystems anbefaler vi altid, at minimum to andre medarbejdere i afdelingen kender din kode og kan stå inde for den kodning, der er lavet. At have flere hjerner til at kigge med sikrer ikke blot den umiddelbare kodningskvalitet, men også at den tekniske forståelse ikke går tabt, når du mister en medarbejder.
Derfor må du aldrig gå på kompromis med denne type kvalitetssikring. Heller ikke selvom det er svært, når deadline presser. Hvis tiden er knap, er det altid bedre at prioritere sine opgaver og vælge noget fra, så systemet også er sikret for fremtiden.
Overlevering af viden er et ledelsesansvar
Som IT-chef er det dit ansvar at sikre, at jeres udvikling ikke sætter sig fast, hvis en kernemedarbejder pludselig stopper. Det er dit ansvar at sikre, at både udviklingsprojekterne kan fortsætte, og at der fortsat kan ydes support på IT-løsninger, som allerede er implementeret i virksomheden.
For at sikre din IT-afdeling mod fatale kompetencetab må du derfor gå forrest og insistere på, at brugerrejser, brugerpersonaer og tekniske wire-frames er dokumenteret, så nye medarbejdere kan rulles ind hurtigt.
Hvad er din medarbejder-plan-B?
Men som IT-chef er det ikke kun den formelle nedskrivning af jeres udvikling, der skal være i orden. Du må også have gennemtænkt de forskellige scenarioer, der kan opstå, når en medarbejder stopper.
Du skal vide, hvad der skal ske, hvis John, med 15 års erfaring, pludselig vil prøve kræfter med en ny virksomhed. Hvem skal holde nøglerne til hans projekter? Og hvem skal svare på spørgsmålene, når de kommer. For de kommer, spørgsmålene.
I en verden, hvor dygtige IT-medarbejdere er ombejlede, bliver du som IT-chef derfor nødt til at have en nødplan klar, til når – ikke hvis – en af dine kernemedarbejdere pludselig meddeler, at han har søgt andre veje. Du bliver nødt til at vide, at en anden kan overtage opgaverne, og du skal have forberedt slagets gang både på kort og lang sigt.
Med god og forståelig dokumentation af jeres udviklingsprojekter og med ”nødplaner” klar i baghånden, kan du som IT-chef sikre dig maksimalt mod de konsekvenser, et stort kompetencetab kan medføre. Og det er en af dine primære opgaver: At sikre din virksomhed mod kvalitetsudsving i jeres IT-udvikling.
