Vi tror stærkt på at forene kræfterne. Man kan trods alt lære meget af og med hinanden. Desuden er forskellige perspektiver på det samme emne en stor hjælp til at træffe en afbalanceret beslutning.
Udvikling og support er afgørende for at levere de bedste kundeløsninger
Hos Easy LMS er udvikling og support afgørende for at kunne levere de bedste kundeløsninger. De arbejdede allerede sammen, men de var separate teams.
Indtil juni 2021 var det sådan, de arbejdede sammen i en nøddeskal - forenklet og uden nuancer ?. Support var ansvarlig for at betjene vores kunder bedst muligt. De brugte meget tid på at lytte til dem og hjælpe dem med at nå deres træningsmål. En del af dette var at besvare deres spørgsmål i chat eller demo og logge deres fejl og funktionsanmodninger. Bind det op og gå! Så kom produktejeren ind i billedet. Baseret på de oplysninger, som konsulenterne loggede, og hans produktvision besluttede han, hvilken funktion der skulle bygges ved siden af, og præsenterede sin løsning for udviklingsteamet. Udviklerne lavede løsningen - sjældent med hjælp og indsigt fra support - og lancerede den! Til sidst opdaterede konsulenterne alt relateret indhold. Så er det gjort!
Gør mere brug af teamets styrker
Som du kan læse, kunne vi bruge holdenes styrker bedre. Derfor besluttede vi at bringe samarbejdet op på næste niveau. Et nyt team blev født: et problemløsende team, der omfatter medlemmer fra udvikling og support. Desuden er en UX-designer og en Product Owner involveret i teamet.
Interview med team Jabba
I øjeblikket har vi to problemløsningshold: team Jabba (navnet består af alle holdmedlemmernes initialer) og SummerKnowly (opkaldt efter vores maskot). Anna og Joey er medlemmer af team Jabba. Sammen med Communication Owl Caroline fortæller de om detaljerne i det opgraderede samarbejde.
Caroline: Siden juni 2021 har vi haft de problemløsende teams. Anna, kan du forklare, hvordan teamene behandler kundernes spørgsmål i dag?
Anna: "Supporten behandler stadig kundernes spørgsmål; vi er det første kontaktpunkt. Vi besvarer dem og hjælper dem. Hvis en kunde rapporterer en fejl, forsøger vi at reproducere den med hjælp fra udviklingsafdelingen, og hvis det lykkes, logger vi den som en fejl og markerer, hvor meget det haster, og hvor stor effekt den har.
For funktionsanmodninger er det det samme som for fejl, bortset fra reproduktionstrinnet. Vi sender en funktionsanmodning med så mange detaljer som muligt til Productboard, et værktøj til at administrere alle vores funktionsanmodninger. Vores Product Owner Jeroen og UX Designer & Researcher Dyann behandler dem og vejer og vurderer omhyggeligt funktionsanmodningen i forhold til vores virksomheds formål. Det resulterer i en to-do-liste over nye funktioner, der skal bygges."
Caroline: Okay, det ser lidt ud som den gamle proces; desuden er der mere kommunikation og interaktion. Så hvornår kommer udviklingen ind i processen?
Vi bringer forskellige perspektiver ind
Joey: "Lige nu. I stedet for produktejeren er det holdene, der er ansvarlige for, hvad der skal arbejdes med, og hvilken løsning der skal vælges. Fra vores problemløsningsteam er Anna og jeg ansvarlige for at vælge, hvad vi skal arbejde videre med som team. Vi bringer forskellige perspektiver ind her. Anna ved, hvad en kunde har brug for, mens jeg har en god fornemmelse af kompleksiteten i en anmodning."
"Vi prioriterer fejl i forhold til potentielle nye funktioner og beslutter, hvad der skal arbejdes på ud fra, hvor meget det haster. Når vi har valgt, skriver vi problemets aktuelle omstændigheder og resultatet af disse omstændigheder ned, så resten af teamet ved, hvorfor det haster med at løse problemet. Derefter kommer resten af teamet ind for at diskutere løsningen og skrive den ned. Dyann, vores UX Designer & Researcher, deltager ofte i samtalen for at sikre, at den valgte løsning er brugervenlig og let at forstå. Diskussionen er værdifuld på grund af de mange perspektiver, vi bringer ind. Alle har noget at skulle have sagt. Derefter sender vi vores forslag til produktejeren til godkendelse."
Caroline: Får du altid godkendelse med det samme?.
Joey: "Det meste af tiden. Hvis det ikke bliver godkendt, vil Jeroen have nogle spørgsmål, som vi forsøger at besvare i et opkald eller i forslagsdokumentet. Der bliver skrevet lidt frem og tilbage, før vi får grønt lys. Når det er godkendt, skriver vi brugerhistorier (red. en kort skriftlig forklaring på, hvad en bruger ønsker og forventer) og fordeler opgaverne i teamet.
Caroline: Er supporten også involveret i at skrive brugerhistorierne? Før var det kun udviklingsafdelingen, der gjorde det.
Anna: "Det kommer an på, om det er en feature eller en bug. Vi deltager altid i nye features, men det er ikke altid nødvendigt for bugs. Det er relativt nyt for os at skrive brugerhistorier. Så vi arbejder på at blive bedre til det."
"Det, vi også gør, er straks at begynde at skrive det relaterede indhold til den nye funktion. Relateret indhold er etiketterne til administrator- eller deltagergrænsefladen eller hjælpeartikler. Desuden skal vi beslutte, hvilken kundekommunikation der skal udføres, f.eks. meddelelser i produktet, direkte kundemeddelelser osv. Det gør vi sideløbende med, at funktionen bliver bygget."
Caroline: Så den vigtigste ændring er, at support og udvikling vælger et problem og skaber løsningen sammen. I har begge større indflydelse på slutresultatet. Hvordan oplever du denne nye arbejdsproces?
Anna: "Det var helt sikkert en forandring at vænne sig til den nye arbejdsstil med hensyn til planlægning og at arbejde tæt sammen med nye mennesker. Men det var også en fordel. Jeg kan godt lide at arbejde tættere sammen med udviklere, fordi de har forskellige perspektiver på, hvad der skal bygges og hvorfor. Vi træffer mere afbalancerede beslutninger nu. Det hjælper også, at vi kan se på hinanden, hvordan vi arbejder. Før i tiden tog vi højde for problemerne. Vi udførte mere manuelt arbejde, og det blev normen. Udviklere bemærker nemt, hvis manuelt arbejde kan automatiseres eller strømlines. Det ligger i deres natur at tænke på den måde. Deres hjælp har allerede sparet os for en masse tid."
Vi har nu meget mere indsigt i, hvad der faktisk sker.
Joey: "Vi har nu meget mere indsigt i, hvad der rent faktisk sker. Hvordan kunderne bruger vores LMS, hvad der er vigtigt for dem, og hvad der ligger til grund for det. Det føles, som om vi er mere i kontakt med kundernes behov. Så før blev et problem overdraget til os, efter at det var gået gennem flere lag i virksomheden. Vi var i slutningen af processen, så mange vigtige oplysninger gik tabt undervejs, og mange spørgsmål blev ikke stillet. Vi kender systemet teknisk meget bedre; vi ser anderledes på problemer. At være sammen med supporten fra starten giver os mulighed for at stille de spørgsmål, vi har brug for til at opbygge en effektiv og bæredygtig løsning. Vi kan sige, at informationskløften er blevet lukket."
Caroline: Vi laver også kundeinterviews for at forstå vores kunders behov bedre. Jeg går ud fra, at det er meget værdifuldt for det problemløsende team?
Joey: "Ja, det er det! For det, kunderne ønsker, er ikke altid det, de har brug for. Det, de tror, der går galt, er ikke altid det, der skal løses. Det er meget svært at se som udenforstående. Så klientinterviewene er et værdifuldt værktøj til at afsløre underliggende problemer. De giver os også kontekst!"
Der er masser af vidensdeling
Caroline: Okay, tilbage til samarbejdet mellem udvikling og support. Hvordan supplerer I hinanden?
Anna: "Der er en masse vidensdeling. Udover at konsulenterne bringer kundens perspektiv ind, ved vi begge forskellige ting om LMS'et. Det fører til, at vi nogle gange ved, hvordan værktøjet fungerer, og det gør de ikke, og omvendt. Så for eksempel er noget helt indlysende for os (red. support), mens udviklerne ikke troede, at det fungerede på den måde, eller at folk brugte en funktion på den måde. På samme måde kan vi bruge tyve minutter på at replikere en fejl, og hvis jeg sender en besked om det til en udvikler, kender de løsningen med det samme. Så der er lidt af det på begge sider, og nu kan vi dele det."
Caroline: Er der også en ulempe ved at arbejde på denne måde? .
Joey: "Nej, det var et godt skridt at bringe udvikling og support sammen. Generelt er der altid en ulempe ved at ændre sin arbejdsmetode. Man skal vænne sig til det, og det kan føre til nogle frustrationer. Det er tidskrævende. Men det er bare forhindringer, man skal overvinde. Det er ikke en dealbreaker. Vi ønsker ikke at gå tilbage."
Caroline: Kan du uddybe det? Hvad var det mest udfordrende?
Joey: "Den største udfordring var at finde ud af, hvordan vi kunne bruge hinandens styrker på den rigtige måde og ikke spilde hinandens tid. I begyndelsen skete det ofte, at vi havde for mange mennesker med til møderne, som ikke kunne bidrage til diskussionen. Så det var spild af deres tid. Men det modsatte skete også. Vi havde såkaldte mis-møder. Folk kunne have bidraget, men var der ikke. Til sidst klarede vi det ved at kommunikere om vores erfaringer og ved at anvende trial and error-metoden."
Caroline: Anna, hvad har du lært af udviklerne i dit team?
Jeg lærte at strukturere mit daglige arbejde bedre med færre afbrydelser
Anna: "Det er lidt svært at sige. Det var bare for sjov. For det første, på et mere filosofisk plan, er udvikleres arbejde meget mere struktureret end supportarbejde. Jeg lærte at strukturere mit daglige arbejde bedre med færre afbrydelser. Udviklere er meget strikse med deres tid, hvilket er logisk, fordi de har brug for uafbrudt tid til at udføre deres arbejde - det hjælper mig med at bringe det ind i min arbejdsdag. Så jeg har lært at holde min tid og mine grænser bedre. Og på et mere praktisk plan giver udviklerne mig mange tips til fejlfinding, så jeg kan hjælpe kunderne."
Caroline: Og til gengæld, Joey, hvad har du lært af supportkonsulenterne i dit team?.
Joey: "Jeg tror, det er det modsatte af det sidste, Anna lige sagde. Vi havde altid en masse ideer til, hvordan vi kunne løse tingene; vi kunne kun stole på vores viden. Men vi bruger ikke systemet på samme måde som kunderne. Så ved at interagere med supporten lærte vi meget om, hvordan kunderne faktisk brugte systemet, og hvilke løsninger der passede til dem. Før var det bare at gætte og gøre det bedste, vi kunne. Vi inddrager slutbrugernes perspektiv mere i det, vi gør. Vi kan bedre forestille os deres situation."
Caroline: Føler du, at vi bygger bedre løsninger til vores kunder nu?.
Joey: "Ja, helt sikkert! Et godt eksempel på det er vores helt nye betalingssystem."
Caroline: Som virksomhed forbedrer og ændrer vi os hele tiden. Men er du nu, efter otte måneder, tryg ved den nye arbejdsproces?
Anna: "I begyndelsen var jeg ikke sikker på, hvad jeg kunne bidrage med. Har jeg virkelig brug for at være her? Hvad er min værdi? Hvad er grunden til, at jeg er her? På det punkt er jeg i hvert fald meget mere selvsikker nu. Jeg kan se, at jeg har værdi og har en plads på holdet."
