Vi tror starkt på att förena våra krafter. När allt kommer omkring kan man lära sig mycket av och med varandra. Dessutom är olika perspektiv på samma ämne till stor hjälp för att fatta ett välavvägt beslut.
Utveckling och stöd är avgörande för att kunna leverera de bästa kundlösningarna
På Easy LMS är utveckling och support avgörande för att kunna leverera de bästa kundlösningarna. De arbetade redan tillsammans, men de var separata team.
Fram till juni 2021 var det så här de arbetade tillsammans i ett nötskal - förenklat och utan några nyanser ?. Support var ansvariga för att serva våra kunder på bästa sätt. De tillbringade mycket tid med att lyssna på dem och hjälpa dem att nå sina träningsmål. En del av detta var att svara på deras frågor i chatt eller demo och logga deras buggar och funktionsförfrågningar. Knyt ihop det och kör! Sedan kom produktägaren in i bilden. Baserat på den information som loggats av konsulterna och hans produktvision bestämde han vilken funktion som skulle byggas bredvid och presenterade sin lösning för utvecklingsteamet. Utvecklarna skapade lösningen - inte sällan med hjälp och insikt från supporten - och lanserade den! Slutligen uppdaterade konsulterna allt relaterat innehåll. Nu är det klart!
Utnyttja teamets styrkor i större utsträckning
Som du kan läsa kunde vi använda teamens styrkor bättre. Därför bestämde vi oss för att ta samarbetet till nästa nivå. Ett nytt team föddes: ett problemlösningsteam som inkluderar medlemmar från utveckling och support. Dessutom är en UX-designer och en produktägare involverade i teamet.
Intervju med team Jabba
För närvarande har vi två problemlösningsgrupper: team Jabba (namnet består av alla gruppmedlemmarnas initialer) och SummerKnowly (uppkallad efter vår maskot). Anna och Joey är medlemmar i team Jabba. Tillsammans med kommunikationsugglan Caroline berättar de om detaljerna i det uppgraderade samarbetet.
Caroline: Sedan juni 2021 har vi de problemlösande teamen. Anna, kan du förklara hur teamen hanterar kundfrågor nuförtiden?
Anna: "Support hanterar fortfarande kundens frågor; vi är den första kontaktpunkten. Vi svarar på dem och hjälper dem. Om en kund rapporterar en bugg försöker vi reproducera den med lite hjälp från utvecklingsavdelningen, och om vi lyckas loggar vi den som en bugg och markerar hur brådskande den är och hur stor påverkan den har.
För funktionsförfrågningar är det samma sak som för buggar, förutom reproduktionssteget. Vi skickar en funktionsförfrågan med så mycket detaljer som möjligt till Productboard, ett verktyg för att hantera alla våra funktionsförfrågningar. Vår produktägare Jeroen och UX Designer & Forskare Dyann bearbetar dem och väger noggrant och betygsätter funktionsförfrågan mot vårt företags syfte. Detta resulterar i en att-göra-lista med nya funktioner att bygga."
Caroline: Okej, det här ser lite ut som den gamla processen; dessutom finns det mer kommunikation och interaktion. Så när kommer utveckling in i processen?
Vi tar in olika perspektiv
Joey: "Just i detta ögonblick. I stället för produktägaren är det teamen som ansvarar för vad de ska arbeta med och vilken lösning som ska väljas. Från vårt problemlösningsteam är det Anna och jag som ansvarar för att välja vad vi ska arbeta vidare med som team. Här tar vi in olika perspektiv. Anna vet vad en kund behöver, medan jag har en bra känsla för komplexiteten i en förfrågan."
"Vi prioriterar buggar mot potentiella nya funktioner och bestämmer vad vi ska arbeta med baserat på hur bråttom det är. När vi har valt skriver vi ner den aktuella omständigheten för problemet och resultatet av den omständigheten, så att resten av teamet vet varför det är bråttom att lösa problemet. Sedan kommer resten av teamet in för att diskutera lösningen och skriva ner den. Dyann, vår UX Designer & Researcher, deltar ofta i samtalet för att säkerställa att den valda lösningen är användarvänlig och lätt att förstå. Diskussionen är värdefull tack vare de många olika perspektiv som vi tar in. Alla har något att säga till om. Efter det skickar vi vårt förslag till produktägaren för godkännande."
Caroline: Får du alltid godkännande direkt?
Joey: "För det mesta. Om det inte godkänns kommer Jeroen att ha några frågor som vi försöker besvara i ett samtal eller i förslagsdokumentet. Det blir en del skrivande fram och tillbaka innan vi får grönt ljus. När det är godkänt skriver vi användarberättelser (red. en kort skriftlig förklaring av vad en användare vill ha och förväntar sig) och delar upp uppgifterna mellan teamet.
Caroline: Är supporten också involverad i att skriva användarberättelserna? Tidigare gjordes detta bara av utveckling.
Anna: "Det beror på om det är en funktion eller en bugg. Vi joinar alltid för nya funktioner, men för buggar är det inte alltid nödvändigt. Att skriva användarberättelser är relativt nytt för oss. Så vi arbetar på att bli bättre på det."
"Det vi också gör är att omedelbart börja skriva det relaterade innehållet för den nya funktionen. Relaterat innehåll är etiketter för administratörs- eller deltagargränssnittet eller hjälpartiklar. Dessutom måste vi bestämma vilken kundkommunikation som behöver göras, till exempel meddelanden i produkten, direkta kundmeddelanden osv. Vi gör detta parallellt med att funktionen byggs."
Caroline: Så den största förändringen är att support och utveckling väljer en fråga och skapar lösningen tillsammans. Ni har båda större inflytande på slutresultatet. Hur upplever du den nya arbetsprocessen?
Anna: "Det var definitivt en omställning att vänja sig vid det nya arbetssättet när det gäller schemaläggning och att arbeta nära nya människor. Men det var också en fördel. Jag gillar att arbeta närmare utvecklarna eftersom de har olika perspektiv på vad som ska byggas och varför. Vi fattar mer balanserade beslut nu. Det är också bra att vi kan se på varandra hur vi arbetar. Förr i tiden tog vi hänsyn till problemen. Vi gjorde mer manuellt arbete, och det blev normen. Utvecklare märker lätt om manuellt arbete kan automatiseras eller effektiviseras. Det ligger i deras natur att tänka på det sättet. Deras hjälp har redan sparat oss en hel del tid."
Vi har nu mycket mer insikt i vad som faktiskt händer
Joey: "Vi har nu mycket större insikt i vad som faktiskt händer. Hur kunderna använder vårt LMS, vad som är viktigt för dem och hur de resonerar kring det. Det känns som att vi är mer i kontakt med kundens behov. Så tidigare överlämnades ett problem till oss efter att det gått igenom flera företagslager. Vi befann oss i slutet av processen, så mycket viktig information gick förlorad på vägen och många frågor ställdes inte. Vi känner till systemet tekniskt mycket bättre och vi ser på problem på ett annat sätt. Genom att ha stöd tillsammans från början kan vi ställa de frågor vi behöver för att bygga en effektiv och hållbar lösning. Vi kan säga att informationsgapet har täppts till."
Karolin: Vi gör också kundintervjuer för att bättre förstå våra kunders behov. Jag antar att detta är mycket värdefullt för problemlösningsteamet?
Joey: "Ja, det är det! För det som kunderna vill ha är inte alltid det de behöver. Det som de tycker går fel är inte alltid det underliggande som behöver åtgärdas. Det är väldigt svårt att se som utomstående. Så kundintervjuerna är ett värdefullt verktyg för att avslöja underliggande problem. De ger oss också ett sammanhang!"
Det finns en hel del kunskapsutbyte
Caroline: Okej, tillbaka till samarbetet mellan utveckling och support. Hur kompletterar ni varandra?
Anna: "Det är mycket kunskapsdelning. Förutom att konsulterna bidrar med kundens perspektiv vet vi båda olika saker om LMS:et. Det leder till att vi ibland vet hur verktyget fungerar och de inte gör det, och vice versa. Så till exempel är något helt uppenbart för oss (red. support), medan utvecklarna inte trodde att det fungerade på det sättet eller att folk använde en funktion på det sättet. På samma sätt kan vi ägna tjugo minuter åt att replikera en bugg, men om jag skickar ett meddelande om det till en utvecklare vet de lösningen direkt. Så det finns lite av det på båda sidor, och nu kan vi dela med oss av det."
Caroline: Finns det också en nackdel med att arbeta på det här sättet?
Joey: "Nej, att föra samman utveckling och support var ett bra steg. Generellt sett finns det alltid en nackdel med att ändra arbetsmetod. Man måste vänja sig vid det, och det kan leda till en del frustrationer. Det är tidskrävande. Men det är bara hinder som man måste övervinna. Det är inte en dealbreaker. Vi vill inte gå tillbaka."
Caroline: Kan du utveckla det. Vad var det mest utmanande?
Joey: "Den största utmaningen var att komma på hur vi kunde använda varandras styrkor på rätt sätt och inte slösa bort varandras tid. I början hände det många gånger att vi hade för många personer på mötena som inte kunde bidra till diskussionen. Så det var slöseri med deras tid. Men det motsatta hände också. Vi hade så kallade felmöten. Människor som kunde ha bidragit men inte var där. Så småningom lyckades vi genom att kommunicera om våra erfarenheter och genom att tillämpa "trial and error"-metoden."
Caroline: Anna, vad har du lärt dig av utvecklarna i ditt team?
Jag lärde mig att strukturera mitt dagliga arbete bättre med färre avbrott
Anna: "Det är lite svårt att säga. Jag skojar bara. För det första, på en mer filosofisk nivå, är utvecklarnas arbete mycket mer strukturerat än supportarbetet. Jag lärde mig hur jag skulle strukturera mitt dagliga arbete bättre med färre avbrott. Utvecklare är mycket noga med sin tid, vilket är logiskt eftersom de behöver oavbruten tid för att utföra sitt arbete - att se det hjälper mig att ta med det i min arbetsdag. Så jag lärde mig att hålla min tid och mina gränser bättre. Sedan, på ett mer praktiskt plan, ger utvecklarna mig många felsökningstips som hjälper kunderna."
Caroline: Och i gengäld, Joey, vad lärde du dig av supportkonsulterna i ditt team?
Joey: "Jag tror att det är motsatsen till det sista som Anna just sa. Vi har alltid haft en massa idéer om hur vi ska lösa saker, vi har bara kunnat förlita oss på vår kunskap. Men vi använder inte systemet på samma sätt som kunderna gör. Så genom att interagera med supporten lärde vi oss mycket om hur kunderna faktiskt använde systemet och vilka lösningar som skulle passa dem. Tidigare var det bara att gissa och göra så gott vi kunde. Vi involverar slutanvändarnas perspektiv mer i vad vi gör. Vi kan bättre föreställa oss deras situation."
Caroline: Tycker du att vi bygger bättre lösningar för våra kunder nu?
Joey: "Ja, absolut! Ett bra exempel på det är vårt helt nya betalningssystem."
Caroline: Som företag förbättras och förändras vi hela tiden. Men känner du dig nu, efter åtta månader, bekväm med den nya arbetsprocessen?
Anna: "I början var jag inte säker på hur jag kunde bidra. Behöver jag verkligen vara här? Vad är mitt värde? Vad är skälet till att jag är här? Åtminstone när det gäller den delen är jag mycket mer självsäker nu. Jag ser att jag har ett värde och har en plats i laget."
