Vi har stor tro på å forene krefter. Man kan tross alt lære mye av og med hverandre. Dessuten er ulike perspektiver på samme tema til stor hjelp for å ta en balansert beslutning.
Utvikling og støtte er avgjørende for å kunne levere de beste kundeløsningene
Hos Easy LMS er utvikling og support avgjørende for å kunne levere de beste kundeløsningene. De jobbet allerede sammen, men de var separate team.
Frem til juni 2021 var det slik de jobbet sammen i et nøtteskall - forenklet og uten nyanser. De brukte mye tid på å lytte til dem og hjelpe dem med å nå treningsmålene sine. En del av dette var å svare på spørsmålene deres i chat eller demo og logge deres feil og funksjonsforespørsler. Knytte sammen og sette i gang! Så kom produkteieren inn i bildet. Basert på informasjonen som konsulentene hadde logget og produktvisjonen hans, bestemte han seg for hvilken funksjon som skulle bygges ved siden av, og presenterte løsningen for utviklingsteamet. Utviklerne laget løsningen - sjelden med hjelp og innsikt fra supporten - og lanserte den! Til slutt oppdaterte konsulentene alt relatert innhold. Så var det gjort!
Utnytt teamets sterke sider i større grad
Som du kan lese, kunne vi bruke teamenes styrker bedre. Derfor bestemte vi oss for å ta samarbeidet til neste nivå. Et nytt team ble født: et problemløsningsteam som inkluderer medlemmer fra utvikling og support. I tillegg er en UX-designer og en produkteier involvert i teamet.
Intervju med team Jabba
For øyeblikket har vi to problemløsningsteam: team Jabba (navnet består av alle initialene til teammedlemmene) og SummerKnowly (oppkalt etter maskoten vår). Anna og Joey er medlemmer av team Jabba. Sammen med kommunikasjonsuglen Caroline forteller de om detaljene i det oppgraderte samarbeidet.
Caroline: Siden juni 2021 har vi hatt problemløsningsteam. Anna, kan du forklare hvordan teamene behandler kundespørsmål i dag?
Anna: "Supporten behandler fortsatt kundenes spørsmål; vi er det første kontaktpunktet. Vi svarer på dem og hjelper dem. Hvis en kunde rapporterer en feil, prøver vi å reprodusere den med litt hjelp fra utviklingsavdelingen, og hvis vi lykkes, logger vi den som en feil og markerer hvor mye det haster og hvor stor innvirkning den har.
For funksjonsforespørsler er det det samme som for feil, bortsett fra reproduseringstrinnet. Vi sender en funksjonsforespørsel med så mange detaljer som mulig til Productboard, et verktøy for å administrere alle funksjonsforespørslene våre. Produkteier Jeroen og UX-designer Dyann behandler disse og vurderer og vurderer funksjonsforespørslene nøye opp mot selskapets formål. Dette resulterer i en huskeliste over nye funksjoner som skal bygges."
Caroline: Ok, dette ser litt ut som den gamle prosessen, men det er mer kommunikasjon og samhandling. Så når kommer utviklingen inn i prosessen?
Vi bringer inn ulike perspektiver
Joey: "Akkurat nå. I stedet for produkteieren er det teamene som er ansvarlige for hva de skal jobbe med og hvilken løsning som velges. Fra problemløsningsteamet vårt er det Anna og jeg som er ansvarlige for å velge hva vi skal jobbe videre med som team. Her bringer vi inn ulike perspektiver. Anna vet hva en kunde trenger, mens jeg har en god følelse av kompleksiteten i en forespørsel."
"Vi prioriterer feil opp mot potensielle nye funksjoner, og bestemmer hva vi skal jobbe med basert på hvor mye det haster. Når vi har valgt, skriver vi ned den aktuelle situasjonen for problemet og resultatet av denne situasjonen, slik at resten av teamet vet hvorfor det haster med å løse problemet. Deretter kommer resten av teamet inn for å diskutere løsningen og skrive den ned. Dyann, vår UX-designer og researcher, blir ofte med i samtalen for å sikre at den valgte løsningen er brukervennlig og lett å forstå. Diskusjonen er verdifull fordi vi bringer inn flere perspektiver. Alle har noe å si. Deretter sender vi forslaget vårt til produkteieren for godkjenning."
Caroline: Får du alltid godkjenning med en gang?
Joey: "For det meste. Hvis det ikke blir godkjent, vil Jeroen ha noen spørsmål som vi prøver å besvare i en samtale eller i forslagsdokumentet. Det blir en del skriving frem og tilbake før vi får grønt lys. Når det er godkjent, skriver vi brukerhistorier (red. en kort skriftlig forklaring på hva en bruker ønsker og forventer) og fordeler oppgavene mellom teamet.
Caroline: Er brukerstøtte også involvert i å skrive brukerhistoriene? Før var det bare utviklingsavdelingen som gjorde dette.
Anna: "Det kommer an på om det er en funksjon eller en feil. Vi blir alltid med for nye funksjoner, men det er ikke alltid nødvendig for bugs. Å skrive brukerhistorier er relativt nytt for oss. Så vi jobber med å bli bedre på det."
"Det vi også gjør, er å begynne å skrive relatert innhold for den nye funksjonen. Relatert innhold er etikettene for administrator- eller deltakergrensesnittet eller hjelpeartikler. I tillegg må vi bestemme hvilken kundekommunikasjon som må gjøres, for eksempel meldinger i produktet, direkte kundemeldinger osv. Dette gjør vi parallelt med at funksjonen bygges."
Caroline: Så den viktigste endringen er at support og utvikling velger et problem og utarbeider løsningen sammen. Dere har begge større innflytelse på sluttresultatet. Hvordan opplever du denne nye arbeidsprosessen?
Anna: "Det var definitivt en omveltning å venne seg til den nye arbeidsstilen når det gjelder planlegging og det å jobbe tett med nye mennesker. Men det var også en fordel. Jeg liker å jobbe tettere med utviklerne, fordi de har ulike perspektiver på hva vi skal bygge og hvorfor. Vi tar mer balanserte beslutninger nå. Det hjelper også at vi ser hvordan vi jobber fra hverandre. Tidligere måtte vi ta hensyn til problemer. Vi gjorde mer manuelt arbeid, og det ble normen. Utviklere merker lett om manuelt arbeid kan automatiseres eller effektiviseres. Det ligger i deres natur å tenke på den måten. Hjelpen deres har allerede spart oss for mye tid."
Vi har nå mye mer innsikt i hva som faktisk skjer
Joey: "Vi har nå mye mer innsikt i hva som faktisk skjer. Hvordan kundene bruker LMS-et vårt, hva som er viktig for dem, og hva som ligger bak. Det føles som om vi er mer i kontakt med kundenes behov. Før fikk vi et problem overlevert etter at det hadde gått gjennom flere lag i selskapet. Vi var på slutten av prosessen, så mye viktig informasjon gikk tapt underveis, og mange spørsmål ble ikke stilt. Vi kjenner systemet mye bedre rent teknisk, og vi ser på problemer på en annen måte. Det at vi har vært med fra starten, gjør at vi kan stille de spørsmålene vi trenger for å bygge en effektiv og bærekraftig løsning. Vi kan si at informasjonsgapet er blitt lukket."
Caroline: Vi gjennomfører også kundeintervjuer for å forstå kundenes behov bedre. Jeg antar at dette er svært verdifullt for problemløsningsteamet?
Joey: "Ja, det er det! For det kundene ønsker, er ikke alltid det de trenger. Det de tror går galt, er ikke alltid det underliggende problemet som må løses. Det er veldig vanskelig å se som utenforstående. Derfor er kundeintervjuene et verdifullt verktøy for å avdekke underliggende problemer. De gir oss også kontekst!"
Det er mye kunnskapsdeling
Anna: "Det er mye kunnskapsdeling. I tillegg til at konsulentene bringer inn kundens perspektiv, vet vi begge to forskjellige ting om LMS-et. Det fører til at vi noen ganger vet hvordan verktøyet fungerer, mens de ikke gjør det, og vice versa. For eksempel kan noe være helt åpenbart for oss (red. support), mens utviklerne ikke trodde det fungerte på den måten, eller at folk brukte en funksjon på den måten. På samme måte kan vi bruke tjue minutter på å replikere en feil, og hvis jeg sender en melding om det til en utvikler, vet de løsningen umiddelbart. Så det er litt av det samme på begge sider, og nå kan vi dele det med hverandre."
Caroline: Er det også en ulempe med å jobbe på denne måten?
Joey: "Nei, det var et godt skritt å samle utvikling og support. Generelt er det alltid en ulempe med å endre arbeidsmetoden. Du må venne deg til det, og det kan føre til frustrasjoner. Det er tidkrevende. Men det er bare hindringer du må overvinne. Det er ikke noe som ødelegger alt. Vi ønsker ikke å gå tilbake."
Joey: "Det mest utfordrende var å finne ut hvordan vi kunne bruke hverandres styrker på riktig måte, og ikke kaste bort hverandres tid. I begynnelsen hendte det ofte at vi hadde for mange mennesker på møtene som ikke kunne bidra til diskusjonen. Så det var bortkastet tid. Men det motsatte skjedde også. Vi hadde såkalte feilmøter. Folk kunne ha bidratt, men var ikke til stede. Etter hvert klarte vi det ved å kommunisere om erfaringene våre og ved å prøve og feile."
Caroline: Anna, hva har du lært av utviklerne i teamet ditt?
Jeg lærte å strukturere det daglige arbeidet mitt bedre med færre avbrytelser
Anna: "Det er litt vanskelig å si. Jeg bare tuller. For det første, på et mer filosofisk nivå, er arbeidet til utviklere mye mer strukturert enn supportarbeid. Jeg lærte å strukturere det daglige arbeidet mitt bedre med færre avbrytelser. Utviklere er veldig nøye med tiden sin, noe som er logisk fordi de trenger uforstyrret tid til å gjøre jobben sin - og det hjelper meg å ta med meg dette inn i arbeidsdagen min. Så jeg har lært meg å holde tiden og grensene bedre. Og så har utviklerne gitt meg mange feilsøkingstips for å hjelpe kundene på en mer praktisk måte."
Caroline: Og hva har du til gjengjeld lært av støttekonsulentene i teamet ditt, Joey?
Joey: "Jeg tror det er det motsatte av det siste Anna nettopp sa. Vi hadde alltid mange ideer om hvordan vi kunne fikse ting, og vi kunne bare stole på kunnskapen vår. Men vi bruker ikke systemet på samme måte som kundene gjør. Så ved å samhandle med kundestøtte lærte vi mye om hvordan kundene faktisk brukte systemet, og hvilke løsninger som passet for dem. Før var det bare å gjette og gjøre så godt vi kunne. Vi involverer sluttbrukernes perspektiv mer i det vi gjør. Vi kan bedre forestille oss situasjonen deres."
Caroline: Føler du at vi bygger bedre løsninger for kundene våre nå?
Joey: "Ja, absolutt! Et godt eksempel på det er det helt nye betalingssystemet vårt."
Caroline: Som selskap er vi i kontinuerlig forbedring og endring. Men er du nå, etter åtte måneder, komfortabel med den nye arbeidsprosessen?
Anna: "I begynnelsen var jeg usikker på hva jeg kunne bidra med. Trenger jeg virkelig å være her? Hva er min verdi? Hva er grunnen til at jeg er her? Nå er jeg i hvert fall mye tryggere på den delen. Jeg ser at jeg har verdi og har en plass på laget."
