Fejl for fanden!

Nu skal du ikke tro, jeg ønsker, at du skal fejle - jeg tror bare på at det er en uundgåelig del af livet.

Når man tror på, at vi uden tvivl kommer til at fejle, så giver det mening at lægge noget energi i at tænke over hvordan vi håndterer fejl. Lærer vi noget eller bliver vi ved med at begå samme fejl? Skammer vi os og lader være med at prøve igen? Står vi ved vores fejl eller finder vi på undskyldninger? Hænger vi folk ud som begår fejl eller hjælper vi dem til ikke at begå dem igen? Tilgiver vi?

Det er ligegyldigt om det handler om softwareudvikling, iværksætteri, parforhold eller politik. Fejlhåndtering er en nødvendig evne. Frygt for at begå fejl kan gøre os handlingslammede. Her i huset siger vi "dem der laver fejlene er dem der laver noget" og det hjælper faktisk at huske, når man ærgrer sig over en fejl. Man kan naturligvis finde mange ordsprog og citater med variationer over samme tema.

Selvfølgelig skal man også være opmærksom på hvad det koster at begå en fejl. En kirurg oplever større konsekvenser ved fejl end softwareudviklere. Men hvis man er i et domæne, hvor det bedre kan betale sig at fejle hurtigt end at bevæge sig langsomt for ikke at fejle, så bør man overveje om ikke det skal være fokus.

I startupverdenen bruger man et udtryk; "FUCK IT. SHIP IT." til at fortælle at det ofte er bedre at have et fejlfyldt produkt på markedet end at bruge 3 år ekstra på at gøre det fejlfrit og så er produktet blevet overflødigt, overhalet eller gammeldags undervejs. Når man laver nye produkter er det også bedre at få det testet in the wild og så hurtigt finde ud af at interessen ikke er der end at lave et fejlfrit produkt for derefter at finde ud af at markedet ikke er der. Fejl hurtigt - det er billigere.

I softwareudvikling ser vi ofte kultur omkring fejl komme på banen, når vi skal tale bugfixing, continuous integration, continuous deployment og agil udvikling. Mobbes folk for at brække build? Gør det helt så meget at man får en fejl sendt i produktion, hvis systemet understøtter at man konstant sender nye versioner ud til kunderne? Fokuserer vi på antal fundne bugs som en god eller en dårlig ting? Ved folk at de bliver fyret for at begå fejl og derfor udvikler de CYA-taktikker? Sender man lorten videre i systemet eller står man ved den og får den fjernet inden dunsten breder sig?

Kulturen omkring fejl kan betyde meget for en virksomhed. Heldigvis kan det ændres. Der er mange teknikker især på ledelsesniveau, som påvirker fejlkulturen. F.eks. har Microsoft lige droppet en evalueringsmetode som påvirkede fejlkulturen i en negativ retning. På den anden side kan man se at ord som flawsome og fejltastisk er kommet på banen i den seneste tid og det påvirker vores holdninger til at stå ved sine fejl mod at være noget positivt.

Hvad er dine favoriteksempler på at fejlkultur har påvirket et projekt eller en virksomhed?

Relateret indhold

Therese Hansens billede

Kommentarer (11)

Kommentarer (11)
Therese Hansen

Indenfor softwareudvikling er der heldigvis en rimelig god kultur omkring at undgå de gentagende fejl. I hvert fald på softwareniveau - vi skriver gerne en fejlende test inden vi retter en fejl og sikrer os dermed at fejlen forbliver rettet og ikke dukker op igen i næste version.

At vi så bliver ved med at gentage fejl på højere niveauer i vores softwareprojekter er en anden sag. Voldsom under-estimering og magisk softwaresovs er gode eksempler på noget der dukker op igen og igen.

Therese Hansen

Der er en teori om at manglende lyst til at påpege fejl ved autoriteter, kan have ført til slemme fly-crash i f.eks. koreanske flyselskaber. Senest har der været fremført en teori om at det var et problem, da Asiana crashede i San Francisco tidligere i år, men de har kørt kulturel undervisning for at undgå netop det problem.

http://news.nationalgeographic.com/news/2013/07/130709-asiana-flight-214...

Torben Mogensen Blogger

De dumme fejl er dem der rammer os igen og igen.

Jeg betragter nu dumme fejl som fejl, der kunne have været undgået med bare et minimum af omtanke. Hvis den slags rammer igen og igen, er det ikke fejlen, der er dum, så er det den fejlende.

Men generelt er min holdning til fejl, at hvis man ikke laver fejl, så er det man laver slet ikke svært nok til at være interessant.

Søren Sjøgren

27 marts 1977 kolliderede et hollandsk og et amerikansk passagerfly i lufthavnen i Tenerife. Det kostede 583 menneskeliv. Årsagen til koalitionen var pilotfejl. Bl.a. at andenpiloten ikke greb ind selvom man senere kunne høre at han havde erkendt pilotens fejltagelser.

Pilotens, kirurgens og soldatens verden sig måske fra softwareudviklingen ved at have store menneskelige konsekvenser ved fejl, men mekanismerne og måder at afhjælpe dem er de samme: det handler om fejlkulturen.

I Forsvaret arbejder vi med strukturede evalueringer efter indsættelser (after action reviews). Aftalen ved sådan et review er at teamet skal lære af sin indsættelse, og at der ikke tages andet end læringspunkterne med ud fra reviewet. Hvem der lavede fejlene er uinteressant. Et review er samtidig et magtfrit rum, hvor lederen ikke er leder, men blot et medlem at teamet. Det skal gerne afbøde effekten af respekt/angst for autoriteten.
Under indsættelser i kamp er der behov for at organisationen hurtigt kan bringe en given ordre ud i livet. Der er ikke plads til debat: der skal handles nu og her. Det sagt, så tager jeg som leder også fejl. Med tanke på autoritetsbegrebet havde jeg udstyret mine mellemledere med ret og pligt til at sige fra og bede mig tænke mig om en gang mere.

Det sidste er måske ikke synderligt relevant i denne kontekst, men de struktureredes evalueringer kunne være. Det er i hvert fald en måde at skabe en ramme som bryder med leder/medarbejder forholdet og sætter fokus på at lære af fejlene.

Men det hele starter med ledelsens perception af fejl.

Jesper Lund Stocholm Blogger

Gør det helt så meget at man får en fejl sendt i produktion, hvis systemet understøtter at man konstant sender nye versioner ud til kunderne?

Dette er præcist ovenstående holdning, der gør, at nogle virksomheder er tilbageholdende med at indføre agile metoder til udvikling af deres software ... og det er faktisk lidt synd - for både dem og os.

Allan Ebdrup Blogger

Tillad mig at komme med en noget generaliserende betragtning:

Når sker en alvorlig fejl, og med alvorlig så mener jeg en der truer virksomhedens eksistens, hvis den bliver ved med at ske, kan du vælge mellem.

  • Den defensive strategi: Gøre alt hvad du kan for at der ikke sker fejl igen
  • Den aggresive strategi: Gøre alt hvad du kan for at reagere hurtigere hvis der sker fejl igen

I min erfaring er de to strategier i praksis deres diamentrale modsætninger. Du gør selvfølgelig lidt a hvert, men du bliver nød til at vælge den ene som en slags grund-filosofi når du skal priotere, du kan ikke sige både og.

Den defensive strategi fører til at du primært bruger dine kræfter på mere test, mere QA, stærkere styring af processer, kontroller, gates, mere dokumentation, måske langsommere releases osv.

Den aggresive strategi fører til at du primært bruger dine kræfter på at forbedre din monitorering af produktionssystmerne, og det er virkelig noget der skal bruges mange kræfter på, så du hurtigere kan spotte og hurtigere kan rulle et fiks ud.

Den aggresive strategi vælges nok oftest som grund-filosofi af start-ups blandt anded fordi.

  • Den kræver ikke nødvendigvis nyansættelser, det kan laves af teknikerne. Mens den defensive strategi kræver nye kompetencer, process-specialister, testere osv.
  • Den aggresive strategi er mindre omkostningstung, da den kræver færre personer, og i højere grad kan automatiseres
  • Et startup har ikke så meget at "passe på", ikke så meget at være defensiv omkring. Det er vigtigere at vokse hurtigt og gamble, end at beskytte det du allerede har opnået.

Men den defensive strategi kan også vælges af startups. Lad os sige at dit startup sælger sikkerhedsløsninger til banker. Så kan det godt være at den defensive strategi giver mening som grund-filosofi i dit startup.

Du kan finde en masse special-eksempler på at ovenstående ikke holder, men pointen er altså at du bliver nød til at aktivt vælge enten den defensive eller den aggresive strategi som grund-filosofi i din virksomhed.

Peter Stricker

Der er et par punkter i din beskrivelse af strategivalg, jeg ikke helt forstår.

Først synes jeg, at du beskriver den defensive strategi som den, hvor man lærer af sine fejl, og den aggressive strategi som ren brandslukning.

Derefter skriver du at en af årsagerne til at start-ups vælger den aggressive strategi er, at den (og her går jeg ud fra at du mener praktikkerne, og ikke selve strategien) i højere grad kan automatiseres. Det må, som jeg læser det, være fordi der ikke er mere tilbage, der mangler at blive automatiseret i modne virksomheder, der vælger den defensive strategi. Der er i hvert fald mange af de praktikker som du karakteriserer en defensiv strategi ved, der virker som oplagte kandidater til automatisering.

Som en prototype på den aggressive strategi, ser jeg indlægget fra Jesper Frederiksen: http://www.version2.dk/blog/hvis-du-er-i-tvivl-saa-test-54920
Da jeg først læste det, tænkte jeg WTF, hvorfor vente med test til man er i tvivl? Og jeg fornemmer ud fra din kommentar til bloggen, at du tænkte det samme.

Jeg sidder tilbage med indtrykket af, at den aggressive strategi ikke er et aktivt valg hos start-ups, men snarere en konsekvens af en manglende modenhed. En modenhed, der stille og roligt vil føre til et kontinuert strategiskifte fra aggressiv til defensiv, snarere end et diskret spring.

Allan Ebdrup Blogger

Derefter skriver du at en af årsagerne til at start-ups vælger den aggressive strategi er, at den (og her går jeg ud fra at du mener praktikkerne, og ikke selve strategien) i højere grad kan automatiseres. Det må, som jeg læser det, være fordi der ikke er mere tilbage, der mangler at blive automatiseret i modne virksomheder, der vælger den defensive strategi. Der er i hvert fald mange af de praktikker som du karakteriserer en defensiv strategi ved, der virker som oplagte kandidater til automatisering.

Ja det er ikke nemt for mig at forklare hvad jeg mener. Sorry.

Man gør selvfølgelig begge dele. (Strengt taget er det at tage en backup en agressive strategi, men hvem gør ikke det?).

Gund idéen Der ALTID er mere der kan automatiseres, det er derfor jeg taler om en grund-filosofi og prioritering. Med det mener jeg hvordan er virksomheds-kulturen? Er den "Vi laver ALDRIG fejl, og hvis vi gør så falder der brænde ned". Eller er kulturen nærmere "Vi gør alt hvad vi kan for at reagere hurtigt når der er en fejl".

Jeg behøver ikke være ret lang tid i en virksomhed, før jeg ved hvilken en af strategierne er vigtigst.

Min pointe er så at jeg synes man aktivt skal vælge den ene eller den anden. For ellers bliver den defensive nærmest pr. automatik valgt som den vigtigste.

David Nielsen

er det ikke to forskellige ting?

og det seneste mantra om at man skal lave et startup med mål at fejle - der tror jeg ikke at man lærer det rigtige hvis man allerede har sit mind-sæt låst fast på at det skal fejle...

fejl hutigere kan jeg bedre lide - prototyping, prototyping, osv. - få et produkt ud hurtigst muligt og valideret/fejlet det.

Log ind eller opret en konto for at skrive kommentarer