At forbedre sig en smule hver dag. Ville det ikke være fantastisk? Hos Easy LMS er vi alle tilhængere af Kaizen-metoden. Denne japanske produktivitetsmetode hjælper os med at tackle tidsspilde og gøre arbejdet sjovere og lettere. Dens nøgleaspekt er løbende forbedringer;
Hvorfor Kaizen?
Store forbedringsprocesser. Vi har prøvet, tro mig, men aldrig med den ønskede effekt. De gik i stå, fordi vi ikke kunne vælge mellem alle de mulige forbedringer, og vi fortabte os i de daglige problemer. Der kom altid et kundespørgsmål ind imellem, som var mere presserende end at sætte en hel proces i gang;
Da vi virkelig godt kan lide at forbedre os, har vi valgt Kaizen-metoden. Efter at have læst bogen Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results af Mike Rother, blev vi overbevist om dens effektivitet. Kaizen fokuserer trods alt ikke på, at alt skal være perfekt på én gang, men på at tage små skridt hver dag. De små skridt er faktisk meget små skridt. I alt vil disse skridt bringe dig langt. I sidste ende løber du også et maraton trin for trin;
Den bogstavelige oversættelse af Kaizen er "forandring til det bedre".
Oversigt over Kaizen-metoderne hos Easy LMS
Kaizen har en bred vifte af metoder og processer, både store og små, til at realisere forbedringer. Kaizen hos Easy LMS er baseret på følgende dele:
Bestem retning ved at bruge målbetingelser.
Små løbende forbedringer.
Rodårsagsanalyse: spørg hvorfor fem gange.
Viden er magt.
Kaizen er alles ansvar.
Lad os fokusere på del to til fem, illustreret med et eksempel på, hvordan vi udfører Kaizen. Første del kræver en hel artikel for at forklare ?.
Del 2: Små løbende forbedringer
Nogle forbedringer synes at være for små, og netop derfor er det vigtigt at foretage dem.
Hvor lille er lille? I vores tilfælde er det meget småt. At lære genveje eller endda at flytte en printer til et mere praktisk sted er en forbedring. At lave små forbedringer er derfor måske det sværeste skridt. Nogle forbedringer synes at være for nyttesløse, for små eller at have for lille effekt. Derfor laver man dem ofte ikke, og netop da er det vigtigt at lave dem. Den anden fare er, at jo længere man venter, jo større bliver problemet, hvilket betyder, at man er nødt til at lægge det ind i planlægningen med alle de farer, der er forbundet hermed. Du kan starte med det samme med at lave små forbedringer. Selv uden godkendelse fra ledelsen. Hvert skridt fremad giver overskud;
Det indså vi, da vi kiggede nærmere på vores udgivelsescyklus. Tidligere skabte vi ny funktionalitet eller løste fejl online ("releasede") en gang med et par ugers mellemrum. Nu gør vi det mindst to gange om ugen, og meget snart vil det være hver gang, vi har færdiggjort noget;
Vejen til dette består af snesevis af små (mini)skridt. Vi vil gerne fremhæve fire:
Vi tester først alt, før det går i luften. For at teste en udgivelse skulle udviklerne i første omgang gøre den tilgængelig i vores testmiljø. Nogle gange glemte udviklerne det, eller også var de syge. Vi er trods alt kun mennesker ?. Det gav os god grund til at sikre, at vores tester, Caroline, selv kan lægge releasen i testmiljøet.
Automatisk generering af en release tager 45 minutter, hvilket er ret lang tid at vente. Fordi det tager så lang tid, gør vi det nu på faste tidspunkter: Mandag og torsdag morgen kl. 6.00. Når Caroline kommer, kan hun gå i gang med det samme. Men først skal hun selvfølgelig have en kop kaffe ?
I starten skulle en udvikler også sætte en release i live i live-miljøet. Sådan er det ikke længere. Caroline gør det nu selv. Det er kun muligt at sætte den i drift, hvis alt er godkendt.
Vi laver altid accepttests, og det tager meget tid. Især hvis der er 25, som det er tilfældet hos os. Derfor begyndte vi at automatisere disse tests en efter en. Den første test sparede os lidt tid. Nu er de alle automatiserede, og det sparer os 12 timer om ugen.
Del 3: Årsagsanalyse, spørg hvorfor fem gange
Når man bruger Kaizen, lapper man ikke bare på tingene.
Når man bruger Kaizen, lapper man ikke bare på tingene. Man tager fat om nældens rod, så man kun behøver at løse problemet én gang. Altid lige så effektivt. Du kan finde den grundlæggende årsag til problemet ved at spørge "hvorfor" fem gange;
Hver gang vi ikke når et bestemt mål, laver vi en årsagsanalyse. Det giver os en grænse på tre user stories, som kan være under udvikling. Det har vi bestemt i fællesskab. Det tvinger os til at færdiggøre historierne i prioriteret rækkefølge. Hvis nogen tager en fjerde historie op, stopper vi arbejdet, og vi begynder at analysere.
For nylig var vi nødt til at sætte noget i gang, mens tre historier allerede var under udvikling. At sætte noget i gang betyder historie nummer fire. Vi kom frem til følgende analyse:
Hvorfor har vi åbnet en ny historie?
Vi skal lave en udgivelse, og udgivelsen kræver en historie, der fortæller, hvad der skal gøres.
Hvorfor har vi brug for denne historie? Vi vil sætte flere nye, efterspurgte funktionaliteter i drift.
Hvorfor tager vi flere funktioner i brug?
Vi tager aldrig kun én funktion i brug.
Hvorfor gør vi det ikke?
Det tager for lang tid at lave en release. Omkostningerne opvejer fordelene.
Hvorfor tager det så lang tid?
Test er flaskehalsen.
Hvorfor er test flaskehalsen?De automatiserede tests er ikke pålidelige nok, så der er mange manuelle tests.
Hvorfor er de automatiserede tests upålidelige?
Fordi vi bruger et ældre framework, som vi kører tests i.
Der er flere løsninger på forskellige niveauer til at løse dette problem. Sammen beslutter vi, hvad der er den bedste løsning i øjeblikket. Løsningen på denne grundlæggende årsag er at opdatere rammerne for at køre testene;
Del 4: Viden er magt
Hvordan ved du, om en forandring har været en succes? Viden er magt. Lav en baseline, og mål den så igen efter justeringen. Vi forsøger at gøre så mange ting målbare som muligt, men nogle gange er det også en mavefornemmelse, at noget kan gøres hurtigere eller bedre. Igen, vi er kun mennesker;
En proces, som vi har gjort fuldt målbar, er en brugerhistorie. Før en historie kan gå i luften, skal den igennem en hel række trin. Hvor lang tid tog disse trin? Det anede vi ikke, før vi begyndte at måle tiden. Så stod det straks klart, hvor flaskehalsen var: Det tog for lang tid, før Caroline kunne teste. Vi gennemførte en årsagsanalyse og implementerede straks en forbedring baseret på denne. En anden forbedring, der kom ud af det, var processen for håndtering af oversættelser. Men det er noget for en anden artikel;
Del 5: Kaizen er alles ansvar
Kaizen fungerer kun, hvis alle i virksomheden bidrager til det ved at tage ansvar og give tid og opmærksomhed til det. Hos Easy LMS får alle plads til at komme med forslag til forbedringer og tid til at arbejde med dem. Fordi vi ved, at det vil gavne os på lang sigt;
Nu hvor du har læst denne artikel, vil du gerne tage et skridt på vejen mod Kaizen?
